A good understanding of the medium and its facilities requires also a description of the implemented algorithms used in communication, timestamp maintenance, distributed topology maintenance etc.
 

3.1. Portability (100% Java)

JVM is certified Sun 100% Pure Java  code. (JVM version 5.0) It doesn't make use of any unstable or incomplete changing packages like the java.awt or alike and doesn't contain any deprecated code fragments. It runs on any Java 1.1 enabled platform. It was thoroughly tested by us on Linux, Solaris, Digital Unix, Windows 95, and Windows NT. The Sun delegated Java Testers (Keylabs) also tested the system for 100% Java compliance on severall platforms. This assures for a wide portability of the system on virtually any hardware, which is a pre-necessary important feature without which the main goals are not attainable.

The system makes full use of the provided Java Object Serialization mechanisms. Most of the components are implementing the java.io.Serializable interface and are transportable over the network. This rises some issues as to how native applications (non-Java programs written in certain hardware machine code) may interface with the medium. In order to overcome this the medium also provides a text mode pre-login protocol which allows for some control and interface to the medium. Another way for an application to interface to the medium is to comply with the Java serializable standard or to use a Java wrapper. This last approach is the recommended way to interface a hardware system dependent code with the system. Take a look at the Talking Objects specifications for some insights into this.
 
 

3.2. Single-server medium

A single-server implementation of the medium is provided through the distributed communication handler plugin running in local operation mode. This means that the active communication handler is set to jvm.server.DistributedCommunicationHandler but the system watchdog is set to jvm.NullAuthHandler.

Many issues that appear in the distributed multi-server case like timestamp maintenance, messages forwarding, distributed grouping etc. don't appear here. This offers the ideal solution for any single-server star alike network structure. Examples might include chat applets, multi-user single-server games and any communication structure that doesn't require a distributed wide area topology and uses a single central server instead, to do the whole job. Take a look at the Simple JVM Chat Applet example (Applications chapter) implementation for an example. Also, by benefiting from the transparent approach, it might be used in testing complex schemes built on top of the system. See Talking Objects for an example.
 
 

3.3. Distributed multi-server medium

The actual power of the system comes to light in the case of the distributed multi-server communication handler plugin running at its full power. This allows for a distributed network topology composed of many servers communicating with each other in a dynamical manner, building up a potential global-wide medium of entities far away of each other able to use together the provided medium facilities.

This case brings about complex issues such as inter-server connections, overall timestamp maintenance, message forwarding, distributed grouping etc. We are now going to enter more detailed explanations on how we solved each issue.


 
 

3.3.1. Inter-server connections

How do two servers communicate with each other? This issue is determinant for the provided system performances and algorithms. The used solution is an elegant way of keeping things fast and simple. In order to start a connection to a new given server, the current server connects to the remote server as a simple client entity. Then it tells the remote server that he actually is a server entity, via a first special control message (IAMSERVER). Once the remote server gets the message, it removes the connection from the ordinary normal entity structures and begins to treat it as a server connection. The approach is simple, just sending a message to a remote server starts up a new connection from the current server to the remote server. The connection is not closed afterwards rightaway, but a certain timeout mechanism is implemented. The topology is also initially created by the provided (required) distributed maintenance server watchdog (jvm.server.DistributedMaintenanceWatchdog) which acts also as simple connection activator client inside the system.
 
 

3.3.2. Overall timestamp maintenance

Timestamping is important issue in any distributed system. Being able to consistently timestamp each action inside the whole system, using a single timestamp scheme is not easy and there are many algorithms out there trying to solve this. We designed a custom algorithm (it might well be designed before by someone else ;) which aims for simplicity and a guaranteed minimal fault tolerance.

Each message contains a timestamp field, which is used in implementing the whole algorithm. This field is used in computing consistent timestamps in all cases, server-server, and server-client communication.

A timestamp is (currently) a 64bit value which is defined inside the UTC timespace (ms elapsed from 01.01.1970). Each server has it's own current timestamp value. The main idea is not to set each server's time to a single central one but to place a given event, message etc. consistently in the current server's timespace. That is even though in the case of the same message which gets transferred through 2 servers, on each server the timestamp for this message gets to be set to a different value, that value has the same meaning on both servers in terms of time localization. A good example would be me being in Europe working at 14pm, that is a value of 14, am considered simultaneous with my friend in the US who's local time is 8am, which is a value of 8. The timestamp difference in this case is 6 although the events are considered to be simultaneous.

A client entity is supposed to use the current server time as being it's own current time although this might not seem very natural. The idea is that the entity is connected to the medium via the current server and is represented thus by this server inside the medium. First we are going to describe how a client entity is able to get the current server time. Upon connecting, the client entity computes the connection speed. It then receives the first message and looks at its size and at the timestamp it contains (server time when the message was sent). It then computes the current server time by adding the time the message needed to be transferred, using the given connection speed and message size, to the message timestamp. It obtains thus an approximation of the current server's time, which the entity uses to set an internal timer.

In the case of cross server messages the timestamp scheme is somehow different. On establishing (dynamically) a connection to another server, the current server computes the connection speed and inquires about the timestamp difference between the two servers. (See above Europe-US example). It then computes a timestamp difference that is added on each outgoing message that has to be transferred to that given server. On arriving inside the other server this message has a locally consistent timestamp already set. On receiving a message, a server only computes the difference pertaining to the connection speed and message size related issue.
 
 

3.3.3. Message forwarding

Message forwarding is the ability of a certain server to forward messages received from a remote sender server to another remote destination server. This might be used in order to create certain structures with central directory servers etc. Those variations are not encouraged as they are actually against the real goals of the whole distributed system design. Therefor the recommended setting should be to disable message forwarding on most of (all) the servers in the medium.
 
 

3.3.4. Distributed grouping

We refer here to distributed grouping as being the ability to send to all the entities that are part of a certain group in the whole medium. This is not easy to attain and it still needs a more optimized implementation. When a message is received by the multi-server distributed communication handler from a local connected entity, with the destination being a groupbroadcast inside a certain overall group, it simply sends the message to all the connected servers, leaving the task of actually sending to all the corresponding entities to the remote servers. This is a un-optimised implementation because there might be servers that don?t have any locally connected entities belonging to that group in which case a waste of bandwidth occurs between the source and destination server.