On Wed, Dec 27, 2000 at 06:15:57PM -0800, Guy Harris wrote:
> I've already updated "pcap.3" to note that there is no guarantee that
> "pcap_dispatch()" will return after the read timeout expires; I'd be
> inclined to remove the "select()" from the Linux libpcap, to remove one
> system call from the code path,
I have a version of Ethereal that, at least on FreeBSD, Debian 2.2, and
Solaris 7:
does a "select()" on the pcap (BPF/PF_PACKET/DLPI) file
descriptor in the GTK+ main loop;
makes that file descriptor non-blocking;
works around the BSD problem with "select()" by setting a
timeout in the GTK+ main loop and, if the timeout expires, doing
a read from the pcap_t.
It seems to work; however, that extra "select()" in the Linux libpcap is
done whenver the timer in the GTK+ main loop goes off, which means that
it blocks, for 250ms, in the main loop every 250ms - this appears to add
some delay to the UI (if it's blocked in the "select()" in
"pcap_read()", it won't respond immediately to clicking the "stop
capture" button, as it will if it's blocked in the "poll()" in the GTK+
main loop).
It seems to respond more quickly when built with the 0.4a6 libpcap that
comes with Debian 2.2, which doesn't have the "select()".
So it looks as if interactive applications might be able to, at least on
BSD, Solaris, and Linux, do a "select()" or "poll()" on the pcap_t file
descriptor in the main loop, and, with the aid of a timeout, work around
the BSD problem - the timeout is established regardless of what platform
you're on, so you don't even have to #ifdef it.
I don't know whether a handle for the WinPcap driver can be used in a
"WaitForMultipleObjects()" or "MsgWaitForMultipleObjects()" call; if so,
a similar technique could be used on Windows.
Given that, it seems to me as if removing the "select()" is, in fact,
the right thing to do, assuming that the technique of using "select()"
or "poll()" on UNIX, or "WaitForMultipleObjects()" or
"MsgWaitForMultipleObjects()" on Win32, works on all implementations of
those APIs on which libpcap works (i.e., the UNIXes I haven't tried, and
both Windows OT and Windows NT). I *suspect* that it'd work on all
UNIXes that use DLPI or sockets or raw STREAMS, so I suspect it'd work
on:
RS/6000 AIX with DLPI;
HP-UX;
Irix;
SunOS 4.x.
It might not work on SunOS 3.x (non-STREAMS NIT), or AIX on the RT PC
(I'm assuming that's what "pcap-enet.c" supports - I don't know what
other platforms it supports), or Digital UNIX, although I suspect it'd
probably work on Digital UNIX.
I can't speak for Windows; perhaps Fulvio Risso or Loris Digioanni could
address that one. (If it's at all possible to make it work with
"WaitForMultipleObjects()", it'd probably be a good idea to make it do
so; I don't know whether that's a pain to do on Windows OT, a/k/a
Windows 9x, or not.)
-
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
