Re: libpcap for linux, to_ms redefined

[Guy Harris <gharris () sonic net>]

On Mon, Oct 07, 2002 at 04:59:47PM -0600, Phil Wood wrote:
> Well, I just changed my code so to_ms == 0 will block as long as is
> necessary.  I still like to have the ability to return to the caller if
> there are no packets available.

That's what non-blocking mode is for; in non-blocking mode,
"pcap_read()" shouldn't wait for packets.  Check whether the "nonblock"
member of the "pcap_t" structure is 0 (meaning non-blocking mode isn't
set) or non-zero (meaning non-blocking mode is set).

> How bad would it be to use a negative
> value (or just -1) to mean "if there are no packets this instant in time,
> return to the calling program"?

Given that there's already an API for that, it'd be bad, as programs
would have to use *both* mechanisms to request non-blocking mode; it'd
be better to just use non-blocking mode, as that already works on all
platforms.

> For what it's worth.  My linux mmap'd pcap behaves as follows:
>
>      A. With a positive timeout (initialized by the to_ms value on each call
>      to pcap_read), a "read" will return if either
>
>       1) enough polls have been called to exhaust the timeout value.
>
>      or
>
>         2) the timeout expires even if no packets have been received.

That's OK, but, as programs using libpcap cannot assume that when the
timeout expires "pcap_read()" will return (Linux is *NOT* the only
platform on which the timeout doesn't work that way - on Solaris,
there's a timeout, but it doesn't work that way, so any program that
assumes that the timeout can be used to limit how long "pcap_read()"
etc. wait is broken on multiple platforms).

>      B. With a zero timeout, a "pcap_read" will never return.  The timeout
>      is considered infinite.  Of course callbacks will continue for each
>      packet that arrives.

That's the right behavior for compatibility with other platforms.

>      C. With a negative value, "pcap_read" will return if either
>
>        1) there are no packets on the ring
>
>      or
>
>        2) the packets that have been queued on the ring have all been
>           processed.

You can do that - but you should also do it if the "nonblock" flag is
set, in which case programs will just use the "nonblock" flag, so the
timeout shouldn't ever be negative, so there's no point in checking for
a negative timeout in that case.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe