Linux - ioctl with FIONREAD always 0

Question

I\'m trying to get to know how many bytes there are readable at my TCP socket. I am calling ioctl with the Flag \"FIONREAD\" which should actually give me this value. When I ca

Answer 1

It's happening very quickly, that's why you don't see anything. What you're doing:

• ioctl: Is there data for me ? No, nothing yet
• recv: Block until there is data for me. Some (short) time later: Here is your data

So if you really want to see FIONREAD, just wait for it.

/* Try FIONREAD until we get *something* or ioctl fails. */
while (!bytesAv && ioctl (m_Socket,FIONREAD,&bytesAv) >= 0)
    sleep(1);

Answer 2

Use select() then ioctl(FIONREAD) then recv()

Answer 3

The real answer here is to use select(2) like cnicutar said. Toby, what you aren't understanding is that you have a race condition. First you look at the socket and ask how many bytes are there. Then, while your code is processing the "no data here" block, bytes are being received by the hardware & OS asynchronous to your application. So, by the time that the recv() function is called, the answer of "no bytes are available" is no longer true...

if ( ioctl (m_Socket,FIONREAD,&bytesAv) < 0 )
{ // Error 
}

// BYTES MIGHT BE RECEIVED BY HARDWARE/OS HERE!

if ( bytesAv < 1 ) // AND HERE!
{
    // No Data Available
    // BUT BYTES MIGHT BE RECEIVED BY HARDWARE/OS HERE!
}

// AND MORE BYTES MIGHT BE RECEIVED BY HARDWARE/OS HERE!

bytesRead = recv(m_Socket,recBuffer,BUFFERLENGTH,flags);
// AND NOW bytesRead IS NOT EQUAL TO 0!

Sure, a small sleep probably fixed your program two years ago, but it also taught you terrible coding practice and you lost out on an opportunity to learn how to use sockets correctly by using select().

Further, as Karoly Horvath said, you can tell recv to not read more bytes than you can store in the buffer that the user passed in. Then your function interface becomes "This fn will return as many bytes as are available on the socket, but not more than [buffer size you passed in]".

This means that this function doesn't need to worry about clearing the buffer any more. The caller can call your function as many times as necessary to clear all of the bytes out of it (or you can provide a separate fn that discards the data wholesale and not tie up that functionality in any specific data gather function). Your function is more flexible by not doing too many things. You can then create a wrapper function that is smart to your data transfer needs of a particular application, and that fn calls the get_data fn and the clear_socket fn as needed for that specific app. Now you are building a library you can carry around from project to project, and maybe job to job if you're so lucky as to have an employer that lets you take code with you.

Answer 4

For those who are using a docker I had the same issue when I tried to send packets from outside (Ubuntu 16.04 in this case) into the docker's interface (docker0 in this case) using tcpreplay.

The workaround was to run tcpreplay inside the docker.

I do not know if ioctl() is supported in docker or not, so it is not a solution.

Answer 5

You're doing nothing wrong, if you are using blocking I/O recv() will block untill the data is available.