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 >Received on Tue Aug 26 2014 - 08:16:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:51 UTC