Hi Bo,

Thanks for the comments! It is true that typically the session and presentation layers are ignored and only application layer is regarded (e.g. HTTP). I thought it would make sense to somehow reflect the ISO/OSI layers into Calitko design. I also thought that referring to the layers would make it easier for new people to understand better the design of Calitko. I might be wrong though and it may be confusing, so if that is the case please let me know.

Depending on the context it would also make sense to have different mapping of protocols to layers I think. For example, HTTP is classically assigned to layer 7, however, in the context of WebServices it is used as a transport, so I would rather map it to layer 4 in this context. I think that partly answers the question why we need transport layer. Yes, the OS provides us TCP and UDP sockets, but we might want to implement some transport protocols based on UDP, for example Limewire’s F2F protocol. To do this, we should derive from Connection and implement the derived class on top a UDP socket. This way wherever we use a Connection we can also use the new transport protocol.

Regards,

Peter

Bob wrote:Hi everyone,

My name is Feng Bo and from China. I am a freshman in Calitko.

Now I only have one idea.

• What do you think about the ISO/OSI layers to classes mapping?

OSI layer architecture is a good suggestion of layered structure and can also be used in Calitko design. But we don’t need to follow it exactly.

In many cases the presentation and session layers are not used, they are just combined with application layer. In Calitko we can also merge these two layers to one, if they are really closely coupled. Otherwise we will spend much time on discussing, if a class belongs to this layer or that one.

Transport layer: Do we really have transport layer? I think it is done by OS.

Best wishes!

Bo

Peter Dimov wrote:

Hi guys,

I’d like to invite all of you to join the development of the new generic PacketSession by doing some brainstorming with me first. Please share all ideas that come to your mind while/after reading the short description of the problem we have to solve. There are not stupid ideas! All ideas are great and any idea could lead to an even greater idea! We have quite some minds reading here already and it would be real pity not to put them into action!

The Background
Currently Calitko tries to match the ISO/OSI layers to types of classes. Here are some examples (which may not be what most of us have read in textbooks):

Application Layer => TODO FileDownload, FileUpload, SearchQuery, SearchResult - high level abstraction of different protocols, which can be mapped to the concrete ones (HTTP, Gnutella HTTP, BitTorrent, etc).

Presentation Layer => Packet (Gnutella/BitTorrent), Header (Http, Handshaking) - the higher level data exchanged on the session level.

Session Layer => PacketSession, HandshakeSession, ClientHttpSession, ServerHttpSession, BitTorrentSession - work on top a Connection object, understand the binary/text format of the data exchanged and thus provides a higher level abstraction of the communication.

Transport Layer => Connection - reliable/unreliable, stream/datagram oriented, takes care of connection establishment and data exchange (no abstraction, just bytes).

Network Layer and below => N/A

If you take a look at the documentation you’ll notice that the session and presentation layers were drawn on the same level, which should be clear by the description above.

The Problem
The problem is what is a simple but yet clever design (both interface and implementation) for the actual classes and especially PacketSession. Here are some questions (please write down right away all ideas that come to your mind):

• What do you think about the ISO/OSI layers to classes mapping?
• How can this mapping be improved?
• If you had to use PacketSession, what would the interface you think you’d need?
• Would you like to derive from PacketSession for each concrete protocol and extend the interface suitably?
• What about protocol dependant state per session (like choked, interested for BitTorrent or node info like ultrapeer, peer, leaf for Gnutella?
• What about traffic stats? Store them in the session or externally?
• What further questions/ideas do you have?

I’m really looking forward to getting some interesting ideas and a fruitful discussion!

Best regards,

Peter

P.S. Here are some of my thoughts. Please read them only after you’ve already thought about and written down some of your ideas. I hope some of you will also reflect on these thoughts as well:

For example, the interface could look like this:

PacketSession (Connection *, const PacketFactory &);

void sendPacket (const Packet &packet);
int readTimeout() const;
void setReadTimeout (int);

signals:
void	packetReceived (Packet &, PacketSession *);

Also, I think it would be cool to be able to implement some of the functions like this:

void PacketSession::readPacket()
{
auto_ptr
packet = p->packetFactory->extractPacket (*p->connection);
// If a packet cannot wet be extracted a null pointer was returned:
if (packet.get() != 0)
emit packetReceived (*packet);
}

void PacketSession::writePacket()
{
if (p->pendingPackets.size() > 0) {
Packet *packet = p->pendingPackets.first();
// If the connection buffer is full writePacket() will fail.
if (p->packetFactory->writePacket (packet, *p->connection))
delete p->takeFirst();
}
}

The above would require some modifications in PacketFactory (provide extractPacket() and writePacket() and in Connection (being able to buffer some raw bytes, peek() the read buffer, being able to say whether a number of bytes can all be buffered in the write buffer).