2

in C recvfrom can be used to read UDP messages form a socket as such:

int length = recvfrom(socket, buffer, max_length, 0, NULL, 0);

max_length only tells the maximum number of bytes the buffer can hold, and not the actual length of course.

Assume my message is the following and is sent with sendto:

char *message = "hi";
sendto(sock, message, strlen(message), 0, NULL, 0);

Now recvfrom will immediately stop reading after the i character is received. length will be set to 2. How does it know when to stop?

does sendto append any data to the packet with result of strlen saying what the data length is? or does it look for null terminating char?

Dan
  • 2,694
  • 1
  • 6
  • 19
  • UDP or TCP? It makese a difference. For UDP each recv gets a UDP packet. For TCP it is stream based and each recv call can receive any number of bytes (up to max of what has been sent of course) - it is not a one to one correlation between send and recv calls. It is up to your application to define message boundaries and to keep calling recv until the required number of bytes have been received. – kaylum Sep 13 '21 at 01:08
  • That depends on the protocols. The IP protocol can hold packet sizes, the UDP header holds a packet size, TCP does as well, and a push (P) flag can split up buffers. This is all very dependent of the network stack implementations of the systems involved. – Cheatah Sep 13 '21 at 01:14
  • This example is for UDP. To me it either has to be a null terminating char or the packet has the info. There is no other way recvfrom could know where to stop. – Dan Sep 13 '21 at 01:15
  • The UDP packet header contains the size, and that should cause the network stack to offer the packet to the `recvfrom` call with the correct size. – Cheatah Sep 13 '21 at 01:24
  • It deoesn't 'read packets' at all. It reads from the socket receive buffer. In TCP it can read the entire buffer, if it will fit into the application buffer: in UDP it can read one datagram, if there is one. There is no 'null terminating char', of course, as that could occur in any payload, and of course there is information in the buffer about how full it is, and in the case of UDP where the datagram boundaries are. – user207421 Sep 13 '21 at 01:27
  • Thanks for all the information. So data is pre-embedded in the packet. Could some one please add it as an actual answer so I can mark it? – Dan Sep 13 '21 at 01:30

2 Answers2

4

Unlike a TCP socket which is stream based, UDP sockets are datagram based.

That means that a single call to sendto will send one UDP datagram and a single call to recvfrom will receive a single UDP datagram. This also means that the buffer supplied to recvfrom should be large enough to hold a single datagram. If it is not large enough, any bytes from that datagram that don't fit in the buffer will be discarded.

dbush
  • 205,898
  • 23
  • 218
  • 273
  • So the entire data will be within a single datagram, but could be in multiple packets, and the total data size is pre-embedded in the datagram? – Dan Sep 13 '21 at 02:36
  • 2
    @Dan The UDP datagram could potentially be spread across multiple IP packets if there's fragmentation, in which case the IP layer in the kernel will do the necessary reassembly. However, as long as what's sent isn't too big that shouldn't happen. In any case, the kernel knows based on what it's read from the network how many bytes there are. From the user side of things, all you really need to know is that a single `recvfrom` corresponds to a single `sendto`. – dbush Sep 13 '21 at 02:41
  • For UDP. For TCP that does not hold. For clarity. – user207421 Sep 13 '21 at 04:02
-1

recvfrom will also return at the first null received.

If hi/00/there is sent, the buffer will only contain hi

John Schmidt
  • 1
  • Welcome to StackOverflow. It appears your answer is more or less in addition to or an extension of dbush's answer above. If so, please consider deleting this answer and adding a comment to their answer since on it's own this doesn't answer the question asked. – Edward Severinsen Apr 21 '23 at 05:13
  • As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Apr 21 '23 at 05:14