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?
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.
Related
Socket Used : udp
I have a client who sends 5000 bytes and a server with this code :
Client code :
cod = sendto (sFd, (void *) buffer, 5000, 0, (struct sockaddr *)
&soc, sizeof (struct sockaddr_in));
Server code :
//leghtBuffer = 5000
while (lenghtBuffer > 0 )
{
//I will insert a signal if pass more than 30 s ...
cod = recvfrom (sFd, buffer,256 , 0, (struct sockaddr *) &clientSoc, &lungimeSocket);
printf("Am received %d bytes " ,cod );
lenghtBuffer = lenghtBuffer - cod;
}
How can I read more than 1 time 256 bytes from this while (still using Udp socket)?
UDP is a message (datagram) based transport protocol and not stream based like TCP. Each sendto/recvfrom works in terms of complete messages.
On the sending end, each call to sendto() creates a datagram of the specified size and data, which in your case is 5000 bytes.
On the receiving end, each call to recvfrom() copies the next message in the receive buffer. Since your datagrams are 5000 bytes, but you're only providing a 256 byte buffer, your datagram is being truncated to 256 bytes as it's copied.
The recvfrom() OpenGroup specification clarifies the behavior in this case:
For message-based sockets such as SOCK_DGRAM and SOCK_SEQPACKET, the entire message must be read in a single operation. If a message is too long to fit in the supplied buffer, and MSG_PEEK is not set in the flags argument, the excess bytes are discarded.
You'll want to increase your buffer on the receive end to be 5000 bytes to account for the entire datagram
I read in MSDN about the send() and recv() function, and there is one thing that I'm not sure I understand.
If I send a buffer of size 256 for example, and receive first 5 bytes, so the next time I call the recv() function, it will point to the 6th byte and get the data from there?
for example :
char buff[256];
memcpy(buff,"hello world",12);
send(sockfd, buffer, 100) //sending 100 bytes
//server side:
char buff[256];
recv(sockfd, buff, 5) // now buffer contains : "Hello"?
recv(socfd, buff,5) // now I ovveride the data and the buffer contains "World"?
thanks!
The correct way to receive into a buffer in a loop from TCP in C is as follows:
char buffer[8192]; // or whatever you like, but best to keep it large
int count = 0;
int total = 0;
while ((count = recv(socket, &buffer[total], sizeof buffer - total, 0)) > 0)
{
total += count;
// At this point the buffer is valid from 0..total-1, if that's enough then process it and break, otherwise continue
}
if (count == -1)
{
perror("recv");
}
else if (count == 0)
{
// EOS on the socket: close it, exit the thread, etc.
}
You have missed the principal detail - what kind of socket is used and what protocol is requested. With TCP, data is octet granulated, and, yes, if 256 bytes was sent and you have read only 5 bytes, rest 251 will wait in socket buffer (assuming buffer is larger, which is true for any non-embedded system) and you can get them on next recv(). With UDP and without MSG_PEEK, rest of a single datagram is lost, but, if MSG_PEEK is specified, next recv() will give the datagram from the very beginning. With SCTP or another "sequential packet" protocol, AFAIK, the same behavior as with UDP is got, but I'm unsure in Windows implementation specifics.
C++ has the following function to receive bytes from socket, it can check for number of bytes available with the MSG_PEEK flag. With MSG_PEEK, the returned value of 'recv' is the number of bytes available in socket:
#include <sys/socket.h>
ssize_t recv(int socket, void *buffer, size_t length, int flags);
I need to get the number of bytes available in the socket without creating buffer (without allocating memory for buffer). Is it possible and how?
You're looking for is ioctl(fd,FIONREAD,&bytes_available) , and under windows ioctlsocket(socket,FIONREAD,&bytes_available).
Be warned though, the OS doesn't necessarily guarantee how much data it will buffer for you, so if you are waiting for very much data you are going to be better off reading in data as it comes in and storing it in your own buffer until you have everything you need to process something.
To do this, what is normally done is you simply read chunks at a time, such as
char buf[4096];
ssize_t bytes_read;
do {
bytes_read = recv(socket, buf, sizeof(buf), 0);
if (bytes_read > 0) {
/* do something with buf, such as append it to a larger buffer or
* process it */
}
} while (bytes_read > 0);
And if you don't want to sit there waiting for data, you should look into select or epoll to determine when data is ready to be read or not, and the O_NONBLOCK flag for sockets is very handy if you want to ensure you never block on a recv.
On Windows, you can use the ioctlsocket() function with the FIONREAD flag to ask the socket how many bytes are available without needing to read/peek the actual bytes themselves. The value returned is the minimum number of bytes recv() can return without blocking. By the time you actually call recv(), more bytes may have arrived.
Be careful when using FIONREAD! The problem with using ioctl(fd, FIONREAD, &available) is that it will always return the total number of bytes available for reading in the socket buffer on some systems.
This is no problem for STREAM sockets (TCP) but misleading for DATAGRAM sockets (UDP). As for datagram sockets read requests are capped to the size of the first datagram in the buffer and when reading less than she size of the first datagram, all unread bytes of that datagram are still discarded. So ideally you want to know only the size of the next datagram in the buffer.
E.g. on macOS/iOS it is documented that FIONREAD always returns the total amount (see comments about SO_NREAD). To only get the size of the next datagram (and total size for stream sockets), you can use the code below:
int available;
socklen_t optlen = sizeof(readable);
int err = getsockopt(soc, SOL_SOCKET, SO_NREAD, &available, &optlen);
On Linux FIONREAD is documented to only return the size of the next datagram for UDP sockets.
On Windows ioctlsocket(socket, FIONREAD, &available) is documented to always give the total size:
If the socket passed in the s parameter is message oriented (for example, type SOCK_DGRAM), FIONREAD returns the reports the total number of bytes available to read, not the size of the first datagram (message) queued on the socket.
Source: https://learn.microsoft.com/en-us/windows/win32/api/ws2spi/nc-ws2spi-lpwspioctl
I am unaware of a way how to get the size of the first datagram only on Windows.
The short answer is : this cannot be done with MS-Windows WinSock2,
as I can discovered over the last week of trying.
Glad to have finally found this post, which sheds some light on the issues I've been having, using latest Windows 10 Pro, version 20H2 Build 19042.867 (x86/x86_64) :
On a bound, disconnected UDP socket 'sk' (in Listening / Server mode):
1. Any attempt to use either ioctlsocket(sk, FIONREAD, &n_bytes)
OR WsaIoctl with a shifted FIONREAD argument, though they succeed,
and retern 0, after a call to select() returns > with that
'sk' FD bit set in the read FD set,
and the ioctl call returns 0 (success), and n_bytes is > 0,
causes the socket sk to be in a state where any
subsequent call to recv(), recvfrom(), or ReadFile() returns
SOCKET_ERROR with a WSAGetLastError() of :
10045, Operation Not Supported, or ReadFile
error 87, 'Invalid Parameter'.
Moreover, even worse:
2. Any attempt to use recv or recvfrom with the 'MSG_PEEK' msg_flags
parameter returns -1 and WSAGetLastError returns :
10040 : 'A message sent on a datagram socket was larger than
the internal message buffer or some other network limit,
or the buffer used to receive a datagram into was smaller
than the datagram itself.
' .
Yet for that socket I DID successfully call:
setsockopt(s, SOL_SOCKET, SO_RCVBUF, bufsz = 4096 , sizeof(bufsz) )
and the UDP packet being received was of only 120 bytes in size.
In short, with modern windows winsock2 ( winsock2.h / Ws2_32.dll) ,
there appears to be absolutely no way to use any documented API
to determine the number of bytes received on a bound UDP socket
before calling recv() / recvfrom() in MSG_WAITALL blocking mode to
actually receive the whole packet.
If you do not call ioctlsocket() or WsaIoctl or
recv{,from}(...,MSG_PEEK,...)
before entering recv{,from}(...,MSG_WAITALL,...) ,
then the recv{,from} succeeds.
I am considering advising clients that they must install and run
a Linux instance with MS Services for Linux under their windows
installation , and developing some
API to communicate with it from Windows, so that reliable
asynchronous UDP communication can be achieved - or does anyone
know of a good open source replacement for WinSock2 ?
I need access to a "C" library TCP+UDP/IP implementation for
modern Windows 10 that conforms to its own documentation,
unlike WinSock2 - does anyone know of one ?
I was considering writing/implementing a UDP-based protocol that would use a zero-length datagram as a 'hello' message. And while I don't expect to have a problem sending a zero-length datagram, I'm not certain I can receive one.
recvfrom returns the number of bytes read, but 0 is reserved for an orderly shutdown.
read returns number of bytes read, but 0 is reserved for EOF.
select "will be watched to see if characters become available for reading".
How would one detect the receipt of a zero-length datagram?
When calling recvfrom on a TCP Socket, you will receive a zero byte read if a FIN packet has been received (an orderly shutdown). UDP has no concept of orderly shutdowns, and no data is transmitted from the sender to receiver to indicate a socket being closed. The protocol is completely stateless and every datagram received is independent from the receiver's point of view. As such, I am not aware of any scenerios in which a zero byte return code from recvfrom on a UDP socket would be caused by anything other than a zero length datagram being received.
For udp, a normal call to recvfrom will return 0 when receiving a udp packet with 0 length payload (see Under Linux, can recv ever return 0 on UDP?).
You can test this by doing a simple sendto/recvfrom test:
const int howManyBytesToSend = 0;
if(sendto(sock, buf, howManyBytesToSend, 0, (struct sockaddr*) &addr, addrlen) < 0)
{
return EXIT_FAILURE;
}
if((recv_len = recvfrom(sock, buf, sizeof(buf), 0, (struct sockaddr *) &addr, (socklen_t*)&addrlen)) < 0)
{
return EXIT_FAILURE;
}
The documentation you are quoting is from the man page for recvfrom: "returns the number of bytes read, but 0 is reserved for an orderly shutdown". That statement applies only to TCP.
Am back with C sockets question.
I am trying to receive a char array from a client via TCP. I have the following recv code:
char buffer[2048];
int recvBytes = 0;
while (1) {
if ((clntSockfd = accept(servSockfd, (struct sockaddr *) &clntAddr, &clntSockAddrLen)) == -1) {
printf("Unable to accept client connection\n");
exit(1);
}
else {
printf("Client connection accepted!\n");
}
/* clear buffer */
memset(buffer, 0, sizeof(buffer));
recvBytes = recv (clntSockfd, buffer, sizeof(buffer), 0);
printf("Bytes received: %i\n", recvBytes);
printf("Char array received: %s\n", buffer);
}
I noted that upon execution, recvBytes shows zero in the first iteration. It's only after the second iteration that it picks up the incoming char array.
I would like to find out will recv block until I receive data from the incoming socket? How should I discard the unwanted chars in the buffer - i.e. drop the chars received from the first iteration.
Many thanks!
-- edit ---
Hi all, I have appended the console output from eclipse.
**... <- initialization stuff
Binding socket to port
Socket binded
Start listening on port 8081.
Client connection accepted! *while loop - first iteration
Bytes received: 0 *while loop - first iteration
Char array received: *while loop - first iteration
Client connection accepted! *while loop - second iteration
Bytes received: 22 *while loop - second iteration
Char array received: 1~Message~HowAreYou? *while loop - second iteration**
Hope the above console output illustrates my questions clearer, regarding the first and second iterations. From the above, the first iteration is not receiving any bytes but recv does not block. I thought recv was supposed to block until it receives bytes?
I believe the recv only returns 0 if the remote end closes the connection (for stream sockets such as TCP) or if a packet with no payload is received (datagram sockets such as UDP).
If the socket has been set to non-blocking mode (default is blocking), and there's no data yet, you'd get an error code, either EAGAIN or EWOULDBLOCK depending on the OS.
In any case, each time recv returns, the new data will be stored at the beginning of the buffer. It won't append to previously received data unless you calculate a pointer designed to store new data after the old.
If your socket is a blocking socket, then recv function will block till you get some data. recv function will return 0 only when the other side closes the connection on most systems.
I suggest you recheck your code and execution and let us know the exact output.
Refer here and here for more details.
If you know what to expect of the data that you receive you can drop the first set of characters. For example if you know what will the length of the packet be or the source of the message or the header information then you can validate and ignore the first set of characters.