Provides the fundamental network communication classes, allowing remote processes to communicate with one another either directly or via repeaters, and to look up and find servers via a dispatcher.

Two types of interprocess communication are provided: standard FXC ("raw") communication, in which each process listens on a server socket for connections, and opens sockets to other processes to create those connections; and hypertext transport protocol ("http") communication, in which an HTTPRepeaterServlet running on a web server acts as an intermediary between processes, which communicate with them via their HTTP requests and its responses. Note that all processes may communicate directly with one another via the raw method, whereas any two FXC processes that want to communicate via the HTTP method must do so via an HTTPRepeaterServlet intermediary. No provision has been made for the use of HTTP communication between server processes; these must communicate with one another via the raw method. In other words, only client-server communication may occur via an HTTP intermediary.

Repeaters, consisting of Repeater objects running as either as standalone processes (RawRepeater) or as web servlets (HTTPRepeaterServlet), enable communicating processes to exchange messages using a minimum of ports, in turn allowing communication to more easily pass through firewalls. Repeaters also enable a process that must send the same messages to many remote processes simultaneously (e.g. a broadcast server) to distribute the load on the network lines, thus utilizing limited bandwidth more effectively.

The dispatcher, consisting of a Dispatcher running as a standalone process, allows clients to find dispatchable servers. The latter must have registered with the dispatcher. The client does not have to know where the desired server is, only where the dispatcher is. As long as the server has registered with the dispatcher, it can be found. The client sends a message to the dispatcher requesting a specific type of server. The dispatcher determines whether or not any servers meeting the client's requirements are registered, and if any are, it asks each in turn if it will accept the client's registration until it finds one that does. The dispatcher then notifies the client as to the success or failure of the latter's attempt.

To take advantage of these capabilities, clients must each instantiate a ClientTransceiver, and servers must each create their own ServerTransceiver. These transceivers allow them to communicate with dispatchers and with one another. A servers uses its ServerTransceiver to register with dispatchers, which then tell the servers when clients are requesting their services. A client does the latter by using its ClientTransceiver's getServerFromDispatcher() method. Once a server accepts a client, communication between the two is accomplished via their respective transceivers' send() methods. Both the initial dispatch request and the subsequent communication may occur via zero or more repeaters.

Clients must implement the ClientTransceiverUser interface, and servers the ServerTransceiverUser interface. Doing so allows them to process received messages.

Also provided is support for cooperative synchronization of access to system files on a particular machine. The FileAccessController, running as a standalone process, manages this access. Any process that wishes to access files on the machine upon which the file access controller is running uses a FileAccessTransceiver to do so. The file access controller is found via a dispatcher, and thereafter the client process may lock and unlock files using the file access transceiver. The object using the transceiver must implement the FileAccessTransceiverUser interface.