Re: KQueue 0-length UDP packet

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