Introduction
This document describes the network architecture of Nautdrafter.
Overview
The above diagram is the current network architecture. The Nautdrafter UI represents the player's application which contains the networking components: Lobby Client, Drafting Client, and optionally the Drafting Server. The Lobby Client connects directly to the Lobby Server which is currently hosted on Digital Ocean but is being migrated to a KVM/Libvirt based virtulzed environment hosted by MichaelS (the current limiting factor is the TTL on the DNS server resolving to a different IP). If the player creates a drafting server, the drafting server is created locally and the lobby server is notified via the drafting server. The lobby server notifies the lobby client of available drafting servers (including drafting servers that are created locally to the client). The client connects to the drafting server through the drafting client.
Proposed Architecture
The above diagram moves the drafting server onto the same physical server as the lobby server. This simplifies the client side architecture. This diagram doesn't show how the dedicated server handles managing the drafting servers as its only describing the network architecture.
Protocol
The network protocol was developed by Jeremy Symon and is a custom design. The network protocol uses TCP and Java Sockets. Essentially, bytes are written to and read from java sockets. The protocol refered to in this section is how the data is managed and how it flows.
The Packet class represents the data that is transferred across the network. The Packet contains methods for converting Objects used by the server and clients into a streamable form and back again. The Packet also contains a mechanism for a client or server to perform an action or actions based on the message that was sent or received.
The diagram above shows the high level actions that takes place on a server when it receives data from a client. First the Server reads in the data. It creates a packet (determining the type for specialization). Once the packet is fully read in and created, the Server calls the handle method on the packet. The handle method determines what actions need to be applied. The packet can also define interfaces that enable specific actions to happen on the client or server which is known as a callback.
Jeremy Symon I am not sure I have got this correct, but its my understanding that a callback only allows the Packet a mechanism to do some action on the client/server that the packet is decoded on.
Meaning, if a client sends a login packet to the server, the server could have a callback that checks for the client's credentials. It doesn't mean that the server will send data back to the client right? Apart of the initial callback though, the server could send a new packet to the client right?
If the above is the case, I think callback might be a bit misleading of a name. When I think of callback, I would think of the scenario where the client sends a packet to the server and the client will receive some from of ACK or apply some action. Maybe its because I am accustomed to using something RMI?