• Asynchronous Message-based Communication

Asynchronous Message-based Communication... Huh?

A key concept in OpenRPG2's design is that the underlying network connections have been totally separated from the rest of the system. Network message construction is also largely removed from the equasion as well defined messages are converted for network transmission transparent from the developers code. All data is passed around the OpenRPG2 system using a fixed message format in the form of an ORPGMessage class. The Asynchronous behavior of the messaging system comes from the use of a pool of indepent processing threads.

A simple way to think about how an OpenRPG client and server interact is to compare it to a webserver and webclient. In this analogy the webserver is equipped with a number of PHP scripts (independent modules) that have access to local variables, databases, and files on the server. As a webclient makes a request the server locates the proper script and executes it using the request. The script runs, accessing data from databases, leveraging other scripts, updating local variables, etc and then may or may not return data to the client via the webserver. The webserver manages the actual network connection while the script is responsible for working with client requests and generating messages for the client.

The OpenRPG2 system is 'semi-stateless'. While a persistant TCP/IP socket is maintained between the client and server inside the network layer the rest of the OpenRPG2 code passes messages to and from the client by dropping and retrieving messages from a pair of message queues (like mailboxes). The ramifications of this system are simple but significant. There is no guarantee that messages will handled in any specific order as underlying Java VM implementation controls the execution patterns of the threads which will handle the message processing as well as network i/o. The scheduling and context-switching of these threads is not defined in the java specification and is VM implementation dependent.

OpenRPG2 is designed to be flexible as well as extensible. To this end we have adopted a modular system of plugin modules. Some modules will be considered 'core' and critical to the operation of OpenRPG. Other modules will be optional or community-generated plugins. The messaging system is designed to allow a client or server to handle messages in a uniform manner and be able to cope with messages they don't have handlers for. This is where the default 'drop unknown messages' concept comes from. Because of the communication between modules using messages as well as using messages for communication with client/server all modules operate on a peer-to-peer level with other modules. The only guarantee with message handling is that a given message will be sent to the appropriate registered handler. There will also not exist any hard coded references for how a given message should be routed. Every module will register its type with a central message routing agent when it is loaded.

Special care needs to be taken with the initialization phase of an OpenRPG2 network connection. This is the point after the connection has been established (exchange of a simple challenge phrase) and before the client may interact freely with the server with arbitrary messages. Because we have no guarantees that initialization messages will be sent or returned in a given order, or at all, some form of special handling needs to be devised to prevent clients from sending messages to a server that requires pre-initialized data (such as a chat message being sent before the client name has been determined or a GM status request before the client has been added to a room). This currently represents a significant challenge to the OpenRPG2 developers.