libpcap does so little you're better off doing that yourserlf and avoiding going through the library, giving you more control on I/O and memory management. As

libpcap does so little you're better off doing that yourserlf and avoiding going through the library, giving you more control on I/O and memory management. As for the library interface, what I usually need is to synchronize a pcap stream with other sources of historical data (some of them other pcap streams, some of them log files). Doing this requires knowing the timestamp of the next packet before I process it so that I drain all events prior to that packet before I process said packet. The iteration API provided doesn't really make it easy to achieve. I also often need to re-order a pcap stream in a sliding window, decode time using a combination of the Arista keyframes and FCS timestamping. My input is typically compressed on-the-fly and split into multiple files which isn't exactly handled here either. The way my own library does this is that you can either process a stream from memory or from an arbitrary file descriptor (which can be a pipe hooked up to something that concatenates or decompresses data). I haven't looked too much at the packet decoding/encoding, but anything that allocates memory is a big no-no for me, and it seems it does. Doesn't seem to be much of an improvement over Tins.