Hi all,
I'm currently trying to use a recv call on a network socket with the MSG_PEEK flag. According to the man 2 recv:
MSG_PEEK causes the receive operation to return data from the beginning of the receive queue without removing that data from the queue. Thus, a subsequent receive call will return the same data.
Yet this doesn't seem to be the case (at least with lwip). I implemented a test [1] that creates a connection from the test http client and subsequently calls recv(sock, buf, 1, MSG_PEEK) which always should yield 'G' into the buffer (the first character of the GET request). Yet the output looks as follows:
[init -> test-http_clnt] got IP address 10.0.2.15 [init -> test-http_clnt] Create new socket ... [init -> test-http_clnt] Connect to server ... [init -> test-http_clnt] Send request... [init -> test-libc_msg_peek] peek: G [init -> test-libc_msg_peek] peek: E [init -> test-libc_msg_peek] peek: T [init -> test-libc_msg_peek] peek: [init -> test-libc_msg_peek] peek: /
(this is just an extract but you get the point)
The problem is that this doesn't only account to the recv call but also any further read call will miss the first "peeked" bytes which completely defeats the purpose of MSG_PEEK.
According to the lwip_legacy port MSG_PEEK should be supported since 2007 and I'm not sure why it should stay broken such a long time.
2007-06-30 Frédéric Bernon
- sockets.h, sockets.c: Implement MSG_PEEK flag for recv/recvfrom functions.
As far as I can see I have used it correctly so I'm not sure why it isn't working. You can view the code at [1] and run the test with run/libc_msg_peek.
Regards, Johannes
[1]: https://github.com/jklmnn/genode/commit/b631a3068024748cc8443d1db4e30b35aae1...