It might seem odd to go from the overall design in part one, to getting all down and dirty with the networking parts. But as I have mostly concentrated on this part for most of my earlier attempts, as well as doing quite a lot of network programming in my different works, this is something I am very familiar with and I’m very much at home designing network servers and clients with intricate protocols.
This part is where most of the multithreading parts of the server will be, as each listening network port will be a separate thread. In the future there may even be thread pools for the connections from the users as well, but it is not needed yet.
Protocols, ports and connections
One of the main design decisions of the networking engine is that it should be able to handle many connections from just as many different clients, and that each clients could use a different protocol.
There may be many different network ports open at the same time, each handled by a separate thread. These threads does not need to communicate directly with each other, only the main thread that handles the input.
Tied to each network port is a protocol, so clients using e.g. the telnet protocol will all be connecting to the same port, while clients using some other protocol will be using another port. This means that all protocol handling, and translating the protocols into something the server can use, will be done in the same thread as the port the protocol is connected to.
Implementation details
Much of the actual details will be handled by Boost::asio. Everything will be implemented in the raven::net namespace. The ports and protocols will be put in separate namespaces as well, to separate functionality.
I do not know yet if the classes should be templates with the character type as template argument, so we will be able to handle both normal ANSI and the different Unicode encodings.
Ports
There are many types of underlying connection protocols used on the Internet, but in reality only two are commonly used: TCP and UDP. Actually, that in itself is four different communication protocols, since each come in two versions: Version 4 (most commonly used so far), and version 6 (which will be used more and more in the future.)
This means there will be four ports classes: tcp_4_port, tcp_6_port, udp_4_port and udp_6_port. Most of the code of these classes will be similar though, so it is only natural to have a set of common base classes: basic_tcp_port, basic_udp_port, and the most basic of them all: basic_port. There will also be two base-classes handling the IPv4 and IPv6 specific things.
Protocols
From the beginning, there will be only support for the telnet protocol. Many MUD servers and clients have made extensions to the base telnet protocol, but I have so far not decided if these should be implemented in the base telnet protocol or as separate protocols.
There will be only two classes needed for protocol handling from the start: telnet_protocol and its base-class basic_protocol.
SSL
It has to be possible to connect to the server with an encrypted connection. This will be done though the use of SSL, the same method used for secure (https) web-sites.
SSL-connections will be made through a special port, so the actual protocol used by the clients after the SSL-connection is established will be handled like any other protocol and port in the server.