Dear all,

I’ve been working on the generalizations in Protocols/Generics for a while and I’d like to share with you some of my visions and discoveries. I’d appreciate some feedback too!

In my dev branch (developers/peter/calitko-dev) you can find the class Protocols::Generics::PacketSession with tests in Testing. I realized that this abstraction would allow us to map not only packets but also other pieces of protocol data. The idea behind PacketSession is that you can just send a packet over it, the object takes care of packet buffering (or even flow control as a special case of buffering), packet serialization in both directions and will forward every received packet to a handler.

A BitTorrent Transfer would keep a number of PacketSessions with different peers having the same file. Similarly our Gnutella LocalPeer would keep a number of PacketSession for each of the connected network peers. The users of PacketSession could just concentrate on handling incoming packets, figuring out what to do with it and deciding what kind of packets to send out. Each protocol would provide a PacketSerializer that would know the binary format and will be capable of converting packets from and to raw bytes. Each protocol might provide its own PacketQueue or use an existing one (e.g. FixedSizeQueue). For example, flow control for Gnutella could be implemented in the PacketQueue. When the session could not send all outgoing data fast enough flow control decides which packets can be dropped and which have priority.

Now the interesting part is that the very same approach could be used for HTTP – we only need to suitably split HTTP messages in “packets” (though I think a more abstract Data would be better). For example HttpData would be HttpHeader (HttpRequestHeader, HttpResponseHeader), HttpBodyChunk. Now if we consider each a kind of Packet, then we could reuse the same PacketSession. Because PacketSession is so generic, I think we should better call it just Session. Then we could also define an abstract base class Data that Packet will derive from. We could also think of a generalization Message for text-based messages (like HTTP headers or XML messages) that also derives from Data.

Another thing I noticed is that for Session I don’t really need the connection part of Transport. That kind of supports the idea to split the interface Transport into Buffer and Connection. Because Session is essentially a kind of a buffer too, so why not call Buffer RawBuffer and Session DataBuffer?

Comments and ideas are welcome!

Regards,

Peter