Introduction to ANet
Client Connection Modules
Data Transformation Modules
Cluster Group Modules
Cluster Filter Modules
Handshaking Protocol Modules
Packet Protocol Modules
Connection Protocol Modules
Bandwidth Manager Module
Document Type Definition (DTD)
The Cluster Group Modules are used to duplicate, when needed, data between different clusters.
Each module instance represents by itself a cluster group. When clients want to send data to the network, they have to send the data to one specific cluster group. Thus, one of the things that a Cluster Group Module has to do is that, given the packets coming from the clients, it has to send the incoming packets to the proper clusters.
Also, it is up to the Cluster Group Module to re-distribute the incoming packets from one cluster to another. This allows different clusters to exchange information.
As input, the Cluster Groups need two things each time their "main" function is called. First, they need a list of cluster IDs. Those are unique numbers that identify all the clusters you have to receive or send data to. You can get additional information about the clusters from the parsed configuration file. The IDs are not part of the configuration file, but are generated as the file is parsed, and they are attributes as if they were written in the configuration file itself(1). Also, they need an "input buffer", which is a list of ANet Internal Packets (AIP). Each packet is identified with the cluster ID it came from.
As output, they produce a list of AIPs, each one identified with the cluster ID it has to go to.
Now it's a good time to introduce the most important data structure in the ANet deamon: the ANet Internal Packets, AIP in short.
An ANet Packet is very similar to packets in IP: they represent an independent block of information that cannot be broken down to be useful. You can split a large block of data into several ANet packets, as long as they contain enough information to be able to merge them back later in your client.
The ANet Internal Packet is a representation of an actual External Packet (AEP), but for use within the deamon. The goal of this structure is to make it easy to transform and process. Thus, it follows byte-ordering and memory alignment of the compiled deamon. Also, the structure is much more flexible than the External one(2).
The AIPs are broken into two: the header and the data. The size of both the header and data are not fixed, but may have a limitation in size. By allowing the header to be of any size, we allow future versions of the ANet deamon to store additional information (at the end of the header) that can be safely ignored by previous versions of the modules.
So here is a list of what the header will, at minimum, contain:
Functions in the run-time wrapper will be given to all the modules to simplify access to the data contained in the AIPs.
See the complete DTD for more information.
<!-- Cluster Group. Contains references to Clusters that compose that Cluster Group. --> <!ELEMENT ClusterGroup (ClusterRef)+> <!ATTLIST ClusterGroup %name; %moduleName; %args; %security;>
(1) So, the IDs must not be saved back to disk. They are re-generated each time the deamon is launched, except when it is "resumed".
(2) What I mean is that, most of the time, doing a simple typecasting is enough to retrieve the data you want.
About the references... Benad: "Run-Time Wrapper". Local link.
Last update for this document: August 24, 2001, at 1:23:37 PST