On Mon, Sep 21, 2015 at 10:19 AM, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote: > Even if the IP layer has to fragment a UDP packet to meet limits of > the > transport media, it should put them back together on the other end before > passing it up to the UDP layer. To my knowledge, UDP does not have a size > limit on the message (well -- a 16-bit length field in the UDP header). But > since it /is/ "got it all" or "dropped" with no inherent confirmation, one > would have to embed their own protocol within it -- sequence numbers with > ACK/NAK, for example. Problem: if using LARGE UDP packets, this protocol > would mean having LARGE resends should packets be dropped or arrive out of > sequence (and since the ACK/NAK could be dropped too, you may have to > handle the case of a duplicated packet -- also large). >
If you're going to add sequencing and acknowledgements to UDP, wouldn't it be easier to use TCP and simply prefix every message with a two-byte length? UDP is great when order doesn't matter and each packet stands entirely alone. DNS is a well-known example - the question "What is the IP address for www.rosuav.com?" doesn't in any way affect the question "What is the mail server for gmail.com?", so you fire off UDP packets for each one, and get responses whenever you get them. UDP's also perfect for a heartbeat system - you send out a packet every however-often, and if the monitor hasn't heard from you in X seconds, it starts alerting people. No need for responses of any kind there. But for working with a stream, I usually find it's a lot easier to build on top of TCP than UDP. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
