Connection Protocol Modules

Home/Documents/Development/High-Level Design/Connection Protocol Modules
 Project Closed
 Site Index
 User Docs
 Introduction to ANet
 High-Level Design
 Run-Time Wrapper
 Client Connection Modules
 Data Transformation Modules
 Client SDK
 Cluster Group Modules
 Cluster Filter Modules
 Core Modules
 Handshaking Protocol Modules
 Packet Protocol Modules
 Connection Protocol Modules
 Bandwidth Manager Module
 Document Type Definition (DTD)
 Low-Level Design
 Protocol Specifications
 Task List
 Development Roadmap
 Other Docs
 Mailing Lists
 Contacting Us


by Benad

The Connection Protocol Modules are used to provide an abstraction of the network protocol used to exchange information with and identify another node on the network.

Table of Contents


Role of the Connection Protocol Modules

Connection Protocol Modules allow an uniform way to do input and output to another node in the network. At this point in the ANet deamon, the Connection Protocol Module should not change the data in any way, as it's supposed to only send and receive data from the network.

Also, each Connection Protocol Module need to define a way to identify another node on the network through the protocol it implements. This has to be known only by the user that needs to change the configuration file[1] or to monitor the list of connections and their state[2].

Input/Output for the Connection Protocol Modules

As an instance of a Connection Protocol Module is created, it should open the connection, given the information in the current settings. The Handshaking Protocol Module[3] for the connection will do polling with the module to know when the state of the connection becomes ready or timed-out. Timing-out a connection can be done either by the Connection Protocol itself or by the Run-Time Wrapper.

An instance of a Connection Protocol Module should close its connection when its instance is being destroyed.

The Input and Output is basically the data you need to send from/to the network. It is very important to note that all the input and output, including opening and closing connections, should be done asyncronously. Otherwise, the entire deamon will become unresponsitive(1).

Connection States

As previously stated[4], a connection has many states. But those states can be changed only by the Handshaking Protocol for the connection. For example, the connection will be opened and used by the Handshaking Protocol, to allow it to figure out if the security requirements can be followed, before the state of the connection becomes opened.

Thus, each Connection Protocol Module must implement a function that returns the actual state of the connection. This function will be used exclusively by the Handshaking Protocol. The Conenction Protocol Module does not need to change or rely on the connection state value for its connections.

Implementation Notes


See the complete DTD for more information.

<!-- Connection. Has a Connection Protocol and, if needed,
a Packet Protocol. -->
<!ELEMENT Connection (PacketProtocol)?, ConnectionProtocol>
<!ATTLIST Connection %security;
          status (open | on_hold | closed) #FIXED>


(1) Actually, the deamon will become a I/O-bound process, instead of being a CPU-bound (or a memory-bus-bound) process, which is bad, since CPU is much faster than any I/O.


About the references...

[1] Benad: "Run-Time Wrapper". Local link.
[2] Benad: "Client Connection Modules". Local link.
[3] Benad: "Handshaking Protocol Modules". Local link.
[4] Benad: "Core Modules". Local link.

Last update for this document: August 24, 2001, at 1:16:59 PST