Hi all,

Attached is an early version of PacketSessionTest.cpp. It won’t compile yet but hopefully you can have a look at it and give some ideas.

I think I slowly start to grasp the idea of TDT. Actually the first thing one has to do is model the environment of the classes that are about to be implemented. This helps not only to simulate all kind of flows but also helps to understand the environment better!

I now use the Ping packet but better would be to use a PacketStub instead. I also need to implement ConnectionStub. The very first version of PacketSession will be totally simple and only implement R1. When R1 is implemented and we want to implement R2, the PacketFactory can be used to read and write the packets.

I could think of more scenarios for the use case U1.1 than the ones I already posted. Take a look at the tests, they are documented. I think next I will try to get these three tests running and then add additional tests.

Any feedback is welcome!

Regards,

Peter

Peter Dimov wrote:Hi everybody, here is a follow-up to the documentation topic:

Rationale

R1. Exchange packets with a remote peer.
R2. Don’t care about the actual transport protocol.
R3. Don’t care about the actual application/session protocol and let the actual protocols extend the functionality of PacketSession.

Use Cases

U1.1. Packets are exchanged with a remote peer after a (transport layer) connection has been negotiated.
U2.1. Exchange packets over a TCP transport.
U2.2. Exchange packets over a UDP transport.
U3.1. Exchange Gnutella packets over the PacketSession.
U3.2. Exchange BitTorrent packets over the PacketSession.

Scenarios

S1.1.1. Send a packet to the remote peer
S1.1.2 Receive a packet from the remote peer.
…

My suggestion would be that Rationale and Use Cases are part of the class documentation, whereas the scenarios are the documentation of their corresponding unit tests (which I hope I’ll be able to provide as well soon).

I’m looking forward to reading your comments!

Best regards,

Peter