Evan Hughes wrote:
Regarding return values: I'll make the changes that you suggested.
I'm using -3 to indicate that a stream [can't be seeked on]. Would it be
acceptable to create a define for that value? It's a pain to memorize
those negative values...
Yes, #defines for the various return
On 11/22/05, Guy Harris <[EMAIL PROTECTED]> wrote:
> Evan Hughes wrote:
> >I can do some timings on the cost of the fgetpos(), but I don't
> > have a large number of platforms available to test on, just debian
> > boxes and windows machines.
> I could test on Solaris 7, assorted versions of Deb
Evan Hughes wrote:
I'm confused. ftell() took a long time because of the fseek()?
No, ftell() took a long time because of the *l*seek(). (V6 UNIX had a
"tell()" system call, along with "seek()"; V7 replaced both with "lseek()".)
I agree. I like this idea the most, as it allows us to
Evan Hughes wrote:
I can do some timings on the cost of the fgetpos(), but I don't
have a large number of platforms available to test on, just debian
boxes and windows machines.
I could test on Solaris 7, assorted versions of Debian, assorted
versions of FreeBSD, and OS X 10.3.9 and 10.4.3
On 11/22/05, Guy Harris <[EMAIL PROTECTED]> wrote:
...
> Some comments:
>
> fgetpos() and fsetpos() don't return an error code, they returns 0 on
> success or -1 on failure and, if they return -1, they set "errno" to the
> error code.
...
Regarding return values: I'll make the changes that you
On 11/22/05, Guy Harris <[EMAIL PROTECTED]> wrote:
re: cost of ftell
> ...and might make a system call to get the file position, which could
> significantly add to the performance overhead. Some versions might keep
> track of the position under the assumption that if you've read N bytes
> you've a
On 11/22/05, Guy Harris <[EMAIL PROTECTED]> wrote:
re: cost of the fgetpos()
> As per my other mail on this topic, as I remember that system call *was*
> significant in the Ethereal capture-file-reading code, and getting rid
> of it sped up file reading.
I could add a call that would turn on th
Evan Hughes wrote:
I haven't done any performance tests. The fgetpos() call is the
only function call I've added on the main path (although I do a little
stack manipulation during the read), but that's during
sf_next_packet(). I'm assuming that is already slow due to IO.
...although real I/
Gianluca Varenni wrote:
Do you have any idea if performance is affected by these patches?
I'd probably expect almost no performance penalty in pcap_ftell() (apart
from the fact that you allocate memory with malloc),
...and might make a system call to get the file position, which could
signi
Evan Hughes wrote:
Bah! That patch has cruft from an uninteresting file. A slimmer
patch is attached.
Some comments:
fgetpos() and fsetpos() don't return an error code, they returns 0 on
success or -1 on failure and, if they return -1, they set "errno" to the
error code.
If fgetpos() fai
d some performance
> hit with pcap_fseek (because basically you flush the FILE cache).
>
> Have a nice day
> GV
>
>
>
>
> - Original Message -
> From: "Evan Hughes" <[EMAIL PROTECTED]>
> To:
> Sent: Monday, November 21, 2005 1:58 PM
> Su
cache).
Have a nice day
GV
- Original Message -
From: "Evan Hughes" <[EMAIL PROTECTED]>
To:
Sent: Monday, November 21, 2005 1:58 PM
Subject: Re: [tcpdump-workers] Seeking in tcpdump files
I've made a patch against 2005.11.17 that provides four functions
for seeking
I've made a patch against 2005.11.17 that provides four functions
for seeking:
pcap_ftell() - Acquires a position handle to the start of the current packet.
pcap_freeposition() - Frees a position acquired with pcap_ftell().
pcap_fseek() - Repoints the currently open stream to the passed positi
I forgot to mention: the diff contains two files for testing the
seeking and telling with a stream containing IP packets.
e
On 11/21/05, Evan Hughes <[EMAIL PROTECTED]> wrote:
>I've made a patch against 2005.11.17 that provides four functions
> for seeking:
>
> pcap_ftell() - Acquires a pos
Bah! That patch has cruft from an uninteresting file. A slimmer
patch is attached.
e
On 11/21/05, Evan Hughes <[EMAIL PROTECTED]> wrote:
> I forgot to mention: the diff contains two files for testing the
> seeking and telling with a stream containing IP packets.
>
> e
>
> On 11/21/05, Evan Hu
On 11/15/05, Guy Harris <[EMAIL PROTECTED]> wrote:
> Evan Hughes wrote:
> > If I submitted a patch with the change in it, what's the
> > likelihood that it would be accepted?
>
> A patch with pcap_seek() and pcap_tell()? It'd probably be accepted...
Cool! I'll give it a shot.
e
-
This is
Evan Hughes wrote:
If I submitted a patch with the change in it, what's the
likelihood that it would be accepted?
A patch with pcap_seek() and pcap_tell()? It'd probably be accepted...
I would, of course, wrap the
position into an opaque typedef, so that stuff like endian-ness could
be
On 11/11/05, Guy Harris <[EMAIL PROTECTED]> wrote:
...
> > I guess an alternative would be to add a pcap_seek() and a
> > pcap_tell() to the API. I assume that you'd rather not grow the API
> > more than necessary, however.
>
> The question is what constitutes "necessary". An API such as that
Hi Evan,
if Guy's points aren't a concern for you, you can just use libpcapnav.
It provides pcapnav_get_offset() which does what you want.
http://netdude.sourceforge.net/doco/libpcapnav/index.html
Cheers,
Christian.
--
On Nov 11, 2005, at 1:48 PM, Evan Hughes wrote:
I'm building a library that indexes packets in libpcap files. In
order to create and use such an index, I'd like to be able to get the
file location that each packet starts at.
Would I be violating encapsulation if I just use pcap_file()
Howdy,
I'm building a library that indexes packets in libpcap files. In
order to create and use such an index, I'd like to be able to get the
file location that each packet starts at.
Would I be violating encapsulation if I just use pcap_file() to
grab the file handle at the current packe
21 matches
Mail list logo
