Table of Contents
Introduction
To support modularity and still allow for fault tolerance in the framework, we have split the design of the communication layer into two sublayers. The first of them is the set of required functionalities that are required for fault-tolerant behavior of the framework for communication purposes. We call this sublayer meta-protocol (which is an abstract sublayer, described as an interface called ServerSideProtocolInterface in the framework). The second sublayer, the protocol is any construct that supplies these minimum required functionalities.
The minimum required functionalities for the meta-protocol (on the client side) are:
- Provide the means to retrieve a job from a connected client;
- Provide the means to return a reply to a client;
- Provide the ability to start the server; and
- Provide the ability to stop the server.
Any class that implements these functionalities is a proper server side communication protocol. Note that there is an analogous set of requirements on the server side as well. This was be covered in the server handler tutorial.
What is a client handler?
The client handler sits on server side and handles the communication between server and clients. It acts more like a switchboard operator, since the only work a client handler needs to do is to call protocol object to retrieve jobs, hand them to corresponding job handler, wait the server reply after jobs are handled, and call a protocol object to send the server replies back to clients.
How to use the client handler?
The client handler needs to be initialized with a server side protocol object. During its initialization, it will also create a job handler so that job listeners (both responding and non-responding) can be registered with, or removed from. After its initialization, we call start() on the client handler object to start its work as described in the introduction paragraph.