How can I tell if a socket buffer is full?

Question

How can I tell if a read socket buffer is full or a write socket buffer is empty?

Is there a way I can get the status of a socket buffer without a system call?

UPDATE: How about this: I'd like to get a callback or signal when either the read socket buffer is full or the write socket buffer is empty. This way I can stop processing to allow more I/O to occur on the wire, since being I/O bound is always an issue when sending data on the wire.

The select() call is how you check if the read buffer has something in it. Not when it is full (I think).

Answer 1

Taking in account that the kernel buffer for sockets lives in kernelspace I doubt there is any way of asking for the size without a syscall.
With syscalls you can try recv with PEEK.

ret = recv(fd, buf, len, MSG_PEEK);

Will give do the recv but without emptying the buffer.

Answer 2

That is not possible without a syscall. But what's the problem with syscalls?

Answer 3

Poll the file descriptor with select and a zero timeout - if select says it's writeable, the send buffer isn't full.

(Oh... without a system call. No, there isn't.)

Addendum:

In response to your updated question, you can use two ioctls on the TCP socket: SIOCINQ returns the amount of unread data in the recieve buffer, and SIOCOUTQ returns the amount of unsent data in the send queue. I don't believe there's any asynchronous event notification for these though, which will leave you having to poll.

Answer 4

Have you tried select()?

Answer 5

You can try ioctl. FIONREAD tells you how many bytes are immediately readable. If this is the same as the buffer size (which you might be able to retrieve and/or set with another icotl call), then the buffer is full. Likewise, if you can write as many bytes as the size of the output buffer, then the output buffer is empty.

I don't how widely supported FIONREAD, FIONWRITE, and SIOCGIFBUFS (or equivalents) are. I'm not sure I've ever used any of them, although I've a sneaky feeling I've used similar functionality on Symbian for some reason or other.

Whether the call needs kernel mode to compute this is platform-specific. Vaguely trying to avoid system calls is not a valid optimisation technique.

A basic BSD-style sockets interface doesn't say anything much about read and write buffers. When does it matter whether the send buffer is empty? It certainly doesn't mean that all the data has been received at the other endpoint of the socket - it could be sitting in some router somewhere. Likewise, "your" read buffer being full doesn't guarantee that a write at the other end will block.

Generally speaking, you just read/write as much as you can and let the sockets layer handle the complexity. If you're seeing a lot of I/O completed with tiny sizes then maybe there's some performance problem. But remember that a stream socket will send/receive a packet at a time, containing a block of data. Unless TCP_NODELAY is set, it's not as though bytes are arriving by ones at the NIC, and you might end up making one read call per byte. They're arriving in packets, so most likely will become readable all at once, perhaps 1k-ish at a time. You're unlikely to be able to speed things up by holding off reading until there's a lot to read. In fact you might make it worse, because by the time your endpoint's read buffer is full, there's a risk that incoming data is being discarded because there's nowhere to store it, resulting in delays and re-sends.

Answer 6

I think there's a fundamental reason why your approach is flawed/doomed. The system doesn't want to tell you when the read buffer is full / write buffer is empty because those events indicate a break down in the contract between you and the system. If things get to that point (particularly in the read direction) it is too late for you to ensure smooth operation of the protocol stack. Some more data might arrive while you are finally deciding to read the buffer. You should be reading the buffer before it gets full, that's the whole point of buffered I/O.