Guy Harris wrote:
>
> On Tue, Jul 16, 2002 at 12:15:33PM -0700, Fulvio Risso wrote:
> > Hi.
> > The fact is that we believe the actual API is a bit confusing, so in our
> > docs we suggest not to use these calls.
> > Instead, we defined a pcap_read_ex() which reads a packet at a time
> > (like pcap_next() ), it is non blocking,
>
> I think that could be implemented without too much pain on UNIX, by
> having "pcap_read_ex()" set non-blocking mode on the descriptor if it's
> not currently set, and having "pcap_read()" set or clear non-blocking
> mode to match what was set with "pcap_setnonblock()".
>
> (For a memory-mapped device, "pcap_read_ex()" would just check the
> buffer to see if any packets were available, and not block if there
> aren't any.)
>
> > - (1) if a packet has been read without problems
>
> Is the intent that it's like "pcap_next()", in that there may be a
> buffer with multiple packets in it, and it'll just return the next
> packet from the buffer?
Yes.
The problems with pcap_next() are that:
- is not too efficient (it uses other functions like the pcap_dispatch,
so it is a nested bounch of calls)
- it is still using "callbacks" for returning packets
- three is no way to know why this call failed (on a live capture this
could be a network error; on a dump file, there could be no packets
left), because it always return 0.
We believe that whe world has changed since tcpdump appeared long time
ago.
At that time, multithreading programs were not so common, so the
callback-mode implemented by libpcap (libpcap calls the userland
software when it receives a packet in the pcap_loop() ) was a good idea.
Now, a large part of programmers prefers to be able to control when
their programs are busy, ... i.e. they don't want callback; they want to
be able to read packets only when the software is ready to do that.
So, we decided to create a new pcap_read_ex(), which does basically
that.
It is platform specific (like pcap_read() ), so it is efficient, and it
provides a simple way to avoid callbacks.
Gianluca Varenni proposed that some months ago:
http://www.tcpdump.org/lists/workers/2002/03/msg00050.html
I think at that time nobody was interested in that.
Anyone now likes this idea?
By the way, in the WinPcap docs we're marking some pcap funcions with
the following tags:
- discouraged (when we suggest to use another call, but this one is
still valid)
- deprecated (when we *strongly* suggest to use another call instead,
and this one should be avoided)
Calls like pcap_next() are "discouraged".
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
