Closed rukai closed 2 years ago
You can easily use from_fn()
to create an iterator.
Thus I would advice to implement IntoIter and not Iterator directly on Capture.
Oh that from_fn is definitely handy.
But it turns out I dont actually want an iterator of Packets for my use case. What would be better is an iterator of an owned equivalent of Packet so that I can have multiple Packets alive at once. The current implementation of Packet only allows a single Packet to be alive at once due to lifetimes. Having multiple packets alive allows me to construct a vec and then rayon iterate over them.
This is what I ended up with locally:
pub struct OwnedPcapPacket {
header: PcapPacketHeader,
data: Vec<u8>,
}
impl OwnedPcapPacket {
pub fn from(packet: PcapPacket) -> OwnedPcapPacket {
OwnedPcapPacket {
header: *packet.header,
data: packet.data.to_owned(),
}
}
}
fn main() {
let mut cap_handle = Capture::from_file(file_name).unwrap();
let packets: Vec<_> =
std::iter::from_fn(move || cap_handle.next().ok().map(OwnedPcapPacket::from)).collect();
let parsed_packets: Vec<_> = packets
.par_iter()
.map(parse_packet(packet))
.collect();
}
I think iteration logic + OwnedPcapPacket being provided by pcap would be nice but if adding such an owned packet struct + iteration is out of scope of pcap feel free to close the issue.
alternatively a way to have multiple Packet's alive at once would be even better and more performant, but I think thats a limitation of the underlying pcap library, havent looked into it closely at all though.
The pcap read packet by packet, thus the user need to copy the buffer provided, read more on https://www.tcpdump.org/manpages/pcap.3pcap.html. The strategy depend on what you need. On your case if you want read the file at once I don't see the problem of the code you show here.
Capture serves the purpose of an iterator: there is a
next
method. But it does not implement the Iterator trait making it difficult to compose with the rest of the rust ecosystem.