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 contain the byte order in effect at the offset, > as > well as the offset in the file; > > 2) have a data structure attached to a ntar_file_handle structure, > giving the byte order for offset ranges in the file, and look up the > byte order corresponding to a particular offset in that table when a > seek is done.
Could the file not store everything in network byte order? I guess there would be a slight speed hit on read/write, but that would all be in processor (or at least in memory) work, but it would seemingly resolve the issue. e > > The former requires less memory and less data structure scanning on a > seek, but it makes an ntar_foff bigger. Ethereal would store an offset > for *every* packet in the file, so a bigger file offset structure might > significantly increase its memory requirements for a big capture. (I'm > worried just about making file offsets 64 bits; given that the structure > is currently a linked list of per-packet records, I might be tempted to > have it just store record length information and compute the offset as > it scans that list forward or backwards.) > > The latter requires that extra data structure, *and* might require that > file offsets be ordered, so that the data structure can be scanned for > the range in which an offset occurs. I'd have to check whether, on all > platforms where the "standard I/O library" routines can be used to > access files > 4GB, either fpos_t is integral or seek/tell APIs that > accept 64-bit file offsets are available. The data structure itself > shouldn't be large - one entry for region, and most files should have a > small number of regions (you're only likely to get more than one region > if you concatenate files from different platforms). > > - > This is the tcpdump-workers list. > Visit https://lists.sandelman.ca/ to unsubscribe. > - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
