Slightly off topic, but...
On 11/23/05, Guy Harris <[EMAIL PROTECTED]> wrote:
...
> For a future libpcap supporting pcap-NG, it might not be; that depends
> on how the byte-order issue is handled. I can think of two
> possibilities, but there might be others:
>
> 1) have an ntar_foff c
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 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
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
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:
>
> pc
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/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...
Co
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
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
12 matches
Mail list logo
