Guy Harris

> If the Section Lengths are updated after the fact, then starting new Sections within a file periodically could make a large file more easily navigable/seekable. Presumably for "navigable" you...

> Right, navigable meaning an index of Sections like book chapters in the UI. With Section Lengths present this could typically be generated in less than a second. But section...

> I think that multiple Sections per capture or file can be useful, and would be worth supporting in libpcap. The capturing application can do most of the work. So...

...and, of course, only do that if the total number of bytes worth of blocks written to the section, after the SHB was written, is < 07FFFFFFF; otherwise, it won't...

Also, we may, in the future, support modules for the lower-level IO part of reading and writing capture files, to allow asynchronous I/O, direct reading and writing of compressed files,...

> > So a call that causes the next block provided to the callback to be an SHB, followed by a set of IDBs? > > Either that, or require...

> If packet blocks and other blocks are compressed, but SHBs are not, then updating the Section Length would still be possible. The most common forms of compression are 1)...

> Yes, provided the Section can be switched after a block has been received for the new section. Or the new *file*; a "start a new section" call would also...

For ASCII (and other single-byte character encodings), there can be a one-to-one correspondence between offsets into the packet and positions in the display. For multi-byte character encodings, a decision has...

Sequences of bytes that are valid UTF-8 characters but that are not printable characters should be displayed as ".", just as bytes that are not printable ASCII characters are displayed...