The CommunicationServer

The CommunicationServer handles all in- and output over the plain sockets protocol. It uses for that purpose two other objects, the ConnectionListener and the class Connection. The Connection class holds an incoming connection and provides the using class with the input and output streams. Further it contains methods for timeout on the connection level. Since timeout it used on the socket level this option still remains, but is not used. The ConnectionListener is a thread which listens on the given port to incoming connections. If a new connection is demanded, it creates a new Connection and gives this to the CommunicationServer.

The CommunicationServer maintains all open connections and calls the desired methods on registered proxies. Also it provides the methods necessary to call methods on another System over the plain socket connections. For calling a method on another Agent System over plain sockets it provides the method remoteCall(Location target, String methodname, Object[] parameter). To connect to another PLSCommService it also needs to know the port to connect to. The port can be provided in the target parameter. If is not provided there the method asks the MAFFinder to return the plain socket register entry of the MAFFinder for the given target System. It then calls the method remoteCall(Location target, String methodname, Object[] parameter, int port) to send the method to the target System. This method creates a new socket to the target System sets the timeout and sends the method name and parameter to its partner CommunicationServer over the net (see subsection ``The Protocol used'' of Section on page for details). Then it waits until an answer is sent from it. This answer could be a normal object or, if there was an exception, the thrown exception which is nothing more then an object. If it returned an exception the method throws this exception, else it returns the received answer.

The receiving of calls from outside is also handled by the CommunicationServer. A CommunicationServer from another Agent System connects to the local communication server and sends it the name and the parameter of the method to execute. This is done by requesting a connection which results locally in creation of a new Connection object. When new data is available on this Connection object the two objects (name and parameter) are read from it. In order for the communication server to know what methods can be called and on which object, all ``call - receiving'' objects have to be known by the communication server. It uses therefor a very similar mechanism as the plug in mechanism of the platform. A receiver object registers itself at the CommunicationServer using the method registerProxy(Object obj). The registered objects are stored in a Vector. There are two objects that are being registered in the CommunicationServer: The PLSCommProxy and the PLSMAFFinderServiceProxy (in wrapper modus). When now a request arrives for calling a method, the server looks at the methods the registered proxies offer and calls the one with the matching name. In this version there is no check for the right parameters implemented, resulting in the requirement to have only different names in the proxies. Since there are only a few proxies used (PLSMAFFinderServiceProxy and PLSCommProxy) it is very easy to keep this requirement.

This is also very similar to the registering of objects in the RMI registry, which also has to know what object can be called. After calling the desired method the return value is sent back to the requester. If an exception has occurred while calling the method, the exception is sent instead of the (in this case not existing) return value. This exception is then thrown on the senders machine, as described before.