Hi Sebastien,

Thanks for the comments! Brainstorming should be going on all the time ;-). Thanks to your comment about the TCP/IP model vs. the ISO/OSI model, I think I finally understood why is all this confusion about which protocol belongs where in the ISO/OSI model. So actually, the TCP/IP model only has network, transport and application layers. The application layer protocols from the TCP/IP suite are incorrectly mapped to the application layer of ISO/OSI as they contain parts belonging to session and presentation layers as well. I see we are on the right track of splitting them and hope we are doing it fine.

You suggest to have a function checkConnection(). It should actually belong to Connection unless ownership of the Connection object is passed to PacketSession. Than maybe add a state() functions that returns the current state of the session? The actual state will be protocol dependent though.

The signal receivedACK() made me think of how a UDP based transport would be implemented. Actually the ACK would also be a kind of packet, meaning it would be emitted in receivedPacket(). What is interesting here is that to implement a F2F (Limewire’s firewall to firewall, I don’t remember the exact protocol name) transport we would have the class F2FConnection derive from Connection and use a PacketSession over a UdpConnection for the implementation :-). This shows pretty well that being session layer or transport layer depends largely on the context.

Regards,

Peter

sebastien venot wrote:Hello,

Here is my thought on this problem(if the brainstorming is still going on :) )

• What do you think about the ISO/OSI layers to classes mapping?
• How can this mapping be improved?

To follow some kind of architectural structure is always a good idea.Any p2p system needs a transport layer for transfering data,session layers to handle time based connection and handshaking, presentation for packet format, languages support, encryption,compression
and application for services such as file search …

if we apply the TCP/IP”model, then we can merge application/presentation/session layer in one, but that would just put a lot of classes under the same package which might not be best.
Following OSI model is good idea.

• If you had to use PacketSession, what would the interface you think you’d need?

Well depends if we include reliability by acknowledging packets and retransmission, so i would try something like:

packetSession(Connection con )

sendPacket(Packet p,Boolean ACK)

boolean checkConnection(Connection con )

closeSession()

signal:

receivedPacket(Packet p)

receivedACK(Packet ACK)

• Would you like to derive from PacketSession for each concrete protocol and extend the interface suitably?

yes why not

• What about traffic stats? Store them in the session or externally?

Both should be possible. the stats might be needed during a session, and it would be maybe good to store the stats in some file also.

hope it helps

regards

sebastien