I'm investigating using UDP instead of TCP for our system communication
to reduce network overhead and traffic, and I have a couple of
questions.
Am I correct in assuming that UDP is also a stream protocol just as
TCP?
Assume a UDP socket is opened with -1 as the remote IP, meaning that
"all hosts can send datagrams to the socket." Two hosts each send a
"datagram" to the socket, and one of the host's datagram is split
between two packets. Is it possible for one host's datagram to be
received between the two packets of the other host's datagram?
Steve
UDP vs TCP
Started by ●November 29, 2011
Reply by ●November 29, 20112011-11-29
> Am I correct in assuming that UDP is also a stream
protocol just as
> TCP?
No, UDP is a datagram protocol (hence the name: User Datagram Protocol). The only service provided by the lower network layers is reassembly of packets. So if you sent a 3000 bytes message (datagram) on a link that has 1500 MTU, your datagram will be split and reassembled by the receiving side. If one fragment is lost, the whole datagram is lost (haven't tried that on Rabbits, but that's the expected behavior).
> Is it possible for one host's datagram to be
> received between the two packets of the other host's datagram?
On other TCP stacks the answer is no: the first packet of the first host would stay in the buffers until the whole datagram is assembled. You would receive the datagram from the 2nd host then the whole datagram from the 1st host. Again this is very much implementation dependent. Because the stack doesn't do any promise of integrity, it is free to drop the first fragment when it receives the 2nd one if it runs out of buffers. The 2nd fragment would then be discarded as out of order.
That being said, it is a bit unusual to use large datagrams in UDP. Given that fragments can and do get lost, it can be expensive to send a 10k datagram just to discover that you have to resend the whole thing.
I don't know anything about your protocol but in many cases you can structure it in small independent pieces that each fit within the channel MTU. In those cases UDP is just great with very little overhead and latency issues. I've used it a lot on Rabbit without any problem.
Mircea
--- In r..., "seecwriter" wrote:
>
> I'm investigating using UDP instead of TCP for our system communication
> to reduce network overhead and traffic, and I have a couple of
> questions.
>
> Am I correct in assuming that UDP is also a stream protocol just as
> TCP?
>
> Assume a UDP socket is opened with -1 as the remote IP, meaning that
> "all hosts can send datagrams to the socket." Two hosts each send a
> "datagram" to the socket, and one of the host's datagram is split
> between two packets. Is it possible for one host's datagram to be
> received between the two packets of the other host's datagram?
>
> Steve
>
> TCP?
No, UDP is a datagram protocol (hence the name: User Datagram Protocol). The only service provided by the lower network layers is reassembly of packets. So if you sent a 3000 bytes message (datagram) on a link that has 1500 MTU, your datagram will be split and reassembled by the receiving side. If one fragment is lost, the whole datagram is lost (haven't tried that on Rabbits, but that's the expected behavior).
> Is it possible for one host's datagram to be
> received between the two packets of the other host's datagram?
On other TCP stacks the answer is no: the first packet of the first host would stay in the buffers until the whole datagram is assembled. You would receive the datagram from the 2nd host then the whole datagram from the 1st host. Again this is very much implementation dependent. Because the stack doesn't do any promise of integrity, it is free to drop the first fragment when it receives the 2nd one if it runs out of buffers. The 2nd fragment would then be discarded as out of order.
That being said, it is a bit unusual to use large datagrams in UDP. Given that fragments can and do get lost, it can be expensive to send a 10k datagram just to discover that you have to resend the whole thing.
I don't know anything about your protocol but in many cases you can structure it in small independent pieces that each fit within the channel MTU. In those cases UDP is just great with very little overhead and latency issues. I've used it a lot on Rabbit without any problem.
Mircea
--- In r..., "seecwriter" wrote:
>
> I'm investigating using UDP instead of TCP for our system communication
> to reduce network overhead and traffic, and I have a couple of
> questions.
>
> Am I correct in assuming that UDP is also a stream protocol just as
> TCP?
>
> Assume a UDP socket is opened with -1 as the remote IP, meaning that
> "all hosts can send datagrams to the socket." Two hosts each send a
> "datagram" to the socket, and one of the host's datagram is split
> between two packets. Is it possible for one host's datagram to be
> received between the two packets of the other host's datagram?
>
> Steve
>
Reply by ●November 29, 20112011-11-29
Thanks. Lots of good information.
--- In r..., "Mircea" wrote:
>
> > Am I correct in assuming that UDP is also a stream protocol just as
> > TCP?
> No, UDP is a datagram protocol (hence the name: User Datagram Protocol). The only service provided by the lower network layers is reassembly of packets. So if you sent a 3000 bytes message (datagram) on a link that has 1500 MTU, your datagram will be split and reassembled by the receiving side. If one fragment is lost, the whole datagram is lost (haven't tried that on Rabbits, but that's the expected behavior).
>
> > Is it possible for one host's datagram to be
> > received between the two packets of the other host's datagram?
>
> On other TCP stacks the answer is no: the first packet of the first host would stay in the buffers until the whole datagram is assembled. You would receive the datagram from the 2nd host then the whole datagram from the 1st host. Again this is very much implementation dependent. Because the stack doesn't do any promise of integrity, it is free to drop the first fragment when it receives the 2nd one if it runs out of buffers. The 2nd fragment would then be discarded as out of order.
>
> That being said, it is a bit unusual to use large datagrams in UDP. Given that fragments can and do get lost, it can be expensive to send a 10k datagram just to discover that you have to resend the whole thing.
>
> I don't know anything about your protocol but in many cases you can structure it in small independent pieces that each fit within the channel MTU. In those cases UDP is just great with very little overhead and latency issues. I've used it a lot on Rabbit without any problem.
>
> Mircea
>
> --- In r..., "seecwriter" wrote:
> >
> > I'm investigating using UDP instead of TCP for our system communication
> > to reduce network overhead and traffic, and I have a couple of
> > questions.
> >
> > Am I correct in assuming that UDP is also a stream protocol just as
> > TCP?
> >
> > Assume a UDP socket is opened with -1 as the remote IP, meaning that
> > "all hosts can send datagrams to the socket." Two hosts each send a
> > "datagram" to the socket, and one of the host's datagram is split
> > between two packets. Is it possible for one host's datagram to be
> > received between the two packets of the other host's datagram?
> >
> > Steve
>
--- In r..., "Mircea" wrote:
>
> > Am I correct in assuming that UDP is also a stream protocol just as
> > TCP?
> No, UDP is a datagram protocol (hence the name: User Datagram Protocol). The only service provided by the lower network layers is reassembly of packets. So if you sent a 3000 bytes message (datagram) on a link that has 1500 MTU, your datagram will be split and reassembled by the receiving side. If one fragment is lost, the whole datagram is lost (haven't tried that on Rabbits, but that's the expected behavior).
>
> > Is it possible for one host's datagram to be
> > received between the two packets of the other host's datagram?
>
> On other TCP stacks the answer is no: the first packet of the first host would stay in the buffers until the whole datagram is assembled. You would receive the datagram from the 2nd host then the whole datagram from the 1st host. Again this is very much implementation dependent. Because the stack doesn't do any promise of integrity, it is free to drop the first fragment when it receives the 2nd one if it runs out of buffers. The 2nd fragment would then be discarded as out of order.
>
> That being said, it is a bit unusual to use large datagrams in UDP. Given that fragments can and do get lost, it can be expensive to send a 10k datagram just to discover that you have to resend the whole thing.
>
> I don't know anything about your protocol but in many cases you can structure it in small independent pieces that each fit within the channel MTU. In those cases UDP is just great with very little overhead and latency issues. I've used it a lot on Rabbit without any problem.
>
> Mircea
>
> --- In r..., "seecwriter" wrote:
> >
> > I'm investigating using UDP instead of TCP for our system communication
> > to reduce network overhead and traffic, and I have a couple of
> > questions.
> >
> > Am I correct in assuming that UDP is also a stream protocol just as
> > TCP?
> >
> > Assume a UDP socket is opened with -1 as the remote IP, meaning that
> > "all hosts can send datagrams to the socket." Two hosts each send a
> > "datagram" to the socket, and one of the host's datagram is split
> > between two packets. Is it possible for one host's datagram to be
> > received between the two packets of the other host's datagram?
> >
> > Steve
>
Reply by ●November 29, 20112011-11-29
On 11/29/2011 12:39 PM, Mircea wrote:
>> Am I correct in assuming that UDP is also a stream protocol just as
>> > TCP?
> No, UDP is a datagram protocol (hence the name: User Datagram Protocol). The only service provided by the lower network layers is reassembly of packets. So if you sent a 3000 bytes message (datagram) on a link that has 1500 MTU, your datagram will be split and reassembled by the receiving side. If one fragment is lost, the whole datagram is lost (haven't tried that on Rabbits, but that's the expected behavior).
>
Note: the Rabbit stack can send large UDP messages (I have done 6kb) but
it can not reassemble them on rteceive.
I looked at the stack and they had added an IP "preprocessor" to speed
up TCP streams. It drops UDP packets as they are not part of known TCP
connection so they are not passed on to the UDP layer. It may have been
fixed in recent stacks but i doubt it.
UDP is much more flexible but packets can be lost and you need to handle
retries. It is easy for multiple devices to talk to the Rabbit. I have
one PC app that has 3 USP sockets that talk to one Rabbit. All 3 send a
packet and wait for a response (with retries if needed.) The Rabbit side
has just one socket and responds to all 3 PC sockets; get a packet,
process it and send back to PC socket (source port will be different on
PC side.) Makes rabbit side simple rather than having 3 TCP sockets to
process.
--
------
Scott G. Henion, Consultant
Web site: http://SHDesigns.org
------
>> Am I correct in assuming that UDP is also a stream protocol just as
>> > TCP?
> No, UDP is a datagram protocol (hence the name: User Datagram Protocol). The only service provided by the lower network layers is reassembly of packets. So if you sent a 3000 bytes message (datagram) on a link that has 1500 MTU, your datagram will be split and reassembled by the receiving side. If one fragment is lost, the whole datagram is lost (haven't tried that on Rabbits, but that's the expected behavior).
>
Note: the Rabbit stack can send large UDP messages (I have done 6kb) but
it can not reassemble them on rteceive.
I looked at the stack and they had added an IP "preprocessor" to speed
up TCP streams. It drops UDP packets as they are not part of known TCP
connection so they are not passed on to the UDP layer. It may have been
fixed in recent stacks but i doubt it.
UDP is much more flexible but packets can be lost and you need to handle
retries. It is easy for multiple devices to talk to the Rabbit. I have
one PC app that has 3 USP sockets that talk to one Rabbit. All 3 send a
packet and wait for a response (with retries if needed.) The Rabbit side
has just one socket and responds to all 3 PC sockets; get a packet,
process it and send back to PC socket (source port will be different on
PC side.) Makes rabbit side simple rather than having 3 TCP sockets to
process.
--
------
Scott G. Henion, Consultant
Web site: http://SHDesigns.org
------
Reply by ●November 29, 20112011-11-29
The BACnet stack (www.bacrabbit.sourceforge.net) works the same way, it uses a
single UDP socket and can handle requests from several sources. It looks after
retries and has sequence numbering to match requests and responses.
It might be a good match for your application depending onthe type of data you need to transfer.
Regards,
Peter
--- In r..., Scott Henion wrote:
>
> On 11/29/2011 12:39 PM, Mircea wrote:
> >> Am I correct in assuming that UDP is also a stream protocol just as
> >> > TCP?
> > No, UDP is a datagram protocol (hence the name: User Datagram Protocol). The only service provided by the lower network layers is reassembly of packets. So if you sent a 3000 bytes message (datagram) on a link that has 1500 MTU, your datagram will be split and reassembled by the receiving side. If one fragment is lost, the whole datagram is lost (haven't tried that on Rabbits, but that's the expected behavior).
> > Note: the Rabbit stack can send large UDP messages (I have done 6kb) but
> it can not reassemble them on rteceive.
>
> I looked at the stack and they had added an IP "preprocessor" to speed
> up TCP streams. It drops UDP packets as they are not part of known TCP
> connection so they are not passed on to the UDP layer. It may have been
> fixed in recent stacks but i doubt it.
>
> UDP is much more flexible but packets can be lost and you need to handle
> retries. It is easy for multiple devices to talk to the Rabbit. I have
> one PC app that has 3 USP sockets that talk to one Rabbit. All 3 send a
> packet and wait for a response (with retries if needed.) The Rabbit side
> has just one socket and responds to all 3 PC sockets; get a packet,
> process it and send back to PC socket (source port will be different on
> PC side.) Makes rabbit side simple rather than having 3 TCP sockets to
> process.
>
> --
> ------
> Scott G. Henion, Consultant
> Web site: http://SHDesigns.org
> ------
>
It might be a good match for your application depending onthe type of data you need to transfer.
Regards,
Peter
--- In r..., Scott Henion wrote:
>
> On 11/29/2011 12:39 PM, Mircea wrote:
> >> Am I correct in assuming that UDP is also a stream protocol just as
> >> > TCP?
> > No, UDP is a datagram protocol (hence the name: User Datagram Protocol). The only service provided by the lower network layers is reassembly of packets. So if you sent a 3000 bytes message (datagram) on a link that has 1500 MTU, your datagram will be split and reassembled by the receiving side. If one fragment is lost, the whole datagram is lost (haven't tried that on Rabbits, but that's the expected behavior).
> > Note: the Rabbit stack can send large UDP messages (I have done 6kb) but
> it can not reassemble them on rteceive.
>
> I looked at the stack and they had added an IP "preprocessor" to speed
> up TCP streams. It drops UDP packets as they are not part of known TCP
> connection so they are not passed on to the UDP layer. It may have been
> fixed in recent stacks but i doubt it.
>
> UDP is much more flexible but packets can be lost and you need to handle
> retries. It is easy for multiple devices to talk to the Rabbit. I have
> one PC app that has 3 USP sockets that talk to one Rabbit. All 3 send a
> packet and wait for a response (with retries if needed.) The Rabbit side
> has just one socket and responds to all 3 PC sockets; get a packet,
> process it and send back to PC socket (source port will be different on
> PC side.) Makes rabbit side simple rather than having 3 TCP sockets to
> process.
>
> --
> ------
> Scott G. Henion, Consultant
> Web site: http://SHDesigns.org
> ------
>
