In C, for a socket, does recvmsg() have a queue?

Question

If a C socket's recvmsg() has a queue, how can I find out how many items are backlogged in the queue?

My problem is that the speed of the code after I receive something from recvmsg() is sometimes slower than the rate of data sent to recvmsg(), which would logically result in a queue? What happens if the queue becomes too big?

For example if this is my recv() code:

while (recvmsg(SocketA,...) > 0)
{
    ...
    ...something that takes 1.5 seconds to execute/complete...
    ...
}

and if the following function somewhere else gets called every 1 second:

// gets called every 1 second
int send_to_sock()
{
    ...
    send(SocketA, ...);
    ...
}

I checked the reference pages for recvmsg() but none of them mention anything about a queue, but it seems like there is a queue because I am observing delays that incrementally add up. But the code stops working if the queue gets too long, so I want to know if there is a way to check length of queue.

Why do you have a function definition for `recv`? Normally, `recv` is defined by the OS... — Dietrich Epp, Apr 25 '17 at 22:25
Sockets do have buffers. If that's what you're referring to, this is probably of interest: http://stackoverflow.com/questions/7865069/how-to-find-the-socket-buffer-size-of-linux — Andrew Henle, Apr 25 '17 at 22:25
We,, data is spread out in space and time between you and the peer. It's queued in the server, client and intermediate routers. It's en-route along undersea fibres and in free space between ground stations and satellites. There is data out there, but you don't know where it is or how much. — ThingyWotsit, Apr 25 '17 at 22:25
if you are doing TCP over those sockets then the send will be forced to wait until you have processed enough messages — pm100, Apr 25 '17 at 22:30
I don't see how you can be observing delays in this situation, or how that implies the existence of a queue (although there is one). If the UDP sender is outrunning the receiver there will be loss of datagrams, but neither the sender nor the receiver should ever have to block. — user207421, Apr 25 '17 at 23:17
I *know* it gets buffered, and that's what it says in my answer below. What I don't understand is why you think your *delays* are accounted for by queues (or buffers). They aren't. They are coming from somewhere else. — user207421, Apr 25 '17 at 23:44
You haven't answered or even addressed my question in any way. — user207421, Apr 26 '17 at 01:16

score 2 · Answer 1 · edited May 23 '17 at 12:02

It's not a queue, it's a buffer associated with most of I/O devices, not only sockets. For example, when you read from stdin with something like scanf, data goes to your program when you press enter. Where do you think all keystrokes are stored in the meantime?

The specific details of these buffers are implementation defined, but usually what happens with sockets is that new packets are discarded if the buffer is full. You can find more information about querying the state of the buffer in How to find the socket buffer size of linux and How can I tell if a socket buffer is full?.

score 2 · Answer 2 · answered Apr 25 '17 at 22:33

Yes. There is a socket receive buffer. Its maximum size can be got and set via getsockopt() and setsockopt() using the SO_RCVBUF option. When it fills, in the case of TCP the sender is told to stop sending; in the case of UDP further incoming data is discarded.

In C, for a socket, does recvmsg() have a queue?

2 Answers2