I am designing my own transport protocol for a video conferencing application. I would like to know whether a connection based or connectionless based approach is better for this application.
+1
A:
Things to note with TCP is that (assuming some sort of MPEG-ish encoding) if packets get delayed because of network problems, the video will freeze, or delay, until data arrives. The video, by definition of TCP, will be error free.
With UDP, while the video will be continous, you can get errors in the video. With an MPEG style protocol, where data is sent in the form of periodic key frames, and then delta frames in between them, if a UDP packet that contains a delta frame fails to arrive, then your video will become blocky and generally error prone as connection degrades. If a key frame is missed, then you will get other errors, perhaps with no video at all.
If what you are pointing the camera at is moving, and delta frames getting dropped would really mess up the image, then TCP may be required in order to guarantee that if you are getting video, it is at least accurate. However, if you are pointing at something fairly stationary (which you probably aren't if it is for video conferencing), then UDP may suffice, since an occasional delta frame loss probably won't effect the overall video quality.
Note also that if you are really rolling your own solution from the ground up, then you can add code to allow for glitches and attempt to handle them in a special way (such as timing out a TCP connection if frames lag to much, and notifying the user accordingly).
Kazar
2010-02-16 18:28:35
Games use UDP, so routers will send UDP packets across the net.
Martin
2010-02-16 18:36:53
Good point, I'll edit that bit out.
Kazar
2010-02-16 18:41:49
TCP retransmission will make a mess of real-time video. The video, when it arrives, may not have errors, but any errors at the network layer will result in a total freeze while TCP retransmits. The application layer must also be smart enough to discard data when it falls behind, otherwise the lag between the two ends will only widen every time there is a retransmission.
Steve Madsen
2010-02-16 19:15:57
+3
A:
I've developed games, including ones that are classified as "twitch" games like racing and FPS titles. For this type of game, latency is extremely important. You can't use TCP because it guarantees in-order delivery and will hold incoming packets while a resend is processed.
What we did for most of these was use what we called Stateful UDP. All that really means is that we added a packet ID to the message. When we received a message, we checked the ID. If the ID was higher than the highest ID we'd seen to far, we accepted and processed that packet. If it was lower, we dropped it. This approach works well when latency is important, as even with UDP you'll receive most of your packets, and most will be in-order.
jfawcett
2010-02-16 19:04:20
A:
TCP is inappropriate for this kind of application. The problem is with retransmission. If the receiver decides that a packet is lost or corrupted, and requests a retransmission, TCP does not allow for a single packet to be retransmitted. Every packet from the lost/corrupted packet on is retransmitted. With a constant, high-bandwidth stream of packets going across the network, one little glitch is going to cause unacceptable lags in the video stream that you may not be able to recover from.
Use UDP as your transport, and design the application layer such that you can gracefully degrade when network conditions worsen.
Steve Madsen
2010-02-16 19:10:42
A:
Video and audio streaming is not that simple. You should look at something that already exists - RTP, to know what are u trying to reinvent ;-)