> -----Original Message-----
> From: Guy Harris [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 13, 2002 09:53
> To: Fulvio Risso
> Cc: [EMAIL PROTECTED]
> Subject: Re: [tcpdump-workers] non-blocking pcap_next?
>
>
> On Tue, Aug 13, 2002 at 07:37:06AM +0200, Fulvio Risso wrote:
> > pcap_loop() is blocking, since it returns only when the amount
> of packets
> > requested has been read. This is because pcap_loop() loops forever,
> > incrementing a packet counter each time a pacekt is received,
> and it returns
> > only when N packets have been delivered.
>
> Yes, but in the loop, it calls "pcap_read()".
>
> If "pcap_read()" never blocks - i.e, *immediately* returns, even if
> there are no packets to be read, rather than returning only after the
> timeout expires - "pcap_loop()" won't block either, even if it hasn't
> received any packets - it'll just spin in a CPU-consuming loop while
> waiting for packets.
No; there is the default timeout (the one set into the pcap_open_live() )
that prevent such a loop.
A reasonable value for that timeout is 1 second, that means that pcap_read()
return once a second (if there are no packets).
I agree with you that this is not a true 'blockage', but it is absolutely
reasonable.
The timeout is enabled by default.
> > We have the pcap_open_live() timeout; the "non blocking" property of the
> > pcap_read_ex() call is due to that timeout.
>
> When I refer to "non-blocking" mode, I'm referring to a mode where
> "pcap_dispatch()" and "pcap_read()" returns immediately, without
> waiting, *even if there are no packets to be read*. That's what the
> "non-blocking" mode set by "pcap_setnonblock()" does - and that's what
> "non-blocking" mode means on UNIX.
Yes; this can be obtained by calling the pcap_setnonblock().
As far as I undestand, Win32 and UNIX behaviour are absolutely equivalent.
Cheers,
fulvio
-
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
