7

I've created some type of client/server application that has its own data ACK system. It was originally written in TCP because of some limitations, but the base was written thinking about UDP.

The packets that I sent to the server had their own encapsulation (packet id and packet size headers. I know that UDP has also a checksum so I didn't add a header for that), but how TCP works, I know that the server may not receive the entire packet, so I gathered and buffered the data received until a full valid packet was received.

Now I have the chance to change my client/server program to UDP, and I know that one difference with TCP is that data is not received in the same order as sent (which is why I added a packet id header).

The thing that I want to know is: If I send multiple packets, will they be received with no guaranteed order but with guaranteed encapsulation? I mean, if I send a packet sized 1000 bytes of data and another packet sized 400 bytes of data later, will the server receive 2 packets, one of 1000 bytes and another one of 400 bytes, or is there a chance to receive 200 of that 1000 bytes, then 400 bytes of that 1000 bytes and later the rest of the bytes like TCP does?

Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156
Jorge Fuentes González
  • 11,568
  • 4
  • 44
  • 64
  • You really shouldn't use the word "packet" to refer to so many different things. Protocol data units that might be sent in any number of packets should be called "messages". – David Schwartz Apr 29 '15 at 18:29
  • 1
    Well, I'm calling them packets in the application layer, and, as I read everywhere (including wiki), that's how people understand them when talking in this layer. I see them talking about messages when they also talk about the transport layer and have to difference between messages and packets. – Jorge Fuentes González Apr 30 '15 at 22:36
  • The computer science definition of a packet is, "the unit of data that is routed between an origin and a destination on the Internet or any other packet-switched network." It's true that the word is sometimes used to mean something else, but when you're talking about systems involving actual packets, it causes confusion to use the same word to mean two totally different things. – David Schwartz May 03 '15 at 10:21

2 Answers2

18

UDP is a datagram service. Datagrams may be split for transport, but they will be reassembled before being passed up to the application layer.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278
2

With small packet sizes you should have no concern that packets will be broken into multiple packets. That generally is only an issue when the packet gets over an Ethernet network.

You ask" will the server receive 2 packets, one of 1000 bytes and another one of 400 bytes, or there's a chance to receive 200 of that 1000 bytes, then 400 bytes of that 1000 bytes and later the rest of the bytes like TCP can do?

With a packet size of under 1492 bytes there is not going to be any partial packets.

UPDATE:
Apparently I see a need to clarify why I say UDP packet lengths 1492 bytes or less will not affect transport robustness.

The maximum UDP length as implicitly specified in RFC 768 is 65535 including the 8 byte Header. Max Payload Frame Length is 65527 bytes.

While this should not be disputed number the UDP data length is often reported incorrectly. This is exemplified in a previous post:

What is the largest Safe UDP Packet Size on the Internet

A data packet is not constrained by the MTU of the underlying network ToS or communications protocol's Frame length (e.g. IP and Ethernet respectively). Discrepancies between MTU and Protocol Lengths are remedied by Fragmentation and Reassembly

At the Transport Layer each network Type of Service (ToS) has a specific Maximum Transmission Unit (MTU). UDP is encapsulated within IP Packets and IP Packets are encapsulated by the transporting Network's ToS. IP packets are often transmitted through networks of various ToS which include Ethernet, PPP, HDLC, and ADCCP.

When the MTU for a receiving Network ToS is less than the sending ToS then the receiving network must Fragment the received packet. When the Network sends a packet to a network with a higher MTU, the receiving Network must reassemble any Fragmented packets.

Ethernet is the defacto mainstream protocol with the lowest MTU. Non-Mainsteam Arcnet the MTU is 507 bytes. The practical lowest MTU is Ethernet's 1500 bytes, minus the overhead makes maximum payload length 1492 bytes.

If the UDP packet has more than 1492 bytes the data packet will likely be Fragmented and Reassembled. The Fragment and Reassembly adds complexity to the already complex process coupling UDP and IP, and therefore should be avoided.

Because UDP is a non-guaranteed datagram delivery protocol it boosts the transport performance. Robustness is left to the originating and terminating Application. RFC 1166 sets the standards for the communication protocol link layer, IP layer, and transport layer, the UDP Application is responsible for packetization, reassembly, and flow control.

The maximum UDP packet size can also be lowered by a Communication Host's Application Layer. The packet length is a balance between performance and robustness.

The Communications Host's Application Layer may set a maximum UDP packet size. The typical UDP max data length at the Application layer will use the maximum allowed by the IP protocol or the Host Data Link Layer, typically Ethernet.

It is the Application's programer that chooses to use the Host Application Layer or the Host Data Link layer. The Host Application Layer will detect UDP packet errors and discard the packet if necessary. When the application communicates directly with the Host Data Link, the application then has the responsibility of detecting packet errors.

Using maximum UDP data packet length of Ethernet's max payload length of 1492 bytes will eliminate the issues of Fragmentation and Delivery Order of multiple Frames.

That is why I said packet length is not a Fragmentation issue with packet lengths of 1000 and 400 bytes.

###

I do not know what you mean by "guaranteed encapsulation", it makes no sense to me.

With IP there is no guarantee of packet delivery of the order whether UDP or TCP.

As long as you control both sides of the conversation, you can work out your own protocol within the data packet to handle ordering and post packets. Reserve the first x bytes of the packet for a sequential order number and total number of packets. (e.g. 1 of 3, 2 of 2, 3 of 3). If the client side is missing a packet then the client must send a request for retransmission. You need to determine to what level you are going to go for data integrity. like maybe the re-transmission packet is lost.

That may be what you meant by "guaranteed encapsulation", Where there is other information within your datagram packet to ensure some integrity. You should add your own CRC for the total data being sent if broken into multiple datagrams. the checksum is not very robust and is only for the one packet.

UDP is much faster then TCP but TCP has flow control and guaranteed delivery.

UDP is good for streaming content like voice where a lost packet is not going to matter.

Network reliability has improved a lot since the days when these issues were a major concern.

Community
  • 1
  • 1
Misunderstood
  • 5,534
  • 1
  • 18
  • 25
  • With guaranteed encapsulation I was talking about packet divison, guaranteed entire packet received in my program without needs of buffering until an entire packet is received. Ive already worked my own functional ordering protocol, so that part is fine. You talk about partial packets. will those packets be delivered to my program before receiving the entire packet? edit: the downvote is not mine. – Jorge Fuentes González Feb 03 '15 at 01:50
  • UDP does not require an application layer. The way you described what you are doing I assumed you were building your own UDP datagrams at the transport layer, bypassing any Host Layers where the Application Layer (the highest layer) resides. My expertise is at the data link layer where I designed MAC Layer IC's for 802.3, 802.4, 802.5, and 802.6. back in the 1980's for IBM, GE, GM, and Ungerman Bass. More recently, about 15 years ago I created a UDP server with an Atmel micro controller. Down Votes are due to ignorance. In the 80's I was a EE specializing in Voice and Data networking. – Misunderstood Feb 03 '15 at 02:32
  • No, my downvote was due to the fact that you didn't actually answer the question, and instead posted a lot of irrelevant information, a fault which you repeated in your comment. – user207421 Feb 03 '15 at 02:51
  • @EJP What did I not answer? The OP asked if there was a chance of receiving packets broken into smaller chunks. That is only a possibility if the data packet gets routed over Ethernet and the packet is larger than 1492 bytes, the max number of bytes for some Ethernet packets. It would be vary rare, due to a network glitch, but possible. The rest had to do with the OP's encapsulation scheme. – Misunderstood Feb 03 '15 at 03:31
  • it isn't a possibility at all in UDP. Either the whole datagram arrives at the application, or none of it, regardless of what may or may not have happened to it *en route*. That's what he's asking, and that's what you haven't answered. – user207421 Feb 03 '15 at 04:38
  • @Misunderstood I think I should have added a bit more info. Is a simple program made in node.js, not working at the transport layer. Btw thank you for the info. Now I know a bit more about all this. – Jorge Fuentes González Feb 03 '15 at 13:34
  • node.js does not set a max data length but in this link: http://nodejs.org/api/dgram.html They recommend an antiquated dial up max length of 576 bytes for IPv4 and 1500 bytes for IPv6. The 1500 does not include the Ethernet overhead. The max recommended UDP data length including the UDP 8 byte header is therefore 1492 or a UDP payload length of 1484 bytes. – Misunderstood Feb 03 '15 at 19:28
  • @EJP I have added an update to my answer which references a post where you incorrectly commented on an answer regarding an MS Windows 2000 Application Layer Getsockopt() where MS specified their max packet length of 65507 bytes. You said _"A Microsoft link is not a normative reference. The RFCs are the normative reference; and what you have quoted applies to IPv4 only"_ RFC768 implicitly specifies a UDP max length of 65527 bytes. IPv4 and IPv6 cannot constrain a communication protocol's max length but must rather Fragment larger packet lengths and therefore not applicable to the answer. – Misunderstood Feb 03 '15 at 19:42
  • Note that the 1484 length has a name, it's called the MSS (Maximum Segment Size), opposed to the MTU (Maximum Transmission Unit). – Alexis Wilke Sep 22 '20 at 03:02
  • Not sure why this answer doesn't have more upvotes, but it's a big help to me, thanks. – Mladen Mihajlovic Feb 27 '23 at 11:04