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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
