nl_recv() and handling truncated messages
Jan Gutter
jan.gutter at netronome.com
Wed Dec 9 07:01:25 PST 2015
On Wed, Dec 9, 2015 at 3:34 PM, Thomas Haller <thaller at redhat.com> wrote:
> On Wed, 2015-12-09 at 14:24 +0200, Jan Gutter wrote:
>> On Wed, Dec 9, 2015 at 12:14 PM, Thomas Haller <thaller at redhat.com>
>> wrote:
>> > On Tue, 2015-12-08 at 17:37 +0200, Jan Gutter wrote:
>> It appears the only way to do this is with peeking.
>
> Hm yeah. To my understanding, it is not possible with recvmsg() to
> obtain the message only if the buffer is large enough.
>
> Without peek, the message gets effectively truncated and lost. With
> MSG_PEEK, you have to always call recvmsg() twice.
>
> It would be better to have a opportunistic MSG_PEEK, which reads the
> message if possible.
>
> Pretty bad (from recvmsg). Or maybe I am wrong and it is somehow
> possible... anybody??
Closest I got was this from The Holy Tome:
https://books.google.co.za/books?id=ptSC4LpwGA0C&pg=PA594&lpg=PA594&dq=recvmsg+msg_trunc&source=bl&ots=Ks4GRncqUs&sig=pZREA6iKGRxmYzM7HaJBkR8V-o8&hl=en&sa=X&ved=0ahUKEwiQxYewhM_JAhWBPhQKHWq6DHYQ6AEILTAD#v=onepage&q=recvmsg%20msg_trunc&f=false
Paraphrasing Unix Network Programming Vol. 1 (Stevens) Section 22.3
Datagram Truncation
There are three possibilities:
1. Discard bytes and return MSG_TRUNC (Linux recvmsg)
2. Discard bytes and don't tell the app
3. Keep excess bytes and return them on subsequent recvmsg calls
According to the book, POSIX specced 1, but early releases of SVR4 did 3.
Jan
More information about the libnl
mailing list