6 Plug-ins

Plug-ins will provide the ``intelligence'' in flowreplay. Flowreplay is designed to be a mere framework for connecting captured flows in a flow file with socket file handles. How data is processed and what should be done with it will be done via plug-ins.

Plug-ins will allow proper handling of a variety of protocols while hopefully keeping things simple. Another part of the consideration will be making it easy for others to contribute to flowreplay. I don't want to have to write all the protocol logic myself.

6.1 Plug-in Basics

Each plug-in provides the logic for handling one or more services. The main purpose of a plug-in is to decide when flowreplay should send data via one or more sockets. The plug-in can use any non-blocking method of determining if it appropriate to send data or wait for data to received. If necessary, a plug-in can also modify the data sent.

Each time poll() returns, flowreplay calls the plug-ins for the flows which either have data waiting or in the case of a timeout, those flows which timed out. Afterwords, all the flows are processed and poll() is called on those flows which have their state set to POLL. And the process repeats until there are no more nodes in the tree.

6.2 The Default Plug-in

Initially, flowreplay will ship with one basic plug-in called ``default''. Any flow which doesn't have a specific plug-in defined, will use default. The goal of the default plug-in is to work ``good enough'' for a majority of single-flow protocols such as SMTP, HTTP, and Telnet. Protocols which use encryption (SSL, SSH, etc) or multiple flows (FTP, RPC, etc) will never work with the default plug-in. Furthermore, the default plug-in will only support connectionsto a server, it will not support accepting connections from clients.

The default plug-in will provide no data level manipulation and only a simple method for detecting when it is time to send data to the server. Detecting when to send data will be done by a ``no more data'' timeout value. Basically, by using the pcap file as a means to determine the order of the exchange, anytime it is the servers turn to send data, flowreplay will wait for the first byte of data and then start the ``no more data'' timer. Every time more data is received, the timer is reset. If the timer reaches zero, then flowreplay sends the next portion of the client side of the connection. This is repeated until the the flow has been completely replayed or a ``server hung'' timeout is reached. The server hung timeout is used to detect a server which crashed and never starts sending any data which would start the ``no more data'' timer.

Both the ``no more data'' and ``server hung'' timers will be user defined values and global to all flows using the default plug-in.

6.3 Plug-in Details

Each plug-in will be comprised of the following:

1. An optional global data structure, for intra-flow communication
2. Per-flow data structure, for tracking flow state information
3. A list of functions which flow replay will call when certain well-defined conditions are met.
   • Required functions:
     • initialize_node() - called when a node in the tree created using this plug-in
     • post_poll_timeout() - called when the poll() returned due to a timeout for this node
     • post_poll_read() - called when the poll() returned due to the socket being ready
     • buffer_full() - called when a the packet buffer for this flow is full
     • delete_node() - called just prior to the node being free()'d
   • Optional functions:
     • pre_send_data() - called before data is sent
     • post_send_data() - called after data is sent
     • pre_poll() - called prior to poll()
     • post_poll_default() - called when poll() returns and neither the socket was ready or the node timed out
     • open_socket() - called after the socket is opened
     • close_socket() - called after the socket is closed