Hello,
This is a good idea. I have being using libpcap since 95 on a
variety of OS's and have always had to mod the libs to get a non blocking
read. I change pcap_open_live() and poll the descriptor. If there is no packet
I immediately return but set the header length to zero to inform my
program no data was available. Very simple but effective.
I require this when writing X11 programs and need to check for X Events
to update the screen/button presses etc.
It would be useful if this was standard in libpcap.
What would be even better would be a polling driver for common cards
ie tulip/Intel so we can get some descent performance out of libpcap.
We need to disable the crippling interrupts to do GIGE speeds.
Maybe this could be an option for Linux/BSD platforms?
Keep up the good work .. Joe.
--
__o _~o __o
`\<, `\<, `\<,
______________________________________(*)/_(*)__(*)/_(*)__(*)/_(*)________
Im a 21st Century Digital Boy ... I aint got a life, but I got lotsa toys.
******************* Joe Elliott [EMAIL PROTECTED] ********************
Phone:(650)961-6631 Cell:(650)714-3932 Inetd.Com http://inetd.com
--------------------------------------------------------------------------
On Wed, 17 Jul 2002, Fulvio Risso wrote:
> Date: Wed, 17 Jul 2002 07:54:27 -0700
> From: Fulvio Risso <[EMAIL PROTECTED]>
> To: Guy Harris <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: [tcpdump-workers] non-blocking pcap_next?
>
>
>
> 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
>
-
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
