On Mon, Mar 26, 2001 at 10:42:31AM +0200, Yoann Vandoorselaere wrote:
> I think saying that a library will have different behavior depending
> of the architecture it is run on is just the proof the library is wrong.
I do not.
There are *TWO SEPARATE PURPOSES* that could be served by a timeout.
One purpose is to allow an application to "batch up" packets, so that
multiple packets can be read by a single system call, but to allow the
application not to wait forever for a complete buffer full of packets to
arrive. In this case, there is no requirement that the timeout expire
and the read complete if *no* packets have arrived; given that the
behavior of the underlying OS's batching mechanism, if present, is
different on different OSes, I consider it sufficient, for this purpose,
for the contract between libpcap and its clients to say that the timeout
*might* expire and the read complete if no packets have arrived, but not
to specify whether it *will* do so (and consider it sufficient for it
not to specify whether any batching is done - this is a "quality of
implementation" issue, where the "implementation" is that of the OS's
packet capture mechanism, not of libpcap).
Another purpose would be to allow an interactive application to
periodically poll for user input while reading a live capture. In that
case, there is a requirement that the timeout expire and the read
complete if no packets have arrived...
...*HOWEVER*, that same purpose can, in all cases I know of, be
achieved, instead, by having a loop that does a "select()" or "poll()"
(or, on Windows, a "MsgWaitForMultipleObjects()") on file descriptors
used for user input (e.g., the connection to the X server, for an X
application, or the current tty, for a curses application) and on the
capture file descriptor. (This has the advantage that the application
can respond immediately to user input, rather than having to wait for a
timeout to expire.)
If somebody can supply an situation where timeout-based polling is
sufficient and selecting in the main loop of the application is *not*
sufficient, I would be willing to add the new "make the timeout expire
even when no packets have arrived" API, as per my previous message. I
would *NOT* be willing to make that behavior the default, as I don't
want to have the writers of applications that depend on that behavior
get a flood of "I tried running your program, but it hangs" messages
(and, given my experience with Ethereal, it will be extremely difficult
for anybody to convince me that they won't get those messages).
> Here you are talking of the read() behavior, different on many
> architectures, but this problem can be avoided internaly to libpcap
> (using, for exemple, the select() approach).
Perhaps it *can* be avoided; however, I have seen no reason yet why it
*should* be avoided.
> > > A question about this point : is there a way to access the
> > > fd used by pcap ?
> >
> > "pcap_fileno()". See the "pcap(3)" man page.
>
> Again, the behavior you describe is documented no-where :
>
> <man pcap>
> pcap_fileno() returns the file descriptor number of the ``savefile.''
> </man pcap>
That's because the documentation is wrong. The *code* has, in fact,
dating back at least as far as LBL libpcap 0.4, not returned the file
descriptor number of the savefile, and *has* returned the file
descriptor number of the raw capture device - the LBL libpcap 0.4, and
the tcpdump.org libpcap 0.5.2 and 0.6[.x] version does:
int
pcap_fileno(pcap_t *p)
{
return (p->fd);
}
where "pcap_open_live()" sets "p->fd", and "pcap_open_offline()", in
those versions, does
/*
* Set this field so we don't close stdin in pcap_close!
*/
p->fd = -1;
and sets "pcap->sf.rfile" to refer to the "FILE *" opened with
"fopen()". I will fix the man page to reflect reality.
-
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
