Re: Portable way to "block" on pcap_next_ex()

[Fernando Gont <fernando () gont com ar>]

On 01/15/2012 08:56 PM, Guy Harris wrote:
> > For my current app, it's probably just "annoying" (although no big 
> > deal). However, I was mostly concern about performance problems in
> > other applications. Put another way, if there's nothing that an app
> > can do without a packet being read, there's no reason for the app
> > to be awaken.
>
> Well, presumably, yes, although I assume the folks at LBL had some
> rationale for starting the timer when the read() is done rather than
> when a packet arrives (starting the timer on a read() also
[,,,]

I guess that's the "logic" place to put a timeout? (Although in the pcap
case, the timeout is used for a different purpose (performance) rather
than "I don't want this call to block forever if there's nothing to read").



> select()   and   poll()   do   not   work  correctly  on  BPF
> devices; pcap_get_selectable_fd() will return a file descriptor on
> most of those versions  (the  exceptions  being  FreeBSD  4.3  and
> 4.4), but a simple select() or poll() will not indicate that the
> descriptor  is  readable until  a  full  buffer’s worth of packets is
> received, even if the read timeout expires before then.  To work
> around this, an application  that uses  select()  or  poll()  to
> wait for packets to arrive must put the pcap_t in non‐blocking mode,
> and must  arrange  that  the  select()  or poll()  have a timeout
> less than or equal to the read timeout, and must try to read packets
> after that timeout expires, regardless  of  whether select() or
> poll() indicated that the file descriptor for the pcap_t is ready to
> be read or not.

Sorry, what's the point of calling select() in this case, and what's the
rationale for the timeout value used with select() in this case?



> If you have a system where select() works as it should, i.e.:
[....]
> select() will block until either
>
> 1) a bufferful of packets arrives
>
> or
>
> 2) the timer, started when the select() is done, expires, regardless
> of whether any packets are available to read.

This doesn't seem to agree with my tests.

I've just checked this on FreeBSD-8.2-release and on a current Ubuntu
system, and in both cases select() returns "readable" only for each
packet that is received.



> > In Solaris's case, that would depend on whether my app is actually
> > run before "to_ms" have elapsed since the reception of the first
> > packet, right?
>
> Your app can't be run before "to_ms" have elapsed since the reception
> of the first packet, because "the first packet" means "the first
> packet received after the getmsg() is done on the DLPI descriptor" -
> i.e., it's not the first packet received ever, it's the first packet
> received in a packet batch.

Sorry, do you mean:

1) I call select(), and it blocks
2) select() returns "readable"
3) I call pcap_next_ex(), and *this* triggers the "to_ms" timer -->
hence this call will probably block for about "to_ms", too.

?

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: fernando () gont com ar || fgont () si6networks com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.