> Nothing currently uses them - the progress bar for writing out a capture file counts packets, not bytes, and making it count bytes would require a pass through the capture to ask Wiretap how many bytes each packet would require before writing the file out - and writing out a capture file doesn't necessarily proceed 100% sequentially in any case.
> Is there any use for those routines, or the bytes-dumped count they fetch and set? Guy, I have some code that takes advantage of wtap_get_bytes_dumped(). It is an enhancement to editcap that allows the user to specify an approximate upper limit on the size of output file segments (akin to the -i or -c switches, except specifying KBs rather than seconds or frame counts). Implementing this feature required that I make a pass through many of the file formats to insert code that correctly increments the bytes dumped counter as blocks of data are written to the file. And while it is true that some file formats do not write contents to the file sequentially, all the ones that I looked at (all that support Ethernet encapsulation) advance the file size linearly from start to finish, but may go back and fill in areas that were skipped over. For example, some file formats don't write the file header until finalizing the file, when things like frame counts are known. But the file header must be skipped over during initialization, so the bytes dumped counter is incremented then, rather than when the header is actually filled in with valid data. So the value returned by wtap_get_bytes_dumped() as I implemented it can be thought of as a file size high water mark, and is accurate up to the last write operation. My editcap algorithm would determine if the next packet to be written (and only the packet, not any accompanying header/metadata/what have you, would exceed the user-specified upper bound, and if so start a new file. The resulting file may exceed the upper bound by a maximum of a single frame header plus a file footer (if the format requires it). But that's OK if you can accept that the user is specifying an approximation. But you are right; if we want complete accuracy when writing then another function is necessary to ask Wiretap, "how many bytes are you about to write for this operation", where operation could be opening the file, writing a packet, or closing the file. I did not use the wtap_set_bytes_dumped() function for any of this, instead electing to increment the wtap_dump->bytes_dumped field directly. I personally feel that wtap_set_bytes_dumped() should not exist, or if it does it should not be exported outside of the Wiretap library as it allows clients to muck with internal state. Robert Bullen U.S. BANCORP made the following annotations --------------------------------------------------------------------- Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. ---------------------------------------------------------------------
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
