tags:

views:

575

answers:

5

Let's say my program sends a 1000 bytes over the network (UDP). Does it guaranteed that the receiver will receive the 1000 bytes in one "batch"? Or perhaps he will need to perform sevral "reads" until he'll receive the entire message? if the later is true, how can i ensure that the order of the packets for the same message don't get "mixed up" (in order), or perhaps the protocol guarantees it?
Edit: that is, does it possible that my message will be split to sevral packets? (what if i try to send a 10000mb message, what happens then?)

+1  A: 

Data sent using UDP is grouped in packets, so if you send x amount of bytes then IF the receiver receives the packet he'll receive x amount of bytes.

However, your packets might not even arrive, or they may arrive out of order.

Chaoz
but is it possible that the program will first see it have only 500 bytes available and after a while it receive the other 500 bytes?
and what if my message size of 1 million bytes long .. what then? (thanks)
Nope, it's not!
Chaoz
I guess it should work with 1million as well; but it's not recommended.
Chaoz
is there any limit at all..?
The length field is a 16 bit number so 64k minus space for IP and UDP headers is a hard limit.
Grumdrig
My bad, didn't know that :P
Chaoz
so what will happen when i'll try to send a message larger then that? i won't be able to send it in the first place?
Then you should send the data in multiple packets; once you verify that the you've received all the packets you can then iterate over all of them and extract the contents to reproduce the original file.
Chaoz
A: 

UDP, unlike TCP, is not a reliable protocol. It provides no built in mechanism to ensure that the packets arrive in the proper order, or even arrive at all. That said, you can write your send/recv routines in a lock step fashion, where every time a packet is sent, the sender must wait to receive an ACK before sending again. If an ACK is not received after some specified timeout, the packet must be resent. This way you ensure that packets are received in the proper order. (For more information, check out the RFC for the TFTP protocol, which uses this strategy.)

Finally, if possible, you may want to consider using TCP instead.

Charles Salvia
+2  A: 

The receiver will get the entire packet in one call. The packet length is limited, even in theory:

Length A 16-bit field that specifies the length in bytes of the entire datagram: header and data. The minimum length is 8 bytes since that's the length of the header. The field size sets a theoretical limit of 65,535 bytes (8 byte header + 65527 bytes of data) for a UDP datagram. The practical limit for the data length which is imposed by the underlying IPv4 protocol is 65,507 bytes.

However the real limit is much much lower, usually is safe to assume 512 bytes. See What is the largest Safe UDP Packet Size on the Internet.

Remus Rusanu
so what will happen if ill try to send 1024 bytes? i'll get an error on send or will my message be splited to different packets? (and the order when be kept between them?)
The 512 is minimum *safe* size. 1024 may succeed. Or error during send at best. Worse, the packet will be dropped by some router in traffic and you'll never know. There is no fragmentation and reconstruction with UDP, that's what TCP is for.
Remus Rusanu
Remus: That is wrong. Fragmentation and reassembly is done at the IP level, which means it applies to UDP. With UDP, you will either see the whole datagram correctly assembled as it was sent, or nothing at all. TCP additionally adds ordering and acknowledgement/retransmission.
caf
+5  A: 

You will get it all or nothing.

But there is no particular guarantee that you will receive packets exactly once in the order they were transmitted; packet loss, reordering and (less often) duplication are all possible.

There is a maximum frame size (of 65,507 bytes), send()ing packets of larger sizes will return an error.

You must provide enough buffer to receive the entire frame in one call.

UDP packets CAN be fragmented into multiple IP fragments, but the OS will drop an incomplete packet. This is therefore transparent to the application.

MarkR
A: 

With UDP Lite you can request to receive partially corrupted packets. This can be useful for video and VoIP services.

Steve-o