Client Connection Modules
Home/Documents/Development/High-Level Design/Client Connection Modules
by Benad
The Client Connection Modules act as a communication bridge between the various programs that use the ANet networks (the clients) and the program that manages the network (the ANet deamon).
Table of Contents
From the point of view of its architecture, ANet is actually several programs. Only one program manages the network: the ANet deamon(1). It is consisting of the run-time wrapper[1] and of different modules. The deamon itself does not "use" the network. The programs that want to use an ANet network will have to communicate with the deamon in order to do so. Those programs are the ANet Clients.
The major advantage of doing so is that each time a developer wants to implement a new application for an anonymous network, that person does not need to re-implement the entire protocol again. This is similar to TCP, since it is being implemented in the operating system, the programmers won't have to re-implement TCP for each program that will be using it.
Since ANet is a protocol, it doesn't know what kind of data it is distributing. So, the same network could be used for completely different things, yet it is not aware of it.
But then, the clients ultimately care about what kind of data they are going to send and receive. As a result, each packet of information will be identified by a Service Number. A Service is a specific use of the network, and as a result, a group of information that can be consistently created, analyzed and modified. This is similar to a "port" in IP[2].
The Clients Connection Modules are modules that fully represent, by themselves, entire clients. Downwards[1], they receive commands(2) from the clients and they transfer them downwards in the deamon. Upwards[1], they receive relevent data from the rest of the deamon and they tranfer that data to the proper clients.
Here is a summary of the interaction between a client, its client connection module and the deamon within a session, from a high-level point of view.
- The user starts the ANet deamon. Thus, the clent connection module is started.
- The user starts the ANet client.
- The client connects itself to the client connection module.
- The client registers the services it will use. The client can receive and send data only for the services it registered for.
- The client connection module sends those registration requests to the rest of the deamon. Registration is actually made for the client connection module, so if more than one client connect to the module, then it has to remember which client requested what services.
- The client starts sending some commands to the client connection module, and the module in turn sends the commands to the rest of the deamon.
- For all the data received from the network that have service numbers registered by the client connetion module, the deamon makes a copy of the data and sends it to the module. Also, for all commands that returns some value, the deamon sends the resulting data to the client connection module.
- As it receives data from the rest of the deamon, the client connection module sends the data to the client (or the proper clients, if more than one client requested the same service or made the same command).
Here is a list of commands that can be sent downwards by a client connection module to the rest of the deamon.
- Register/Unregister service
- Given some service number, it registers that service for its calling module instance. You can also unregister some service you don't want to use anymore. If you pass a flag saying "all services", then the service number given will be ignored and all possible service numbers will be registered or unregistered. If you register all services, all other calls to this command will be ignored except the next "unregister all services" command.
- Send packet
- Sends an ANet packet, query[3] or static data[4], to the ANet network. The cluster group[5] where the packet will be sent has to be specified. Use the "Get Config" command (read below) to know which cluster groups you can use. The format of the "internal ANet packet" will be described in "Cluster Group Modules"[5].
- Get Status
- Will make the ANet deamon return a packet describing its current status. The contents of this packet will be implementation specific and outside the scope of the high-level design, though it will contain enough relevant information to let the user know what's going on in the deamon.
- Get Status - Start/Stop polling
- From the time the deamon gets the "Start Polling" command to the time it gets the "Stop Polling" command, the deamon will regularly send status packets the the client connection module. This is usefull for clients that want to monitor the status of the ANet deamon. With the "Start Polling" command, you can also specify what is the delay between when ANet will send the status packets, though if that value is too small, the command will be ignored.
- Get Static Data
- Given a primary and/or the secondary key, this will make ANet return all the static packets currectly stored locally that matches the key (or keys).
- Change/Delete Static Data
- Those commands will allow the module to change or delete some static packets currently stored locally.
- Open TWDTC
- Given the protocol, the "unique address" and the "subnet" of the other node, ANet will try to establish a Two-Way Data Transfer[6] Channel (TWDTC) to the other node through the network. If ANet didn't already found which node to use as a proxy (that can have access to the protocol and subnet you specified), it might take some time to establich the connection. Use the "Get status" commands to know what's going on. ANet will return a packet containing an ID that can be used to identify the TWDTC with the other TWDTC commands.
- Read/Write TWDTC
- Read or write some data in the TWDTC. This is similar to reading or writing data in a TCP socket.
- Close TWDTC
- Given an open TWDTC ID(3), closes the identified channel.
- Get Config
- Returns the readeable tags in the configuration files[1]. Each tag in the configuration files can have access rights, that is read, write or both. If specified, it affects the tag, and recursively overwriting the access rights of the tags it contain. Otherwise, they remain to their default value.
- Change Config
- Allows the client connection module to change tags in the configuration file, it it has the right to do so. The change can be saved to the hard disk, instead of being temporary, if the user has configured ANet to do so.
- There is no point of making one instance of the client connection module per connection to a client. Most instances should be made before having any connection to clients. Note that an instance cannot "instantiate itself" as the deamon receives a connection: the instance should exist to make whatever kind of connection it supports.
- A client connection module doesn't have to allow all the commands allowed the the deamon. Actually, those modules can be very sophisticated, for example gateways[7]
See the complete DTD for more information.
Notes
(1) You can have more than one ANet deamon in the same machine, but why? ANet is flexible enough to allow isolated network to coexist in the same system.
(2) This what inspired by HyperTalk, the programming language of HyperCard[8]. Here's an example:
ask "What is your name?"
if the result is "Benad" then answer "Wow! I have the same name!"
Here, "ask
" and "answer
" are commands, while "the result
" is a function and "is
" is an operator. This is not a joke!
(3) If you know what "TWDTC ID" means, then you're ready to be a developer for ANet!
References
About the references...
[1] Benad: "Run-Time Wrapper". Local link.
[2] University of Southern California
, "Internet Protocol". External link. Cached.
[3] Benad: "Queries". Local link.
[4] Benad: "Static Data". Local link.
[5] Benad: "Gateways and Clusters". Local link.
[6] Benad: "Anonymous Two-Way Data Transfers". Local link.
[7] Benad: "Gateways and Clusters". Local link.
[8] Apple: HyperCard. External link.
Last update for this document: August 24, 2001, at 1:32:31 PST