On Thu, Dec 28, 2000 at 03:09:07PM -0500, Michael T. Stolarchuk wrote:
> >> and the associated select
> >> timeout only works `marginally'... the select will only be awoken
> >> when the buffer fills, not when the timeout has passed.
> >
> >Not true - it will be awoken when the timeout specified by the timeout
> >argument to "select()" or "poll()" expires; that's the timeout to which
> >I'm referring.
>
> oh, yes, you're exactly right about that. are you planning on
> placing the select into pcap-bpf.c (for example?).... first
> doing the select, and it if the timer expires, then
> not dispatching any data? then later the read?
No. The "select()" - or, rather, the "poll()" - in the version of
Ethereal I built is in "gmain.c", i.e. it's in GLib (GTK+ uses a main
loop from GLib).
It does a "poll()" on all the input sources that were given to GDK
(which passed them on to GLib), as well as on the connection to the X
server; the "poll()" also has a timeout which was set by a call to a
GTK+ routine.
That way, the application wakes up if either
1) the pcap_t's file descriptor becomes readable (which won't
happen on most releases of most versions of BSD until the
buffer fills, although I think some versions have fixed
this);
2) input arrives from the X server (e.g., if the user clicks on
the "Stop" button in the dialog box popped up for the packet
capture);
3) the timeout expires.
If the timeout expires, the application tries to read from the pcap_t.
The pcap_t file descriptor has been put into non-blocking mode, so it
won't sleep if there're no packets available.
The FreeBSD 3.4 version of "bpfread()", at least, will, if there's
nothing in the hold buffer, but there is something in the store buffer,
move stuff from the store buffer to the hold buffer and return it. If
there's nothing in the store buffer, if the descriptor is in
non-blocking mode, it'll either return an error of EWOULDBLOCK or return
a count of 0, both of which, it appears, will cause "pcap_read()" in
"pcap-bpf.c" to return 0, causing "pcap_dispatch()" to also return 0.
Applications such as tcpdump that only read from one pcap_t, and that
don't wait either for packets to arrive or for user input to arrive,
such as tcpdump, can just use "pcap_loop()" or "pcap_dispatch()" as is
(they don't depend on a read from the underlying file descriptor
returning after the timeout expires even if no data has arrived - in
fact, doing so merely causes them to waste CPU time saying "no data has
arrived, let me try again"). Those applications don't need a "select()"
in "pcap-bpf.c" - or in "pcap-linux.c".
Applications such as Ethereal that do wait either for user input or
packets would do the select themselves - or would have the GUI toolkit
do so. Those applications also don't need a "select()" in "pcap-bpf.c"
- or in "pcap-linux.c".
The only applications that would "need" a "select()" in "pcap-linux.c"
are those that depend on the read timeout expiring regardless of whether
any packets have arrived or not - but they'd "need" a "select()" in most
of the *other* "pcap-*.c" files as well, e.g. "pcap-dlpi.c" (Solaris's
read timeout does *not* appear to start until a packet arrives, and at
least some other DLPI platforms don't, as far as I know, have a "bufmod"
and thus don't have a read timeout). However, those applications
*already* have to work around this problem by doing a "select()"
themselves; that's what Ethereal did on Linux (and what the current CVS
version now does on all non-BSD UNIX platforms, given that I recently
discovered that you have to do that on Solaris; that "select()" is in
Ethereal, not in GTK+/GLib - the version of Ethereal that uses GLib's
"poll()" is an experimental version I have, I need to make sure I can
make that work on Windows as well before I check it in).
As such, those applications don't really need a "select()" in
"pcap-linux.c", as they have to supply it themselves (or switch to
having the main loop do it) in order to work with versions of libpcap
other than the current CVS version (and, in fact, even *with* the
current CVS version, they'd have to do it themselves in order to work
right on platforms that are neither BSD nor Linux).
Even if we *did* put the "select()"s in elsewhere, we wouldn't put them
into "pcap-bpf.c" unless there was a version of BSD on which the read
timeout *didn't* cause a read from a BPF device to return when the
timeout expired if there're no packets to be read.
-
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
