Yoav Nissim wrote:
Hello All,
We believe there might be a problem when calling lwip_ioctl on a UDP socket.
AFAIK, when calling ioctl() with FIONREAD, we should receive the size of
the next unread datagram;
The problem here is that FIONREAD does not appear to be standardized.
We are trying to conform to the opengroup specifications with the
socket API, but since not all functions/options are standardized there,
some have been implemented to the bests knowledge of the developer.
instead lwip_ioctl() seems to returns the
total size of pending datagrams.
>From looking at the current source code, I think so, too.
Although we use lwip 1.3.0, we believe the problem still exists in the
cvs head.
As far as we can tell, both Windows and Linux behave as expected.
Well, at least from the msdn docs, its unclear what windows is expected
to do. Heres an excerpt from
http://msdn.microsoft.com/en-us/library/ms738573(VS.85).aspx :
"FIONREAD returns the amount of data that can be read in a single call
to the recv function, which
may not be the same as the total amount of data queued on the socket.
If s is message oriented (for example, type SOCK_DGRAM),
FIONREAD still returns the amount of pending data in the network
buffer, however, the amount that can actually be read in a single call
to the recv function is limited to the data size
written in the send or sendto function
call."
To me, this means that "the amount of pending data in the network
buffer" is equal to our
"sock->conn->recv_avail".
Could anyone confirm whether this is indeed an lwIP problem?
If we don't find a standard, we might want to see what most OSes do and
do whatever seems to be best practice...
I've added a bug entry for this so that it doesn't get forgotten.
Simon
|