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