locked
Reliable Multicast Data Transfer RRS feed

  • Question

  • Hi there!

    Does Conference XP suports reliable multicast data transfer? I supposed the transfer of PowerPoint slides and annotation requires some sort of reliability if it is done through IP multicast. If that is the case, is there any specific reliable multicast protocol Conference XP is using (e.g. PGM, RMX, SRM)? Thanks.

    • Moved by Max Wang_1983 Thursday, April 28, 2011 7:02 PM forum consolidation (From:Developer Discussions)
    Thursday, August 30, 2007 2:13 PM

Answers

  • Hello,

    Glad I could help!  You are correct -- every receiver must have a separate socket for each sender.  Although some available documentation online says that PGM is connectionless (able to receive from multiple senders on the same socket), this is inaccurate.

    However, you do not need to disconnect each session to receive data from multiple senders.  What I do is this:  I create two  main sockets, both of which are bound to the same multicast address (the address of the venue) and one is bound to port 5004 (for RTCP data) and the other is bound to port 5005 (for RTP data) [Note: I might have those ports backwards, I can never remember which is which without looking it up Smile].  These sockets serve as my acceptors, which accept connections from different senders.  After binding, I call Listen() then BeginAccept() on both sockets, using an asynchronous callback to automatically handle any incoming connections without blocking the thread.  Inside the callback, once a connection is accepted and created, I store the new socket in its appropriate collection (one collection for RTP sockets and one for RTCP sockets).  Next, I call BeginReceiveFrom() on the new socket, using another asynchronous callback to process all incoming traffic without blocking the accept thread.  The acceptor socket then calls the BeginAccept() again with the same accept callback to accept any new connections.  Inside the receiving callback, I have all of the code responsible for processing packets, and have it recall itself after handling a new packet.

    This system allows me to automatically generate multiple sockets for receiving from multiple senders without having to reset the session if senders join or leave.  If you have any questions about how this works, I have a test application I wrote when I first began testing PGM that walks through the process.



    Wednesday, September 12, 2007 3:00 PM

All replies

  • Hello,

    To answer your question, CXP uses UDP as its networking protocol, which provides no mechanism for reliable delivery.  However, UDP has great bandwidth utilization and low latency, so it is great for streaming data where a little loss is acceptable, such as in audio/video streams with frame rates around 30 per second.  To offer more reliability for the other capablilities in CXP, like Presenter and Chat, the application provides error prevention through the FEC using the Reed-Solomon algorithm.  If enabled through the config file, FEC computes parity on every packet sent and can rebuild lost packets through the computed parity.  However, this process is very cpu intensive and can inhibit the conferencing process.

    At the University of Nebraska-Lincoln, we have been working on developing support for PGM within the CXP networking stack.  We built a version for CXP 3.5 (running on .NET 1.1) and ran simulations in wireless environments testing both the reliability and actual amount of time it takes for participants to receive packets due to loss and retransmissions.  This summer, we have reimplemented PGM within a copy of the CXP 4.0 networking stack (using .NET 2.0).  It wasn't an exact port of our old version because we wanted to make the code cleaner and possibly mergable into the main trunk of CXP.  The performance of PGM in CXP 4 has been observed to be the same as the prior version.  If you are interested in learning more about our work, please visit our website

    If you have any questions, I should be around the forums.

    Hope this helps!
    Adam
    Wednesday, September 5, 2007 7:43 PM
  • Thanks for the info Adam! I am actually looking for a good multi-sender multi-receiver capable reliable multicast protocol. Eg. Multiple senders in a session. So what you described on your website seems pretty helpful. Like how all receiving cannot be done on one socket.

    I've tested the Windows PGM implementation and everytime when I need to send data simultaneously from multiple sources to a single receiver, I have to open a new socket in that receiver. Since one socket = one session = one sender. So the notion of PGM multi-sender in RFC 3208 only guarantees no two senders sending to the same port can interfere with the receivers. But it doesn't mean multiple senders can send simultaneously to one receiver over one socket/session. If there are more than one sender sending at the same port, then that session need to be disconnected before the 2nd sender's data is received. Please corrent me if I'm wrong.
    Wednesday, September 12, 2007 3:01 AM
  • Hello,

    Glad I could help!  You are correct -- every receiver must have a separate socket for each sender.  Although some available documentation online says that PGM is connectionless (able to receive from multiple senders on the same socket), this is inaccurate.

    However, you do not need to disconnect each session to receive data from multiple senders.  What I do is this:  I create two  main sockets, both of which are bound to the same multicast address (the address of the venue) and one is bound to port 5004 (for RTCP data) and the other is bound to port 5005 (for RTP data) [Note: I might have those ports backwards, I can never remember which is which without looking it up Smile].  These sockets serve as my acceptors, which accept connections from different senders.  After binding, I call Listen() then BeginAccept() on both sockets, using an asynchronous callback to automatically handle any incoming connections without blocking the thread.  Inside the callback, once a connection is accepted and created, I store the new socket in its appropriate collection (one collection for RTP sockets and one for RTCP sockets).  Next, I call BeginReceiveFrom() on the new socket, using another asynchronous callback to process all incoming traffic without blocking the accept thread.  The acceptor socket then calls the BeginAccept() again with the same accept callback to accept any new connections.  Inside the receiving callback, I have all of the code responsible for processing packets, and have it recall itself after handling a new packet.

    This system allows me to automatically generate multiple sockets for receiving from multiple senders without having to reset the session if senders join or leave.  If you have any questions about how this works, I have a test application I wrote when I first began testing PGM that walks through the process.



    Wednesday, September 12, 2007 3:00 PM
  •  

    Hey Adam! Thanks very much for your answer! This is exactly what I'm looking for.

    Friday, September 28, 2007 8:56 AM
  • Nice work, Adam.

    Monday, October 29, 2007 6:35 PM
  • Well done, Adam.

     

    Although it may seem backwards (who wouldn't want the control data first?), the order according to the RFC is DATA then CONTROL packets (RTP then RTCP, 5004 then 5005).  :-)

     

    JVE

     

    Thursday, November 8, 2007 3:55 PM
  • Hi, Can i You help me?
    I want Only one receiver from two hosting. Each host send data to same Multicast address and same Port.
    Is Posible that only one socket receives dat feom two senders sockets?

    Thanks.

    Can you write me to jcecharte@hotmail.com ?
    thanks
    Tuesday, May 12, 2009 2:39 PM