On Tue, Jul 16, 2002 at 03:06:58PM -0400, Przemyslaw Karwasiecki wrote:
> There are some idiosyncrasies in different versions/implementations
> of pcap libraries.
Currently, on UNIX, there aren't idiosyncracies in libpcap that should
matter.
However:
1) there will be differences on Windows, and on OSes where a
memory-mapped capture mechanism is present, so that you won't
necessarily be able to set non-blocking mode yourself, on all
platforms, in the future;
2) there are some idiosyncracies in the underlying mechanism
*used* by libpcap that could require you to do a timeout in
the select.
> But as long as I will follow rules given by you,
> and I will force pcap handle to be non-blocking, I should be able
> to do select() in my event loop,
Yes.
> but actual packet reading can be still done by pcap_next()?
Yes. Note that, with a timeout in the select (to work around the BSD
bugs in select on BPF devices), there will be no guarantee that
"pcap_next()" will return a packet - it might return NULL, indicating
that no packets were available. (I.e., you'll have to read when the
timeout expires, regardless of whether select says a read will be
possible or not, so you might read when a read won't be possible, and
thus get no packets.)
> I don't need to read() on pcap handle. Right?
Right. "pcap_read()" (as called by "pcap_dispatch()" and "pcap_loop()",
"pcap_dispatch()" being what "pcap_next()" calls) does the read for you
- assuming it's doing a read. On Linux, in fact, it does a
"recvfrom()", not a "read()". The details of how to read from the
pcap_t are handled by libpcap.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
