Connection Protocol Modules

Home Project Closed Site Index News Recent Old Download Documents User Docs Development 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 Development Mailing Lists Contacting Us

PROJECT CLOSED

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

• Design
  • Role of the Handshaking Protocol Modules
  • Input/Output for the Handshaking Protocol Modules
  • Connections
• Implementation Notes
• DTD

Design

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

• When the instance is destroyed, the Connection Protocol should disconnect, but still asynchronously. What this mean is that the disconnection should be done even if the deamon already "forgot" the existence of the instance.
• The most important thing about Connection Protocols is speed. A typical ANet node will have to handle a lot of data both as input and output to the network, and the CPU will be used a lot for data transformations. So, blocking the CPU could be almost catastrophic.

DTD

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>

Notes

(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.

References

About the references...

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