Next: 4 Multiple Independent Flows Up: Flowreplay Design Notes Previous: 2 Features
Flowreplay must be able to process multiple connections to one or more devices. There are two options:
Although using libpcap/libnet would allow more simultaneous connections and greater flexibility, there would be a very high complexity cost associated with it. With that in mind, I've decided to use sockets to send and receive data.
Because a pcap file can contain multiple simultaneous flows, we need to be able to support that too. The biggest problem with this is reading packet data in a different order then stored in the pcap file.
Reading and writing to multiple sockets is easy with select() or poll(), however a pcap file has it's data stored serially, but we need to access it randomly. There are a number of possible solutions for this such as caching packets in RAM where they can be accessed more randomly, creating an index of the packets in the pcap file, or converting the pcap file to another format altogether. Alternatively, I've started looking at libpcapnav5 as an alternate means to navigate a pcap file and process packets out of order.
Knowing when to start sending client traffic in response to the server will be "tricky". Without understanding the actual protocol involved, probably the best general solution is waiting for a given period of time after no more data from the server has been received. Not sure what to do if the client traffic doesn't elicit a response from the server (implement some kind of timeout?). This will be the basis for the default plug-in.
Dealing with IP fragmentation and TCP stream reassembly will be another really complex problem. We're basically talking about implementing a significant portion of a TCP/IP stack. One thought is to use libnids6 which basically implements a Linux 2.0.37 TCP/IP stack in user-space. Other solutions include porting a TCP/IP stack from Open/Net/FreeBSD or writing our own custom stack from scratch.