- Freeway, Off-the-Shelf Protocol, and Message Switch
configured for data only
A Freeway can be configured to use the Message Switch
software to automatically configure protocol lines
statically, with pre-canned specifications, and then
to transfer data between TCP/IP or UDP/IP datastreams
and the WAN protocol lines. For example, if you have
bisynchronous protocol WAN lines running at 9600
bits/second, and all you need to do is to send and
receive data to/from those WAN lines, then the
Freeway/Message Switch could be configured to receive
the data from those WAN lines and send it to your IP
network as TCP or UDP packets, destined to a specific IP
port and address (or if UDP, to the broadcast address).
It could also receive TCP or UDP packets from or to
various IP ports, and send those packets to specified
This is the simplest method to implement in the client.
Depending on the destination or source of data required
by the client, this method requires either no programming
whatsoever, or minimal socket-level programming (to create
a program to send and receive the IP data streams). For
comparison with the other methods, a
socket-level program to send and receive IP data
(and therefore WAN data) might take only 50 to 100 lines
of C code.
- Freeway, Off-the-Shelf Protocol, and Message Switch
configured for control information and data
The Message Switch can also be configured to pass control
information as a 32-byte header at the beginning of each
data packet on the IP network. This allows simple
socket-level client application programs to be written
which can send commands to, and retrieve status information
from, the WAN protocol lines.
An example of this would be a client which wants to start
or stop a WAN link; the previously-described "data only"
client could not start or stop a WAN link (because that
type of client can only send or receive WAN data), but a
"control information and data" client can start or stop
a WAN link, or even change the WAN parameters.
Implementing this method is slightly more complex than the
previous (data-only) method. For example, a
socket-level program to send and receive IP data and
WAN control information
might take approximately 150 lines of C code.
- Freeway, Off-the-Shelf Protocol (no Message Switch);
A Freeway can be configured without the Message Switch
to simply download the protocol code into the ICP board(s),
but not to configure any of the protocol parameters
(datarate, electrical interface, etc.); that job is left for
the client application program to perform.
This method requires that a program be written on the client
machine to connect to the Freeway and send commands to
configure the WAN protocol lines (to set the datarate, etc.).
For many of Protogate's off-the-shelf protocols, Protogate
provides source code for a DLI/TSI library, which can be
linked with your client program to aid in making the
connection to the Freeway and in configuring the protocol(s).
That DLI/TSI code contains instructions which are
specifically-designed to aid in writing client programs for
The protocols which are supported by the DLI/TSI library are
called "Normal-Mode" protocols, and those which are
unsupported are called "Raw-Mode" protocols.
This method assumes that a Normal-Mode protocol is used and
the client program is written to take advantage of the full
Implementation of this method is moderately complex, because
of the client application program that must be written.
This client program must not only connect to the Freeway via
the LAN, but must also send commands to configure the Freeway
and the protocol, and handle all of the various packet types
which the Freeway might send to it.
Because in the Normal-Mode much of this code is in the
DLI/TSI library, a
typical Normal-Mode client application program
might take approximately 2000 lines of C code.
Configuration of the WAN links is performed by code inside
the DLI/TSI library based on an easy-to-edit ASCII
DLI configuration file, which
can be changed without any need to also change the client
- Freeway, Off-the-Shelf Protocol (no Message Switch);
This is similar to the previous method, but the client
application program accesses the Freeway and protocol in
Raw-Mode, either by choice or because the DLI/TSI does not
support Normal-Mode for the protocol in use.
Implementation of this method is even more complex than
the previous (Normal-Mode) method, because of the additional
work that the client application program must perform.
This client program must not only connect to the Freeway
via the LAN, but must also send commands to configure
the Freeway and the protocol, and handle all of the various
packet types which the Freeway might send to it. Because in
Raw-Mode the DLI/TSI provides less help in performing these
tasks (and therefore the client program must itself include
code to accomplish these tasks), a
typical Raw-Mode client application program
might take approximately 3000 lines of C code.
- Embedded ICP board, Off-the-Shelf Protocol;
Inside all Freeway systems which handle WAN links are
one or more ICP boards. Each ICP board contains several
serial WAN ports -- but it also contains a CPU and RAM;
and the Freeway downloads a file into each ICP board which
contains instructions for that ICP's CPU to execute to
implement the lowest levels of the protocol (the bit level
and the character level).
A separate CPU in the Freeway implements the higher levels of
the WAN protocol (at the block-of-characters level) and
drives the LAN (IP network).
It is possible to purchase individual ICP boards and
protocols, and install them into your own computer running
NT, Solaris, or VMS. You must then install an ICP-board
driver into your operating system, and write an application
program which uses driver-level calls to download the
protocol to the ICP board and then to read and write control
information and data from and to the WAN links on the ICP
board. For some operating systems Protogate offers a
"DLITE" library which provides a bit of help, but the
DLITE library does not contain nearly as much functionality
as the true DLI/TSI library (but the DLI/TSI library only
supports interfacing to a Freeway).
Implementation of the embedded board method is even more
complex than the "Freeway, Raw-Mode protocol" method,
because of the driver-level interface, because the client
application must download the protocol code to the ICP board,
and because of the lack of Normal-Mode DLI features in the
- Freeway or Embedded ICP board, Custom Protocol
For the greatest level of control (at the greatest cost in
difficulty of implementation), any of the
previously-described Freeway or embedded WAN-access methods
can also be configured to use a custom protocol, which might
be custom-written either by Protogate
(to your specifications) or by yourself.
This requires not only that a client program be written
(as in the "Freeway, Off-the-Shelf Protocol" method above)
but also that the custom protocol code be developed
(written, cross-compiled, tested, and debugged) to run on
the ICP board.
Developing a custom protocol requires a great deal of work
(it generally takes several engineer-weeks to develop even
the simplest protocol code), but allows the most possible
Writing the protocol code yourself means that you have
control even down to the bit level on your WAN protocol
If you need this level of customization and want to write
your own protocol, Protogate offers the sourcecode for a
representative protocol as part of a "protocol toolkit",
to help get you started.
The previous list includes most of the WAN access methods, but
if none of those methods satisfy your needs completely, there are
two more possibilities: use of a Server Resident Application (SRA)
and use of Message Switch "Programmable Endpoints".
An SRA can be used with any of the Freeway methods described above.
Programmable Endpoints can be used with either of the Message
Switch methods described above.
The Freeway system is programmable and includes a full set of
native development tools. You can use those tools to develop
an application program which runs on the Freeway itself.
If that application program is written to use sockets or the
DLI/TSI library to connect to a Freeway daemon (running either
in the same Freeway, or another Freeway connected via an IP
network), then we call it an SRA (Server Resident Application).
An SRA can utilize all the features of the Freeway, just as any
client application can, but because it runs in the Freeway it can
perform extra work before the data leaves the Freeway; it can thus
make the Freeway into a self-contained data processing system,
rather than simply a data-transferring system.
For example, an SRA could be written to capture data from several
WAN lines and output a report (to the console, to a socket, or
any to other output device) when those datastreams differ.
SRAs can be as simple or as complex to write as any other
Freeway client application. They can be written to use the
socket-level Message Switch interface or the DLI/TSI interface,
in either Normal-Mode or Raw-Mode. In fact, all of the client
application programs described in the first 4 methods above can
run directly on a Freeway as an SRA: the
socket-level program to send and receive IP data, the
socket-level program to send and receive IP data and WAN
control information, the
Normal-Mode client program, and the
Raw-Mode client program
will all run on a Freeway.
Message Switch Programmable Endpoints
The Message Switch software which runs on the Freeway can be
configured to transfer data from a set of inputs to one or more
sets of outputs.
From the Message Switch's point of view, these inputs and outputs
are simply "endpoints"; the Message Switch takes data from each
endpoint and sends it to one or more other endpoints.
These endpoints can be WAN links, UDP or TCP sockets, or other
devices (hard disks files, etc.). Another type of endpoint
supported by the Message Switch is called "Programmable Endpoints".
Programmable Endpoints are separate programs, running on the
Freeway, which have their Standard Input and Standard Output
connected to the Message Switch.
When the Message Switch is configured to use a Programmable
Endpoint, it forks a separate process running the Programmable
Endpoint program, with data pipes set up to connect that process
to the Message Switch.
Whenever the Message Switch sends data to that endpoint, the
Programmable Endpoint process will receive it on stdin, and
the Programmable Endpoint process sends data to stdout, the
Message Switch will be able to read it from that endpoint.
Because the Programmable-Endpoint program is a simple
stdin-stdout program, it can be easy to create, but because it
has access to all of the features of the Freeway it can have
great power. For example, a program to
compress WAN-link data can be written
in about 250 lines of C code, and another program to
send WAN-link data to an FTP server
can be written in even fewer lines.
The last program described above is a good example of the power
and flexibility of the Freeway when running the Message Switch
with Programmable Endpoints. When configured this way, the
Freeway will take all of the data on all desired WAN links and
write it into a set of files on an FTP server; and it will begin
doing so automatically, as soon as it is powered up, with no
intervention necessary by any person or other machine.
We recommend that you use the simplest method which still
provides all the capabilities you need. In general, use of
a Freeway is much simpler than use of embedded ICP boards, and
requires less effort on the client's part. See our list
advantages of using Freeway versus
When choosing a WAN-access method, it is also important to
remember that most of the methods described above can be used
in combination with each other. Use of one method does not
preclude the simultaneous use of other methods. For example,
a single Freeway with several WAN lines could be running the
Message Switch and also several different SRAs, and could be
accessed simultaneously by different client programs, some
socket-level (data-only and data-and-control) and some
DLI/TSI (Normal-Mode and Raw-Mode).
Back to the top-level Protogate webpage