Structure

Thinking about the best way to structure the TCP regression framework. A few things immediately jump out at me:

• Handle either IPv4 or IPv6 gracefully
• Reuse the most code possible
• Easy generations of responses (e.g. create new Chain, with corresponding TCP layer with filled-in fields like Sequence number, Ack number, Ack flag, etc.)
• Ability to test that the opposite side is actually getting a connection and recv'ing data
  

Handling IPv4 and IPv6 Gracefully

The simplest way to do this would be to define an interface and two implementations. However, I need to look into the differences between IPv4 and IPv6 a bit more -- static header size may preclude IPv6 from needing some tests, and there may yet be other differences.

Code Reuse

Code reuse will likely fit into the same category as above. Simple interface/implementation class hierarchy may do the trick. However, aside from the direct manipulation of the tests, there may be some tests which are a subset of other tests, or the same test may need to be run under multiple circumstances. Preventing duplicated code is something I really put a high priority on.

Response Generation

Response generation will also be a subset of the two above areas. For example, let's say I send a SYN packet, and I find the corresponding SYN/ACK packet. Having a method that generates the final ACK packet would be beneficial (or that generates an ACK packet to any packet).

Connectivity Testing

Connectivity testing should be fairly trivial. Basically, set up an echo server. If the connection is properly established, the data should be echoed back without problem. This particular solution should also lend itself to testing window sizes.

Side Note:
The blog client Blogo is amazing. Full-screen, rich-text editing FTW.

Read more...