KQueue 0-length UDP packet

[Fedor Indutny]

Ok, thanks for a clarification!


On Tue, Aug 26, 2014 at 1:48 PM, Jan Kokemüller <jan.kokemueller at gmail.com>
wrote:

> Hi,
>
>
>  What I wanted to ask is: why does FreeBSD kqueue implementation treat
>> `SO_RCVLOWAT` as a raw packet size watermark, and not using the actual
>> data size for filtering out events?
>>
>
> It looks like SO_RCVLOWAT refers to the number of bytes in the socket
> buffer, not raw packet bytes. In the case of an arriving UDP packet there
> is always a 'struct sockaddr' in the buffer that contains the source
> address/port of the message. For IPv4 this is 16 bytes and for IPv6 28
> bytes. I think this is intended behavior, as this is data you can "read"
> with recvfrom or recvmsg.
>
> POSIX says "Receive calls may still return less than the low water mark if
> an error occurs, a signal is caught, or the type of data next in the
> receive queue is different from that returned (for example, out-of-band
> data)." So in this case this data is address data.
>
> On the other hand, NOTE_LOWAT from kevent refers to data/protocol bytes.
> The semantics were changed in 2002:
> http://marc.info/?l=freebsd-arch&m=103587526507822&w=2
> The value you get in 'data' also refers to the number of protocol data
> bytes available.
>
> I've had a look at how OpenBSD handles this. It returns the number of
> protocol data bytes with "ioctl(s, FIONREAD, &len)" but the number of bytes
> in the socket buffer in the 'data' member of kevent, so exactly the other
> way around compared to FreeBSD. SO_RCVLOWAT works still the same, though.
>
> Cheers,
> Jan
>