libc lwip recv MSG_PEEK doesn't behave as specified

Johannes Kliemann kliemann at componolit.com
Tue Jun 19 22:20:56 CEST 2018


Hi,

Am 19.06.2018 um 20:39 schrieb Christian Helmuth:
> Hello,
> 
> On Tue, Jun 19, 2018 at 08:14:07PM +0200, Johannes Kliemann wrote:
>> So having at least MSG_DONTWAIT would be quite helpful. But I think the
>> general problem is the API. Having a native asynchronous TCP or IP
>> session with a native TCP/IP stack would be the best case but I assume
>> this won't happen soon. But also an asynchronous (or at least more
>> compatible) approach using libc would already be useful (and potentially
>> resolve the need for any recv flags ;) ).
>>
>> So currently I need some flags but I would happily switch to a generally
>> better approach if there is one.
> 
> I see two prominent directions we could explore. First on the libc
> level, you may use select() with a zero timeout for polling file
> descriptors and only read() if data is available. This option leaves
> us with the question, when to poll.

This is what I currently do but with ioctl(int, FIONREAD, int*) which
gives the number of bytes available to read from a socket.

> The second option may be a deeper
> look into Emery's current lwip port which removes the socket API level
> and provides the low-level functions, which should be non-blocking.

I will look into that, thanks.

> There's also a third option in libc/select.h, which provides a
> mechanism to block in the entrypoint waiting for signals, RPC, and
> also for libc file descriptors to become readable. The semantics are a
> bit tricky, but I know of applications out there using this mechanism
> successfully.

I also might look into this while I still prefer a non-blocking approach.

Thanks for your help,
Johannes



More information about the users mailing list