Src-datasite-commserver

• commserver* provides the ability to establish connections to remote sites using FreeWave serial radio modems in point-to-point mode, and with the base radio reached via IP. The commserver can be accessed on the commserver host, or remotely via ip-i/o redirection through the inetd daemon.

Assuming a remote site is configured on the commserver host, a connection can be made either locally to the commserver and a connection requested by the command at the query prompt:

   query: call mysite

The commserver reads the setup files for mysite, establishes a connection to the remote radio base station via IP, checks and configures the base radio callbook, then issues the FreeWave dial command. It then monitors the response from the base radio, first looking for "OK", which means the dial command was recognized, and "CONNECT", which indicates that the first repeater in the radio path was reached. Unfortunately, the FreeWave OS provides no further indications of access to repeaters or to the target radio site, so commserver begins issuing commands to the target system in hopes of seeing a prompt response from that system. If no prompt response is seen from the target system, the commserver process times out and the session is ended. If a prompt is seen, commserver issues the response "CONNECTED" to the originating client, and transfers the input and output channel to the client.

Once "CONNECTED" is seen by the client, commserver sits in the background passing data back & forth between the client and the remote target system. Effectively, the client is connected by long serial cable to the target system.

Once a connection is established, commserver does only two things. First, it monitors data from the client looking for the special in-band string "BAIL!", and, if seen, it immediately terminates the connection. Second, it observes the duration of no data from the client, and terminates the connection if the set timeout period is reached.

commserver offloads from the client any need to control and command the FreeWave radio system, including knowledge of radio numbers or repeater paths, or selection of base radio stations. This is especially useful in large networks, where there is insufficient space in the FreeWave base radio's callbook for all potential connections. commserver inspects the base radio callbook and will use existing path entries if available and appropriate, or else will create a new path using entries 8 and 9.

internals

commserver is built using the thinobject system, so that configuration is done in ordinary files and not in a running application. Each instance of commserver runs as a separate process, and there is no controlling process or daemon running on the server.

Currently, commserver uses a simple fallback approach of reading setup details from a file named ".query" in the site object directory. This file can be a symlink to other files, so there may be multiple setups defined but only one selected by the system operator.

Here's a view of a working commserver site:

   ken@hayes:/var/local/commserver/nslope/$  ls -a1 .slope_mtn/
   ^
   paths
   .query -> .query-via-sagriver
   .query-via-deadhorse
   .query-via-sagriver
   .query-via-sagriver-dfr2
   .query-via-sagriver-dfr2-ukrep
   .query-via-toolik
   .query-via-toolik-dfr2
   .query-via-toolik-direct
   @RADIO
   radio-power
   UPLINK/

Several query scripts are defined but just one is selected by setting the symlink named .query to it.

The use of a dot before "query" is not really necessary and is perhaps unfortunate, but these are ordinary files. Here's the content of the selected query for this site:

   ken@hayes:/var/local/commserver/nslope/$  cat .slope_mtn/.query
   host sagriver
   port 1234
   prompt *
   radio 555-1212

The entries for UPLINK/ and paths in the above site object listing hint at a feature for commserver which is not yet realized. THe UPLINK/ directory contains identifiers for other sites which can be reached from this site in the direction from target to base. Upon getting a command to call a site, commserver will analyze the uplink paths from the target site back to one or more base stations, along with path metrics representing distance, visibility, signal strength, and potentially other factors, and create a set of possible radio paths that might be used. The set of paths will be stored/cached in the paths file so that the analysis does not have to happen for each call.

Essentially, commserver will implement a dynamic routing algorithm for each call, automatically selecting the best base station and path to use to contact the site.

The dynamic routing feature is not yet in place, so instead the static query files are used.

The radio-power file is another commserver feature which is not yet in use. It is a Schedule object, and will be used to identify when the particular site radio is powered on or not. Currently the schedule object is forced on:

    $ tob nslope/slope_mtn:radio-power.isa
    Schedule
      Object
    $ tob nslope/slope_mtn:radio-power.show
            FORCE   =ON
    $ tob nslope/slope_mtn:radio-power.show-state
    1
    $ tob nslope/slope_mtn:radio-power.is-on
    TRUE
    $ tob nslope/slope_mtn:radio-power.is-off
    FALSE

This feature will factor in to path selection, since all radios in a path must of course be powered on. Normally, the schedule would be set to whatever operating schedule is running on the remote datasite, and a "force" used only if the radio at the site is actually forced on.