TCP vs UDP?

[Winglet]

I havn't really understood the differences (except some of the programatically differences) between the CSock functions Send() and SendDatagram(), TCP/UDP.

What would be most suitable (if any specific pros/cons) for streaming images?

Thanks
Fred

[TheCPUWizard]

TCP guarantees that each byte is delivered once and only once in the same order as it was transmitted (or it raises an error)

UDP may deliver the bytes in any order, with items dropped or duplicated at will.

BOTH may PAD (Packet Assembly & Disassemble at will. So

You may trnsmit a packet of 500 bytes, and recieve 100 bytes in a packet followed by 400 bytes.. or any combination of splits.

You may transmit a packet of 100 bytes followed by a packet of 400 bytes and recieve a single packet of 500 bytes, or a packet of 250 bytes followed by another 250 bytes packet.

etc.etc.etc.

[Richard.J]

I don't think that UDP can pad.

For streaming images, UDP as the underlying protocol for RTP would be the correct choice.

[Winglet]

Well, how do you distinguish duplicate bytes from bytes being sent for the first time? Since Send() and Recv() are simple when you know the image byte size and just have to count when the sum of bytes received equals total bytes.

Why would UDP be the choice for streaming images over TCP? Is there a transfer rate benefit with UDP over TCP?

Thanks for your replies.
Frederik

[Richard.J]

duplicates must be distinguished by a sequence number.

I suggested RTP as I assumed streaming images has to do with realtime video, and the the Realtime Transport Protocol came into my mind.

[Winglet]

Thanks to the quick reply. I guess I have some reading to do. Would a sequence number be something I can put in as a preceeding number to every package?

[MikeAThon]

BOTH [TCP and UDP] may PAD (Packet Assembly & Disassemble at will. So You may trnsmit a packet of 500 bytes, and recieve 100 bytes in a packet followed by 400 bytes.. or any combination of splits. You may transmit a packet of 100 bytes followed by a packet of 400 bytes and recieve a single packet of 500 bytes, or a packet of 250 bytes followed by another 250 bytes packet.
I agree with Richard J. on this issue. UDP is message-based and will not do this. "PAD" is, in fact, a property of TCP, which is stream-based, but it is not a property of UDP.

[Edders]

Would a sequence number be something I can put in as a preceeding number to every package?Yes, you just add a header to the start of each UDP packet of which one of the fields is your sequence number.

This number allows you to re-order packets (so that they are in the same order as they were sent in), you can detect that you received the same packet multiple times or that you've missed one.

Even if you do not want to implement the full RTP standard, you still may want to have a look at the headers used to see which fields make sense for your application.

[TheCPUWizard]

I don't think that UDP can pad.

For streaming images, UDP as the underlying protocol for RTP would be the correct choice.

Packet Assembly/Disassembly is totally independant of the protocol. In fact, it is actually possible for a router to split and/or join packets. (There are some overhead issues with this in keeping the stream coherent, but there is nothing "illegal" about it).