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

KQueue 0-length UDP packet

2014-08-02 Thread Fedor Indutny
Hello! I'm trying to figure out, why this code: https://github.com/indutny/0-udp Which basically sends a 0-length UDP packet to a server and polls kqueue events on the server fd. Return 1 kevent on FreeBSD, and blocks indefinitely without returning any events on OSX. So far I could see that

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 fe...@indutny.com wrote: Hello! I'm trying to figure out, why this code:

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