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.