Hi Petr,

Thanks for the comments! I’m replying to some of them here.

I’d stick to the current approach in this case and if we find out that there are too much if’s when handling Data (and that a Null data object could become handy), we can refactore it. It’s now consistent to the DataSerializer::write() approach, too.

OK!

If the DataSerializer wouldn’t be “used” (maybe exploited is a better word) for writing data into something different than a transport (e.g. directly to a file), I’d write there explicitly that it writes/reads data to/from a transport. The idea of passing a Transport object by reference to read() and write() functions makes sense for me and I think it would become more clearer!

I was actually thinking about the possibility of implementing a FileTransport! :-) It would thus be possible to dump packets for example directly to a file :-).

Glad to hear you agree about passing Transport as a parameter!

I was first wondering why there are the setStatus() functions :). Could you please expand the example a little bit? I don’t get why we would need to change the status notifier in the example if there are two separate sessions (handshaking and packet). Maybe if there is a session that can “do more things” or can change it’s behavior dynamically than it would be useful.

A Transport object is clearly created and connected once. Possibly a single Session object attached to the Transport could be used thereafter. However, if like in Gnutella the session gets negotiated (handshaking) by exchanging HTTP-like headers, then you need one kind of a Session temporarily (HandshakingSession) and then another one (PacketSession) for the rest of the lifetime of Transport. There are generally two options: create one Transport and one Session and change DataSerializer and possibly DataQueue, another one is to create two Sessions and once the first one is no longer necessary, the second one could be set to receive the status notifications.

Have a nice day!

Regards,

Peter