Re: KQueue 0-length UDP packet

2014-08-26 Thread Fedor Indutny
Ok, thanks for a clarification! On Tue, Aug 26, 2014 at 1:48 PM, Jan Kokemüller 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 lo

Re: KQueue 0-length UDP packet

2014-08-26 Thread Jan Kokemüller
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

Re: KQueue 0-length UDP packet

2014-08-24 Thread Fedor Indutny
Hello again! I just realized that the wording was probably a bit off. 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? I am totally fine with the fact that it triggers

Re: KQueue 0-length UDP packet

2014-08-02 Thread Fedor Indutny
After reading that line more carefully, I wonder if this behavior is really intentional here. It seems to me that `SO_RCVLOWAT` is supposed to set watermark value in terms of packet data bytes, not just raw packet size. And this is how `NOTE_LOWAT` actually works there, right? Could anyone please

Re: KQueue 0-length UDP packet

2014-08-02 Thread Fedor Indutny
Guess I know the answer: https://cloudup.com/cCkjLhI4M2r Basically, OSX is checking `kn_data` and FreeBSD is using `so->so_rcv.sb_cc`. Thank you anyway! On Sat, Aug 2, 2014 at 1:39 PM, Fedor Indutny wrote: > Hello! > > I'm trying to figure out, why this code: > > https://github.com/indutny/0