MadMathLabs

The Pious Paladin network is a breakthrough, mainly because I feel I am taking one step backwards and then two steps forwards. The new network is being designed to be easy to understand, maintain, and update. I’ll go over a bit how the current network is working, and then explain how the new networks differs.

The Current Ornery Network:
The main files that deal with the Client <-> Server relationship are the mplay_server and mplay_client. The mplay_messaging file that is in the networking folder is not even used, though the code is copied into the mplay_client and the mplay_server. I’ll wait with that fact for now and explain how the Client and Server work together.

When a user starts the software they create a client by loading the mplay_client. This client creates a few needed objects so that data can be sent and received, the Client’s data (pulled from a client_base class), the Client’s network socket, and the Clients inbox and outbox.

When the Server is started it creates similar objects, a Server inbox, a Server outbox, a Server network socket, and some dictionaries for the rooms and players. When a Client connects to the Server, the Server creates a Client dictionary entry that holds Server created Client objects, allowing the Server to have one network socket for each Client.

Data is sent through the connected sockets. Clients send data to the Server, and then the Server disperses the data through the Server created Client sockets.

Somewhere during development the mplay_messaging script become a part of both the Client and Server scripts and was reused less. Clients and Servers started dropping data directly into the outbox. Pious changes this.

The Pious Network:
The Pious Network breaks the network engine into five main gears.

The five Network Gears:

1. Comm: All communications pass through here.
2. Server: Listens for Clients, handles Server <-> Client connections.
3. Client: Client, re-used by Server (replaces client_base), handles Client <-> Server connections.
4. ServerComm: Handles non-connection related Server -> functions.
5. ClientComm: Handles non-connection related Client -> functions.

This breaking up of the network will make the network far easier to maintain, and it works just like before, only with added functionality.

Here is how the Pious Network works. The Client first creates the Client which creates all the needed objects, sockets, inbox, outbox, a client dictionary which contains the object values that will be sent to the Server, and a CommGear which is used to transmit and receive data.

The Server operates in much the same way as before, it creates all the needed sockets, inboxes, outboxes, a dictionary of rooms, a CommGear, and when Clients connect the server builds that Client with the exact same script as the Client; so each Client has it’s own separate and retrievable socket.

All data is transmitted through the CommGear, so if a data transmission problem occurs we know exactly where to look. The Client and Server gears will focus on the connection relationship, so if there is a connection problem we know exactly where to look. Both the Client and the Server will have a Commands Gear that handles the functions that work outside of connectivity; ei, changing rooms, changing roles, changing names, and other basic functions.

This further breaking apart is something that will set the Pious Network apart from the current Ornery Network by allowing for a server to communicate to different protocols.

Protocol 4.2 (The Traipse Pure Network v.1):
Protocol 4.2 will be a new method to send and receive data for both Clients and Servers. Using the ClientCommGear and the ServerCommGear I will be able to pull the protocol from the version script and make a decision as to which protocol to use.

The new protocol will truncate data that is sent. The Server already has a dictionary of each Client connected, and each Client has a dictionary of each Client in the room, so sending all of the data needed to refill that dictionary is way too much data being transmitted over the network. Protocol 4.2 will change that.

Protocol 4.2 is currently far from complete but I will explain how it will work. A Client with Protocol 4.2 connects to a server that uses the Old Ornery (or basic OpenRPG) Network. The Client defaults to Protocol 2.1. When that same client connects to a Server that uses Protocol 4.2 the Server understands that and accepts the new protocol XML strings, but then the Server iterates through all the Clients in the dictionary and builds an XML string for each clients Protocol that it understands.

I am going to leave the explanation at that so I don’t make promises that will happen, just later than expected.

I would like to think the new network will be far more stable than the previous network, mainly because it will be easier for a developer to read through and understand. I currently have basic connectivity working in the Dev-Shed folder.

The server software is also portable. I am working on a new Command Line Interface for the server which simply imports the ServerGear. When I get around to building the ServerGUI I will be using the exact same ServerGear as a basis. The network is far from complete, but with this approach I believe I can eradicate some old demons.

I am currently looking at the Map and will post about that in the near future. The new map is going to have some really interesting features.

Leave a Reply

You must be logged in to post a comment.