CA 02212388 2000-11-17
1 NETWORK COMMUNICATION SERVICES METHOD AND APPARATUS
l.1 Field Of The Invention
The present invention relates to an architecture for network communication
services with
special applicability to networks capable of providing message routing and
delivery over
multiple communication protocols on distributed networks.
1.2 Background Of The Invention
Information processing networks have dramatically increased in size, and
complexity
1 o especially with the increased volume ofuse and the increased complexity of
communications
and data processing that are done on the networks. One of the more complex
areas which are
rapidly expanding are the telecommunications networks which now are opening up
into the
videoconferencing arena. In this and other information processing networks
there are several
communication protocols and media in use. Whc~n networks having particular
protocols or
organizations are interconnected with other networks having different
protocols or
organizations there may be difficulties or complexity in passing messages
between them or
conducting distributed application processing.
In the data processing field and in the video conferencing field distributed
applications that
2o are used may make use of one or more communication media and protocols to
allow
distributed nodes to communicate. The nodes of a distributed network may route
messages
for other nodes. For instance, consider the case of three nodes; A, B, and C
where node A
can talk directly to node B, and node B can talk directly to node C; but node
A cannot talk
directly to node C. Messages from A to C could be delivered to B and routed
from B to C.
As the number of nodes and complexity of networks increases other
complications occur.
For instance in a netwark of nodes consisting of hundreds or thousands of
nodes the failure
of a node or the network may impose significant difficulties in restarting the
network and the
nodes. It is understood that depending on the network restarting the network
may require that
C.A9-97-034 1
CA 02212388 2000-11-17
nodes of the network may need to be started in a particular order. In other
networks the
failure of a node may not be readily detectable by the network such that
certainty of
communication may be affected.
If an information processing network is constructed using the Internet as a
base it will be
appreciated that the size of the network may become vnmense. It would be
unfortunate if
the unavailability of any portion of the Internet would cause the information
processing
network to be brought down, and particularly if it could not be rapidly
restarted.
1 o It would be preferable that the network could include a method or
apparatus for verifying its
integrity and restarting nodes that have stopped ,without requiring a network
shutdown and
full restart.
1.3 Summary Of The Invention
In one implementation of the current invention a networking services
architecture is provided
in which several cormnunication media and protocols are supported. In commonly
used
communications middleware, the routing specification and messaging interface
provided to
a client application may depend on the communications protocol used. In the
present
invention the client's interface is independent of the communication protocols
supported for
2o internode message delivery, and the routing specification is also
independent of the number
and type of communication protocols supported. For instance, in a
communications system
constructed in accordance with a preferred mode of the invention, for the
example mentioned
above, node A and node B could be connected using IP {lnternet Protocol),
while node B and
node C could be connected using synchronous polling. T'he routing
specification is
independent of these details, since nodes are identified in a protocol
independent manner.
One aspect of the invention provides a network communication services system
for providing
communication services between nodes of a netvrork.
C.A9-97-034 2
CA 02212388 2000-11-17
Local communications access means (such as the module comprising lcmne tasks
plus lanai
library in the preferred embodiment below) for each node adapted to forward a
message from
a task on a node internally to another l:ask on tlhe node; configuration
information means
containing information on nodes with which communication is possible;
One or more internode message delivery task means on a first node adapted to
forward a
message addressed to a second node from the loe~l communications access means
on the first
node to the second node to intetnode message delivery task means on the second
node and
to accept messages from an internode message delivery task means of a remote
node for
1 o routing as appropriate to:
(i) local communications access means if intended for internal use within a
node
(ii) internode message delivery task means of the remote node.
A further aspect of the invention provides:
~ monitoring means for monitoring communications link between nodes including:
the
internode message delivery task means including status monitoring task means
for
communications connection to other nodes;
~ the status monitoring task means including, polling task means for polling
the other
nodes to determine their status; and reporting; means for reporting a detected
change in
2o status of the other nodes;
~ the status monitoring task means being adapted to:
store status information in a database;
for registration of tasks;
~ notify tasks registered with it of changes in communication link status of
selected nodes.
Still another aspect of the invention provides a system wherein the monitoring
means (monT)
includes:
~ means for answering queries from other task, for node status of a remote
node;
~ means for notifying tasks asynchronously of node status;
CA9-97-034 3
CA 02212388 2000-11-17
~ means for registering with monitoring means on a node that is directly
connected to
another node that provides communications routing for the other node, in order
to
determine communication link status o.f a none that it has a route to and also
to any node
to which it is directly connected.
Another aspect of the invention provides a system as above including a task
manager
(TMGT) at a node adapted to monitor applications within the node and
including:
~ means to start a task on the node;
~ means to monitor the task;
~ means to restart the task if required;
~ means to terminate the task;
~ means to report changes of status of the node to the monitoring means.
A further aspect of the invention provides network communication services
system for
providing communication services between nodf;s of a network comprising:
a plurality of nodes.
Each the nodes comprising:
~ local communications access means for each node adapted to forward a message
from
2o a task on a node internally to another task on the node;
~ configuration information means containing information on nodes with which
communication is possible;
One or more internode message delivery task means on a first node adapted to
forward a
message addressed to second node from the local communications access means on
the first
node to the second node to internode message delivery task means on the second
node and
to accept messages from an inte;rnode message delivery task means of a remote
node for
routing as appropriate to:
(i) local communications access means if intended for internal use within a
node
C A9-97-034 4
CA 02212388 2000-11-17
(ii) internode message delivery task means of the remote node.
Advantageously monitoring means may be provided in another aspect of the
invention for
monitoring communications link between nodes including:
~ the internode message delivery task means including status monitoring task
means for
communications connection to other nodes;
~ the status monitoring task means includin~; polling task means for polling
the other
nodes to determine their status; and reporting means for reporting a detected
change in
status of the other nodes;
o
The status monitoring task means being adapted to:
~ store status information in <~ database;
~ for registration of tasks;
~ notify tasks registered with it of changes in communication link status of
selected nodes.
t5
The monitoring means (monT) may include:
~ means for answering queries from other tasl~;s for node status of a remote
node;
~ means for notifying tasks asynchronously of node status;
~ means for registering with monitoring means on a node that is directly
connected to
2o another node that provides communications routing for the other node, in
order to
determine communication link status of a node that it has a route to and also
to any node
to which it is directly connected.
Another aspect can provide a task manager (TMGT) at a node adapted to monitor
25 applications within the node and including:
~ means to start a task on the node;
~ means to monitor the task;
~ means to restart the task if required;
~ means to terminate the task;
CA9-97-034 5
CA 02212388 2000-11-17
~ means to report changes of status of the node to the monitoring means.
Advantageously, the network communication services system invention can
provide
communication services between nodes of a network for providing both message
delivery
and Remote Procedure Call services between nodes of a network comprising:
~ a plurality of nodes;
~ the nodes comprising:
3E local communications access means for each node adapted to forward a
message
t 0 from a task on a node internally to another task on the node;
~f configuration information means containing information on nodes with which
communication is possible.
One or more internode message delivery task means on a first node adapted to
forward a
message addressed to second node from the local communications access means on
the first
node to the second node to internode message delivery task means on the second
node and
to accept messages from an internode message .delivery task means of a remote
node for
routing as appropriate to:
(i) local communications access means if intended for internal use within a
node;
(ii) internode message delivery task means of the remote node; wherein the
internode
message delivery task means on at least the first node is adapted to
communicate in a
plurality of data communication protocols including at least one of IP
(Internet
Protocol), LAB, or BIOSC'.IENC'E 3270.
Still another embodiment of the invention provides a method for use in a
network
communication services system for providing communication services between
nodes of the
network comprising:
~ for the nodes;
CA9-97-034 6
CA 02212388 2000-11-17
~ forwarding a message from a task on a node internally to another task on the
node using
local communications access means on each node;
~ storing information on nodes with which communication is possible within
configuration information means within the nodes;
Forwarding a message using one or more internode message delivery task means
on a first
node to forward a message addressed to a second node from the local
communications access
means on the first node to the second node to intf;rnode message delivery task
means on the
second node and using internode message delivery task means to accept messages
from an
t o internode message delivery task means of a remote node for routing as
appropriate to:
(i) local communications access means if intended for internal use within a
node
(ii) internode message delivery task means of the remote node.
Advantageously, the method can further include: monitoring communications link
between
nodes using monitoring means wherein the monitoring includes:
~ monitoring status of nodes with which communications connections are
required using
status monitoring task means for communications connection to other nodes;
~ polling the other nodes using pollW g task means for polling the other nodes
to determine
their status; and reporting a detected change in status of the other nodes
using reporting
means;
The status monitoring task means being adapted to:
~ store status information in a database;
~ register of tasks;
~ notify tasks registered with it of changes in communication link status of
selected nodes.
The monitoring may also include:
~ answering queries from other tasks for node status of a remote node;
~ notifying tasks asynchronously of node status;
C,A9-97-034 7
CA 02212388 2000-11-17
~ registering with monitoring means on a node that is directly connected to
another node
that providing communications routing fo~~ the other node, in order to
determine
communication link status of a node th<~t it has a route to and also to any
node to which
it is directly connected.
Another aspect of the method of the invention can include monitoring
applications within
the node and including the capability o~
~ starting a task on the node;
~ monitoring the task;
l0 ~ restarting the task if required;
~ terminating the task if required;
~ reporting changes of status of the node in monitoring.
Still another aspect of the invention provides a computer program product
comprising:
~ a computer usable medium having computer readable program code means
embodied
therein for implementing a network communication services system for providing
communication services between nodes of a network comprising a plurality of
nodes;
~ the computer readable program code means in the computer program product
comprising:
2o ~E computer readable program code means for causing a computer to effect,
local
communications access means for each mode adapted to forward a message from a
task on a node internally to another task on the node;
~f computer readable program code means for causing a computer to effect,
configuration information means containing information on nodes with which
communication is possible;
j-f computer readable program code means for causing a computer to effect, one
or
more internode message delivery task means on a first node adapted to forward
a
message addressed to a second node from the local communications access means
on
the first node to the second node to internode message delivery task means on
the
CA9-97-034 8
CA 02212388 2000-11-17
second node and to accept messages from an internode message delivery task
means
of a remote node for routing as appropriate to:
(i) local communications access means if vltended for internal use within a
node
(ii) internode message delivery task means of the remote node.
The computer program product may further include: computer readable program
code means
for causing a computer to effect, monitoring means for monitoring
communications link
between nodes including:
~ the internode message delivery task means including status monitoring task
means for
1 o communications connection to other nodes;
~ the status monitoring task means including polling task means for polling
the other
nodes to determine their status; and reporting means for reporting a detected
change in
status of the other nodes;
~ the status monitoring task means being adapted to:
~E store status information in a database;
for registration of tasks
~E notify tasks registered with it of changf~s in communication link status of
selected
nodes.
2o In addition the computer program product can include program code means for
causing a
computer to effect monitoring means (rnon'T) includes:
~ means for answering queries from other taska for node status of a remote
node;
~ means for notifying tasks asynchronously of node status;
~ means for registering with monitoring means on a node that is directly
connected to
another node that provides communications routilig for the other node, in
order to
determine communication link status of a node that it has a route to and also
to any node
to which it is directly connected.
The computer program product embodiment of the invention can include program
code
C A9-97-034 9
CA 02212388 2000-11-17
means for causing a computer to effect, task manager means ('TMGT) at a node
adapted to
monitor applications within the node and including computer readable program
code means
for causing a computer to effect:
~ means to start a task on the node;
~ means to monitor the task;
~ means to restart the task if required;
~ means to terminate the task;
~ means to report changes of status of the node to the monitoring means.
A further aspect of the invention provides a program storage device readable
by a machine,
tangibly embodying a program of instructions exc°cutable by the machine
to perform method
steps for use in a network communication services system for providing
communication
services between nodes of the network comprising:
~ for the nodes;
~ 5 ~ the method steps of
~-E forwarding a message from a task on a node internally to another task on
the node
using local communications access means on each node;
3f storing information on nodes with which communication is possible within
configuration information means within the nodes;
~-E forwarding a message using one or more internode message delivery task
means
on a first node to forward a message af~,dressed to a second node from the
local
communications access means on the first node to the second node to internode
message delivery task means on the second node and using internode message
delivery task means to accept messages from an internode message delivery task
means of a remote node for routing as appropriate to:
(i) local communications access means if intended for internal use within a
node
(ii) internode message delivery task means of the remote node.
The program storage device may further comprise a program of instructions to
perform the
CA9-97-034 10
CA 02212388 2000-11-17
method steps of: monitoring communications link between nodes using monitoring
means
wherein the monitoring includes:
~ monitoring status of nodes with which communications connections are
required using
status monitoring task means for communications connection to other nodes;
~ polling the other nodes using polling task means for polling the other nodes
to determine
their status; and reporting a detected change in status of the other nodes
using reporting
means;
~ the status monitoring task means being adapted to:
3f store status information in a database;
o ~E register of tasks;
1-E notify tasks registered with it of changes in communication link status of
selected
nodes.
The program storage device may further comprise a program of instructions to
perform the
t 5 method steps of monitoring including:
3f answering queries from other tasks for node status of a remote node;
~E notifying tasks asynchronously of node status;
~f registering with monitoring means on a nodes that is directly connected to
another node
that providing communications routing for the other node, in order to
determine
2o communication link status of a node that it h~~s a route to and also to any
node to which
it is directly connected.
The program storage device may also further comprise a program of instructions
to perform
the method steps of monitoring applications withKn the node and including the
capability of
25 ~ starting a task on the node;
~ monitoring the task;
~ restarting the task if required;
~ terminating the task if required;
~ reporting changes of status of the node in monitoring.
CA9-97-034 11
CA 02212388 2000-11-17
1.4 Brief Description Of The Drawings
The present invention will be more fully understood by reference to the
following detailed
description, which should be reviewed with the accompanying drawings in which:
Figure 1 depicts a System Component Diagram;
Figure 2 depicts a System Process Diagram (shaded areas represent separate
nodes);
Figure 3 depicts a Network with three nodes;
Figure 4 depicts a Control Channel System Block Diagram;
Figure 5 depicts an Application Access Process;
l0 Figure 6 depicts an Application Access Module Block Diagram;
Figure 7 depicts a Server Task;
Figure 8 depicts Message Delivery (a typical event sequence to send a message
between
two tasks running on different nodes);
Figure 9 depicts RPC Client and Server Transaction (a typical sequence of
messages sent
between a client and server tasks running on different nodes);
Figure 10 depicts Communication Lirtk Status Change Notification (a typical
sequence of
messages that occur when application tasks register with the monT task to be
notified of communication link alarm~~ for directly connected nodes and remote
nodes. Note that all messages actually pass through lcmnc en route to their
destination);
Figure 11 depicts a sequence of messages sent between communication tasks
during node
startup;
Figure 12 depicts Application Access (a typical sequence of events that occur
when an
application is accessed using Application Access component);
Figure 13 depicts two nodes establishing communications over IP;
Figure 14 depicts a testing communications between two nodes (a typical
sequence of
messages that could be sent when ncmat is run to test communications to a
remote
node).
CA9-97-034 12
CA 02212388 2000-11-17
2 DETAILED DESCRIPTION OF'fHE INVENTION
2.1 Introduction
The specific embodiment of the communications system described herein has two
main
attributes: to provide communications services between network connected
entities, and to
provide a framework to facilitate rapid and convenient development ofprograms,
called tasks
that can take advantage of its capabilities. The network connected entities
are called nodes,
and together these nodes create a virtual network built on top of one or more
underlying
networks, where the underlying networks can use a multitude of
networkprotocols, including
0 Internet Protocol (IP), Bioscience 3270, and LAB among others. The nodes can
run on a
heterogenous set of hardware platforms, including SCO UNIX on PC computers,
SLTN
computers running SLJN OS, and proprietary hardware/operating system
platforms.
Referring to the gray areas in Figure 2, each nodel includes a collection of
tasks, some
application tasks 2, and some support tasks. The support tasks shown in Figure
6 and
discussed below, together with the Taslctalk library provide services to
application tasks. The
provisioning of these services are broken into two layers: Operations 4 and
Communication
3. The Communication layer provides basic communications services and is not
visible to
clients of the system of the invention. The Operations layer provides value
added access to
2o Communication services and also provides a framework to simplify
application task
development. The mapping (i.e. relationship) of'system components shown in
Figure 1 to
system tasks, libraries, daemon processes and configuration files shown in
Figure 2 is given
in the following table:
Table 2-1 System Component to Process Entities Mapping
C system Component Process Cntities
~~perations Framework 44 _'Ta_sktalk Library 8
~
operations Sup ort ServicesTasktalk Library, timT task 7
43
~~ommunication Services Tasktalk Library, dupT task 9,
46 monT task, tmgT
task
CA9-97-034 13
CA 02212388 2000-11-17
System API Tasktalk Library
Local Communication AccessIcmai Library 10, Icmnc Task
48
Application Access 6 inaas.d daemon process 6, lcmar
access agent 11,
lcmaa Libra 1 f, inaas.conf confi
uration file 13
Configuration Services lcmdb task 14; poll.conf 15, lcmdb.conf
49 16 and
~oll.conf 15 conk uration files
IP Messa a Delive 54 lcmlc task 17
Bioscience 3270 Messa a lcm c task 21
Delive 53
LAB Messa 7e Delive 52 lcmlb.task 20
Talk Su ort Services 51 Icmai Libr<i 10
rsdsl 19 rsdsl Libra 19
l0 ull 1 18 ull l Libra 18
CA9-97-034 14
CA 02212388 2000-11-17
The Communication layer 3 provides intra and inter node message routing and
delivery over
multiple communication protocols. The Communication architecture isolates
message
routing (including indirect routing from one nodn~ through another to a third
node) and intra
node delivery into a single routc;r task (lcmnc 5), while inter node messaging
functions are
also localized to single tasks (one for each supported network protocol). All
of these tasks
require network configuration information this information is advantageously
parsed by a
single task (including asynchronous update notifi.cations), and forwarded in
small chunks to
allow the other tasks to avoid lengthy delays in their main service provision.
Application access functionality provides an API for discovering transient or
additional
configuration information from other nodes in a consistent manner. Finally the
Communication layer also provides a communication link and other status alarm
notifications
to the Operations layer for use by application tasks.
Access to Operations layer functionality from application tasks is through the
system
(TaskTalk) API. Requests (A:P( function calls) are delegated to components
within
Operations. Information flows between Operations (Communications Services) and
Operations (Local Communications Access) through the interface defined in
talk.h. Some
services provided by Operations require support t;~sks to be running (those
that interface with
2o Runtime Services 47 which start these tasks), while others do not.
Communication components interact with each other through the System API.
There are task
components that add value to operating system services, and the Communication
Local
Communications Access 48 services. There is also the Task Framework 44
component
whose function is to provide a ready made skeleton for application tasks.
2.2.a The Communications Model
The communications model is that of a flat network of nodes which may reside
on any of a
number of separate hosts connected via multiple communications protocols. The
term flat
C'A9-97-034 15
CA 02212388 2000-11-17
network is meant to imply there is no centralized network control, or
hierarchy of network
nodes. Each node has a separate "view" of the network specified in
automatically generated
and distributed configuration tiles, and can only communicate with those other
nodes
specifically identified therein. Executable tasks (that provide application or
support services)
on a given node (either local or remote) ;ire addressed using the abstraction
of
communication "ports". Each task can listen or send messages on one or more
ports, which
must be specifically initialized. Tasks sending messages to ports on other
nodes do not need
to know routing or protocol information to do so, these details are hidden
within the
OPERATIONS 4 (TALK) layer.
to
From an application task's perspective, tasks or services are addressed using
a TSK ADDR
(task address) structure, which includes the following: a network id, node id
and port id
which are all integers, and additionally a node type and port type may be
specified (both from
enumerated lists). See Fig. 3 for an example network with three nodes (two
[24, 25] running
on one host [22] and one [26] on another [23]).
Note that although the message sent from (node, port) _ (1001, 10003) to
(3,1001) is routed
through node 51 and travels over two different communication protocols (IP and
LAB), the
task that sent the message needed only to identify the destination node and
port (it did not
2o need to know any of the routing or protocol pa.rameters). In the preferred
embodiment,
message sending and receiving uses a connectionless paradigm.
For more detail on the handling of messages by the various support tasks of
the system of the
present invention, see the section EVENT SEQ(IENC;ES, and to the event
sequence RPC
client and seYVer transaction in particular, below.
Fig. 4 shows an example of a network in accordance with this invention as used
for the
control network in a Broadband Video Conferencing System. The boxes labeled
CNC 30
(Central Node Controller), SNC 29 (Service Node Controllers), SWC 28 (Switch
Controller),
CA9-97-034 16
CA 02212388 2000-11-17
BMS 31 and 35 (Broadband Multi Site Server), ESS 32 ( Event Schedules System),
SNMP
33 (Simple Network Management. Protocol), and.AVT 27 (Audio Video Terminal)
are nodes.
Note that multiple nodes of a network constructed in accordance with the
invention
(sometimes referred to as a Taskrtalk network) can be put on a single Internet
host, and each
node is assigned its own user account for all its application processes to run
in. Connections
between nodes are established by the Application Access component of the
invention. In this
capacity, Application Access rnay establish a connection between two nodes
that are up and
running, or it may start a node at the request of another node. In fact, an
entire network
using the system of the invention that is down (al l nodes down) can be
started by starting any
1o single node, and all nodes will be started as each node attempts to
establish a
communications connection with its neighbors.
2.3 Operations Components Overview
The interface to the three Operations components is provided by the Tasktalk
API 45.
A task must link in the Tasktalk library to have access to this API.
2.3.1 Task Framework
The Operations Framework is responsible for making it simpler and faster to
build
executable tasks using the system of the invention (Tasktalk) by providing
2o implementation for common task activities, including: startup, argument
processing,
generic signal and error condition handling, task shutdown, etc. This
framework also
forces most tasks to be similarly structured, tracking them more consistent
and thus easier
to understand.
2.3.2 Communications Services
Operations Communications Ser~~ices are services built on top of the services
provided
by the Communication Local Communications Access library, lanai 10. Some
services
available here map directly to services from lanai 10, while others have added
value
such as increased abstraction or information hiding.
CA9-97-034 17
CA 02212388 2000-11-17
The main addition to the Operations 4 functionality is that messages are not
explicitly
received. Instead callbacks for various messages are installed and a message
handling
loop is activated. This same message handling loop is used by all tasks,
saving effort
and enforcing consistency.
Other added functionality includes automatic platforni independent message
packing/
unpacking, message duplicating, remote procedure call functionality and
communication
and other alarm notification (Communication Alarms 40). This component also
serves
1 o the purpose of hiding the interface to lanai from other task components
and clients
thereof.
2.3.3 Support Services
Support Services 43 is a group of services that provide more convenient access
to
operating system functionality and other low level services. This includes
task
debug/log services, memory management services, timer services and system
command
execution seances.
2.4 Communication Components Overview
2.4.1 Local Communications Access
Local Communications Access 48 encompasses the client and server portions of
communications access.
The lanai library 10 provides access to Communication functionality available
to client
tasks of the invention (Tasktalk). It provides the raw messaging and remote
procedure
call (RPC) functionality through the mode, port> addressing abstraction. A
library is
built from this component that is linked into the Tasktalk library 8 that is
linked into all
client tasks of this invention (Tasktalk).
CA9-97-034 18
CA 02212388 2000-11-17
Message Routing 9, provided by the lcmnc task 5, is responsible for routing
all support
and application task messages within nodes from one task to another. This
includes
routing messages to the Internet, Bioscience 327(1 53 and LAB 52 message
delivery
tasks (lcmlc 17, Icmlb 20, and lcmpc 21 tasks respectively) for messages that
must be
forwarded to other nodes. The lcmne task ;also allocates communication ports
for all
other tasks on its node, and reports routing; information to the monT 80 task
in the
Communications Services 40 module of the Operations 4 layer.
t o 2.4.2 Configuration Services
Configuration Services are provided by the communications database task lcmdb
14,
which reads in the configuration files lcmdb.conf 16, lapb.conf 98, and
poll.conf 15 .
These files contain lists of nodes that can be reached using various protocols
(IP, LAB,
Bioscience 3270) and also indirect routing tables that specify nodes that can
be reached
t 5 by going through other nodes. lcmdb 14 then serves this information to
other
communications tasks when requested. Distribution of the configuration files
is done
by lcmdb 14.
2.4.3 IP Message Delivery
2o The IP Message Delivery task, lcmlc 17, handles forwarding messages from
one node
to another (to its instance of lcmlc 17) over an IP network using UDP (a well
known
protocol) datagrams. It also monitors the communication link status to
directly
connected nodes (the list of which is obtained from lcmdb 14), and notifies
monT 80,
in the Communication Services component, of any status changes.
2..4.4 LAB Message Delivery
The LAB Message Delivery task (lcmlb 20) handles forwarding messages from one
node to another over serial lines using the wf~ll known LAB protocol. It also
monitors
communications link status to directly connected nodes (the list of which is
obtained
C.A9-97-034 19
CA 02212388 2000-11-17
from lcmdb 14), and notifies monT, in the Communication Services component, of
any
status changes.
2.4.5 Bioscience 3270 Message Delivery
The Bioscience 3270 Message Delivery task Icmpc 21 handles forwarding messages
from one node to another using the 3270 Bioscienee multipoint master protocol.
It also
monitors the communication link status to directly connected nodes (the list
of which
is obtained from lcmdb), and notifies monT, in the Communication Services
component,
of any status changes.
to
2.4.6 Application Access
Application Access 6 provides IP based access to remote services (such as
starting
remote nodes or GUIs) that reside on other nodes. Since the other nodes may
not be
currently running or reachable, regular communications may not be used. A
daemon
process, inaas.d 6a, runs on each host, and it reads a configuration file to
see what
applications it can "serve". Requests from client tasks are made after
establishing a
socket connection to inaas.d (6a)'s well known IP port. Successful requests
result in
inaas.d starting the access agent for the given service application, and a
connection back
to the client task from the access agent is established. Information specific
to the
2o requested service can then be exchanged between the client task and the
access agent
over the connection.
2.5 Other Components
2.5.1 rsdsl
rsdsl 19 (the reliable sequenced datagram service library) is linked into a
client task
(lcmlcl7 is its only client at present) to provide reliable UDP based datagram
services.
2.5.2 ullpl
C'.A9-97-034 20
CA 02212388 2000-11-17
ullpl 18 is the LAB protocol library, which is linked into client tasks (lcmlb
is its only
client at present) to provide LAB protocol communications services.
2.6 Internal Interfaces
2.6.1 OPERATIONS Internal Interfaces
There are no internal interfaces between Operations components since
Operations
services access each other through the public Tasktalk API supported by those
components detailed in IN?~~,RFAC:ES.
to
2.6.2 Operations Support Services <-> COMMUNICATION components
This interface specifies the message type's and structures for messages used
by
COMMUNICATION components to report communications link status to the monitor
task, monT, in Communication Services. lcmnc 5 provides a list of directly
connected,
and routed, nodes to (that is a list of all the nodes that communications can
reach from
the current node). lcmlc 5, Icmlb 20, and lcmpc 21 report node communication
statuses.
2.6.3 Local Communications Access <-> Communications Services (+ others)
This interface specifies how tasks obtain access to intra node communications
services.
2o These services are provided by the Local Communications Access library,
lanai, that
is linked into an e~:ecutable task and provides Tasktalk network port
allocation, message
delivery and remote procedure call (RPC) sf.rvices.
2.6.4 Configuration Services <-> Message Routing/Delivery
This interface consists ofthe update requests, messages, and responses that
pass between
lcmdb 14 and its clients lcmnc 5, lcmlb 20, Icmlc 17, and lcmpc 21.
2.6.5 Application Access <-> IP Message Delivery
This interface is a C language AfI that specifies a single function,
C'A9-97-034 21
CA 02212388 2000-11-17
inaas request application(, that lcmlc 17 uses to get access to lcmlc's
running on
remote nodes. In particular., Icmlc 17 uses it to discover the dynamically
assigned UDP
port used by remote lcmlc tasks. This LJDP port is required by lcmlc in order
to
establish inter node communications over lI'.
2.6.6 IP Message Delivery <-> rsdsl Interface
There are functions to initialized datagram service, add and delete datagram
channels,
enquire about parameters of the communication channels, send messages, and to
control
the timing used to give control to rsdsl routines.
to
When rsdsl 19 is initialized, several callback functions are supplied that are
called by
rsdsl to have received messages handled, do cleanup when necessary, handle
status
messages, and to schedule t:he next time rsdsl will get control.
~ 5 2.6.7 LAB Message Delivery <-> ullpl interface
This interface is very similar in structure to that in section IP Message
Delivery <->
rsdsl Interface .
2.7 Design Motivation
2.7.1 Architecture
2.7. l .a The architecture of the OPERATIONS components was chosen to isolate
changes in the
internode communications ( lcmlc 17, lcmlb 20, lcmpc 21 ) channels from those
for intra
node communications and routing (lcmnc 5 ). By separating internode
communications
functions into separate tasks, the architecture allows additional internode
communications functionality (e.g. native ATM communications task) to be added
more
readily.
2.7. l .b Parsing of and resynchronizing configuration information is
controlled by lcmdb 14 to
CA9-97-034 22
CA 02212388 2000-11-17
avoid duplicating this functionality in many tasks. This also allows the other
tasks to
be more responsive during updates since long delays in service that might
occur while
reading a new configuration tile, or receiving the configuration file from a
master lemlb
20, are avoided.
s
2.7.1.c. Internode routing is handled by lcmnc 5 and so is independent of what
internode
communications protocols are used between nodes. This avoids differences in
routing
protocols between communications protocols, so that routing support is uniform
across
communications protocols.
2.7.2 Reliability Considerations
The internode communications tasks have been designed to expect and react to
loss of
connectivity to other nodes and to automatically sync up when connectivity is
restored
(which is detected by periodic polling).
2.7.3 Performance Considerations
To ensure quick response of message handling tasks (lcmlc 17, lcmnc 5, lcmlb
20, lcmpc
21), long or potentially blocking activities mustbe avoided. This has been
accomplished
by farming the potential blocking activities to forked children (that do not
handle
2o messages), and splitting long activities into smaller manageable chunks.
This splitting
up of actions to be taken is supported by functionality built into
Communication Support
Services.
3 COMPONENTS
3.1 Local Communications Access
3.1.1 Introduction
Local Communications Access provides .a library, lanai 10, to allow access to
CA9-97-034 23
CA 02212388 2000-11-17
COMMUNICATION communication functionality. The interface provided by this
library includes functions for allocation of communication ports, message
delivery over
these ports, as well as RPC services.
Provision of many of the services provided by library lanai 10 are actually
shared
between it , acting as a client, and the messal;e muter task lcmnc 5 , which
provides the
services. lcmnc 5 and library lanai 10 are tvreated as a single component
because they
are very tightly coupled.
1 o Message delivery at four different priorities (from High to Low) and
remote procedure
calls services are supported. There is a limit to the length of messages that
depends on
the priority of the message.
3.1.2 High Level Design Details
3.1.2.a Overview
Other tasks obtain communications ports through library lanai 10 from lcmnc 5.
lcmnc
5 keeps track of all system ports assigned on the node to facilitate message
routing. This
information is stored in a shared memory segment that all tasks can access
using the
lcmai.a 10 library. The number of system (Tasktalk) ports that -lcmnc 5 can
make
available for use by other tasks on the node is limited by the size of the
shared memory
segment and is set at startup of lcrrmc 5 using the -M option. In the current
embodiment,
messages are actually sent using System V fPC message queues - lcmnc 5
allocates a
send and receive queue per communications port and manages the port to message
queue
mappings for all tasks.
For local messages (messages from one task to another on the same node) lcmnc
5 just
forwards the message from one message queue to the other. For messages to
remote
nodes, lcmnc 5 uses information obtained from lcmdb 14 to determine which
protocol
CA9-97-034 24
CA 02212388 2000-11-17
task (lcmlc 17, lcmlb 20, or lcmpc 21 ) the message should be forwarded to. It
is then
the protocol task's responsibility to deliver the message to the corresponding
protocol
task on the destination node, which will forward it to its local message muter
task.
3.1.2.b How to use the API
Messages are sent using calls similar to the one below:
COM RETURN- STAT_.T com_Send_to(
COM NETADDR T' remote addr, /* Message destination */
COM PORT T local Port, /* Communications Port Id */
to U2 T priority, /* Message priority. */
int msgflg, /* Message flags */
U2 T msg-len, /* Message length */
COM NETBYTE-T *msg body ) /* Message body */
For the destination of the message, we need to specify all the elements of the
structure
shown below:
CA9-97-034 25
CA 02212388 2000-11-17
Table 3-1 Specification of remote addresses
Structure member Comments
remote addr.node id v
remote addr.node t v exam le AT NCPC C
remote addr. ort id v. ort
number v
remote addr. ort id v. ort PT GEN C or PT RPCSRV
v C
1 o For the source, one of the local ports obtained through the function com
get multiport()
will usually be specified:
Table 3-2 Specification of local port from which to send message or make RPC
call
Structure member Comments
local_port.port_number_vnot necessarily a port we have obtained
from lcmnc
local-port.port_typ-yusually PT GEN C (or PT RPCSRV C)
The priority must be chosen from one of the following levels:
Table 3-3 Available priority level;
priority comment
.
COM HIPRI often used for short important
messages
COM MHIPRI
COM_MLOPRI
COM LOPRI often used for general purpose
messages
For the msgflg, the usual ones of interest arc::
Table 3-4 Message flags of common use
ms fl comment
~~
0 not return until a message is available
the default case
d_o
IPC NOWAIT force nonblockin T return immediateh if
no messa a endin =
The message length, msg.-len, is the length of the message (not the size of
the buffer),
and the text of the message, in network form, is stored in the buffer msg-
body.
C'A9-97-034 26
CA 02212388 2000-11-17
~~.1.2a Interface between lcmai.a and lcmnc
Here's what's in the shared memory segment:
Table 3-5 C'.ontents of shared memory segment
com shared_memory-ptr-> typical value
csm_network_task_status 0 _
csm maximum-high_port 65,520
csm maximum low-port 49,151
csm_maximum-ports li0
csm_minimum_high_port 65,520
csm_minimum low_port L
my node_id LOl
I my node-type 17
S
csm-port_status[0] see below
csm_port status[1]
Table 3-6 Contents of csm-port-status[] records in shared memory segment
T ical Values
receive ueue 6S1 554 505 0
send ueue 652 653 653 0
ort status 0 1 1 0
ort riorit CI 0 0 0
roc id 5 557 5 559 5 572 0
ort id.. ort number() 1 004 1 020 0
v
ort id.. ort v 0 1 1 0
ort id.. ort number0 1 004 1 020 0
v
ort id.. ort v (1 1 1 0
extra data 0x0 0x0 0x0 0x0
C'A9-97-034 27
CA 02212388 2000-11-17
Table 3-7 Port status bit masks used in port status rec
Name Value ('.ommen
MSPI PORT ASSGND U2 T 10 /* Port assi ned
MSPI PORT CLOSNG U2 _T1 1 /* Close in ro ress
*/
MSPI PORT CNCTNG U2 T 12, /* Connect in ro
ress */
MSPI PORT CMONLY U2 T 13 /* Comms onlv */
MSPI PORT ERROR U2 T 1 4 /* Emor condition.
*/
MSPI PORT EXCLSV U2 T 15 /* Error condition.
*/
1 o typedef struet net addr {
U2 T node id v;
COM ADDR TYP. T node typ- v;
COM POR7 -T pork-id v;
} COM NETADDR T;
3.2 Communication Support Services
3.2.1 Introduction
Communication Support Services provide general purpose functionality such as
I/O
2o utilities, timer utilities, communications database management, etc. There
are anumber
of interfaces provided by support services that are used by other
Communication (Talk)
components.
3.2.2 Interfaces Provided
There are several interfaces provided by this component. Many of these
interfaces are
used by nearly all the other (:ommunication (Talk) components while others are
only
used by a few. Each interface listed below has an assigned keyword name and a
general
description.
3.2.2.a lcm_general: General purpose data structures and management functions,
including:
1. Functions for managing doubly linked li~;ts.
2. Functions for managing actions. Actions are used to split work into small
manageable
CA9-97-034 28
CA 02212388 2000-11-17
parts that will not cause undue delays in :processing.
Interesting data types include: LCM ACTION PTR (a definition of an action),
LCM ACTION FUNCTIC)N (callback that carries out the requested action),
LCM ACTION I-IEADER P (a list to which actions are added),
The following functions are defined:
~ lcm check timeout() checks the currently active queued actions for timer
expiry,
and performs the retry or fail actions for the expired timers.
~ lcm delete action() removes the specified action from its action header (if
any).
~ lcm-queue action() adds the given action to the specified action list. If
the action
was already in another action list, it will be removed without warning.
~ lcm init action header) adds the given action to the specified action list.
If the
action was already in another action list, it will be removed without warning.
t 5 ~ lcm-init action-item() adds the given action to the specified action
list. If the action
was already in another action list, it will be removed without warning.
3. General communications database type definitions and management functions.
4. Functions used in converting address types.
3.2.2.b lcm xdr: XDR packing/unpacking functions, including:
1. XDR pack and unpack functions provided for compatibility with Task support
tasks.
3.2.2.c lcm timer: Timer functions, including:
1. Functions for setting up and using timer (:vents.
3.2.2.d lcm route: Message routing functions and data structures, including:
1. Functions and data types used in message; routing.
3.2.2.e Icm config: Configuration update message definitions and pack/unpack
functions,
C A9-97-034 29
CA 02212388 2000-11-17
including:
1. Support functions for communications d~rtabase update functionality.
3.2.2.f lcm lan: Lan communication database structures and management
functions, including:
1. Lan communications database types and utility functions.
2. Utility functions and services for EP interfaces.
3.2.2.g lcm alarm: Communications alarm reporting functions, including:
1. Functions for formatting; and sending communication alarms to the TASK
layer.
t0
3.2.2.h lcm lapb: LAB communications database structures and management
functions,
including:
1. lab addresses and message types
3.2.2.1 lcm_poll: Bioscience 3270 polling database structures and management
functions,
including:
1. Synchronous polling addresses and message types.
3..3 Configuration Services
3.3.1 Introduction
lcmdb 14, the communications database task, reads in three configuration
files,
lcmdb.conf 16, lapb.conf 9E~, and poll.conf 15, which contain lists of nodes
that can be
reached using various protocols (IP, LAB, Bioscience 3270 respectively). The
configuration files also contain indirect routing tables that specify nodes
that can be
reached by going through other nodes. It then serves this information to other
communications tasks as requested.
The configuration files are distributed to the nodes by lcmdb from a master
lcmdb 14
C.A9-97-034 30
CA 02212388 2000-11-17
running on a configuration server node. The address information required to
connect to
the configuration server node is set up when the node is installed on a host
computer.
Provision is also made for specifying a secondary configuration server node.
Once the
information for the configuration files is received from a configuration
server, it is
stored, and a messaging mechanism using version numbers is used to determine
when
updates to the files are required.
3.3.2 Interfaces Provided
lcmdb provides a message accessible communications database access interface
to other
1 o COMMUNICATION component executable tasks. This service is accessed by
sending
the appropriate database request message to lcmdb 14, which responds by
sending a
number of database update messages to the :requester for processing.
3.3.3 Interfaces Used
Configuration Services 49 uses some of th~~ interfaces provided by
Communication
Support Services 51 that are documented in .Interfaces Provided. In
particular, it uses:
lcm-general, lcm-Config, lcm Ian, lcm-lapb, lem__poll, lcm route.
3.,3.4 High Level Design Details
2o At startup lcmdbl4 processes all its configuration files, gets its well
known
communications port and then sits waiting fir messages. The main message types
of
W terest are:
COM CONFIG UPDATE REQ, and
XXX CTL NEWDB-REQ, where XXX = [LAN 1 LAB 1 POLL].
When a COM CONFIG_UPDATE REQ nuessages is received, lcmdb reprocesses its
configuration files (see routine Icmdb-filtefyles) and queues an action item
on the
db updates queue with the details ofthe requeat. The LCM_ACTION FUNCTION for
C.A9-97-034 31
CA 02212388 2000-11-17
this queue is db do update() which calls lc~~~ndb- continue update() to do the
work. A
DB CONTROL ___R data st:mcture referred to as db control is used to coordinate
many
simultaneous update operations.
db do update causes db-con~g update() to be called for each of the tasks that
need to
be notified, which in turn calls db send_dbid message() to send the
notification
message to the muter task. The other communications tasks are notified if
needed also
in lcmdb continue-update through calls to functions pointed to by db iptr->di
step
(db iptr is data type DB-ITERA'TE P).
3.4 IP Message Delivery
3.4.1 Introduction
The lan protocol task, lcmlc, which is the main product of the IP Message
Delivery
component, handles forwarding messages from one node to another (to it's
instance of
lcmlc) over an IP network using IJDP datagrams. It also monitors the
communication
link status of these directly connected nodes (the list of which is obtained
from lemdb,
see Configuration Services), and notifies the monitor task, monT, of any
status changes.
(:ommunication link monitoring is accompl fished by: i) periodic network
polling; and
2o ii) an lcmlc task on a node that is about to shutdown will notify the lcmlc
tasks on all
directly connected nodes so that they know immediately that communications to
the
shutdown node is down.
Each node's lcmlc uses a set of IP numbers Gone for each network interface on
the host
on which it is running) and t.JDP port numbers. While lcmle's on different
machines
know each other's IP addresses (listed in /etc/hosts or accessed using domain
name
service), they cannot know each other's UDP ports because they are assigned
dynamically, i.e. every time an lcmlc is started it gets new and unknowable
UDP port
numbers. This is true even of two instances of lc;mlc running on the same
host. This
C A9-97-034 32
CA 02212388 2000-11-17
information is accessed using functionality provided by the Application Access
component. lcmlc forks a child, referred to as the hunter, that does this UDP
port
number resolution. The hunter receives periodic directives from its parent,
since this
process is time consuming and subject to irregular delays.
?..4.2 Interfaces Used
IP Message Delivery uses some of the interfaces provided by Communication
Support
Services that are documented in s.3.2.2. Interfaces Provided. In particular,
it uses:
lcm-general, lcm config, Icm ran, lcm alarm, lcm route and lcm timer. It also
uses
t 0 interfaces provided by the Application Access and rsdsl components.
3.5 LAB Message Delivery
3.5.1 Introduction
The LAB Message Delivery task 52 (IcmlY>) handles forwarding messages from one
node to another over serial lines using the LE~B protocol. It also maintains a
link status
to directly connected nodes (the list of which is obtained from lcmdb) by
polling, which
is forwarded to monT in the C',omrnunication Services component. For nodes
where the
connection is via a modem, Icmlb does have modem control features to establish
the
2o connection to the node. Icmlb is used to tall; to AVT terminals, which run
proprietary
firmware. It cannot be used to talk to other lcmlb's (it is not symmetric like
lcmlc is).
lcmlb 20 obtains the list of nodes (and the serial devices to use to contact
each) from
lcmdb 14 at startup and whenever the configuration is changed.
3.5.2 Interfaces Used
LAB Message Delivery uses some of the interfaces provided by Communication
Support Services that are documented in s._3.2.2. Interfaces Provided. In
particular, it
uses: lem-general, lcm~config, lcm_-lapb, lctn alarm, lcm_ route and
lcm~timer. It also
CA9-97-034 33
CA 02212388 2000-11-17
uses interfaces provided by the ullpl component.
?..6 Bioscience 3270 Message Delivery
3..6.1 Introduction
The Bioscience 3270 Message Delivery task (Icmpc) handles forwarding messages
from
one node to another over serial lines using the l3ioscience 3270 protocol. It
also maintains
a link status to directly connected nodes (the list of which is obtained from
lcmdb) by
1 o polling, which is forwarded tc»nonT in the Communications Services
component. -lcmpc
is used to talk to proprietary communication hardware and firmware. It cannot
be used
to talk to other lcmpc's (it is not symmetric like lcmlc is).
lcmpe obtains the list of nodes from lcmdb at startup and whenever the
configuration is
changed.
3.6.2 Interfaces Used
Bioscience 3270 Message Delivery 53 uses some of the interfaces provided by
Communication Support Services that are documented in s.3.2.2. in Interfaces
Provided.
2o In particular, it uses: lcm-.general, lcm config, lcm-lapb, lcm alarm, lcm
route and
lcm timer.
3.7 Application Access
3..7.1 Introduction
Figure 5 gives a short overview of how Application Access works. A client task
57 on
host B 60, which links in the application access library lcmaa.a 58, makes a
socket
connection to the application access daemon process, called inaas.d 6a,
(usually on a
different host [host A 59] but not necessarily), which forks a child to handle
each
C.A9-97-034 34
CA 02212388 2000-11-17
request. The client next writes information down this socket to identify the
application
it wishes to have access to. The child inaas.d 55 compares this request with
those
applications configured in inaas.c;onf 13 and, if a match is found, starts the
appropriate
access agent. At this point a socket connection exists between the client task
57 and the
access agent 56 for the requested application (which has replaced the child
inaas.d).
Application specific information is then exchanged over this socket between
the client
and the access agent 56.
Application Access provides i) an application access client library lcmaa.a
58; ii) an
application access daemon process inaas.d 6a; iii) several paired special
purpose access
agent 56 and client tasks 57 (inaas test -> lcmar, inaas rg -> lcmdt); and iv)
a file
specification for the inaas.conf file 13, used to specify which services an
inaas.d daemon
process can serve. inaas.d 6a provides services similar to RPC portmap, that
is, given
an identifier for an application (in this case a host name, application type,
and
application instance, which are all strings), inaas.d provides a socket
connection to the
designated access agent, usually lcmar or lcmdt. Tnformation is usually
exchanged over
this socket connection (for example UDP port numbers) between a client task
and the
access agent to access and/or startup Internet applications.
The simple client inaas test: connects to the access agent lcmar and prints
out the UDP
port of a remote node received from lcmar. lcmar is the access agent that
starts up
and/or connects to a node, and provides access to the node's UDP port number
(to lcmlc
or inaas_test).
The client, inaas rg 62 com~ects to the acces;~ agent lcmdt 61, which provides
access to
desktop monitor user interface startup. lcmdt: 61 is analogous to lcmar, being
the access
agent that is used to startup remote desktop monitor user interfaces and
display them
back to the node on which inaas rg is running.
CA9-97-034 35
CA 02212388 2000-11-17
In the following discussian., only lcmaa, lcmas and lcmar will be mentioned.
The same
information applies if lcmrl; is substituted for lcmaa and lcmdt is
substituted for lcmar
(except where specifically noted).
3.7.2 Interfaces Provided
Application Access provides several different interfaces, enumerated below.
1. The application access library lcmaa.a provides a simple API with a single
function
call:
int inaas_request_application(
char * ira hostname,
char * ira ip__protocol,
char * ira app identiver,
char * ira app-instance,
int ira__ timeout );
This function returns the file descriptor of the socket connected to the
access agent for
the requested application.
2. Two simple client's are provided, inaas_ test and inaas rg. Their command
line
arguments specify the interface they provide:
> client task hostname application-type application instance
where hostname identifies the which host's inaas.d to contact and the
application type
and instance are used to identify a service on the host. For more details see
the
specification of the format for the application access daemon's configuration
file,
inaas. conf.
3. The access agent lcmar 67, which is used for node startup and UDP port
discovery,
C.A9-97-034 36
CA 02212388 2000-11-17
is intended to be used by other clients bes ides inaas-test. It provides an
interface that
is the (request, responsf;) pair to be sent over the socket between it and a
client.
There is only a single request supported which is a request for the remote
node's
UDP port. The response is either "OK=<nodeid>:<ipNumber>: -<portNumber>\n"
or "FAIL=<reason>\n" where the items in <>'s will be replaced with appropriate
values.
3.7.3 Interfaces Used
Application Access uses some of the interfaces provided by Communication
Support
o Services that are documented in s.3.2.2. Interfaces Provided. In particular,
it uses:
lcm-general, and lcm_lan.
3.7.4 High Level Design Details
3.7.4.1 Architectural Overview
Referring to Fig. 6, Application Access is divided into five modules: lcmas
69, lcmar
67, lcmaa 68, lcmdt 61 an<I lcmrg 62. See Figure 6 Application Access
Component
Block Diagram for an overview of information flows and process invocation
events
between the modules and external components and subsystems.
The general pattern is that an access client (cmrg 62, inaas test from lcmaa,
IP Message
Delivery) calls inaas request application() from the lemaa module library 68,
which
makes a socket connection to the inaas.d daemon process (module Icmas 69) on
the
requested host. At this point inaas.d forks a child which execs Icmas-vr,
which handles
the upcoming request. The lcmas- yr process is, therefore, a child process of
the inaas.d
daemon process. Information is exchanged between the client and lcmas yr
(child of
illaas.d) through the lcmaa module library function inaa.s request
applications on the
client side. If a valid request is submitted, lcmas yr execs the appropriate
access agent
(lcmar or lcmdt), and -inaas _ request, application( ) returns with the file
descriptor of the
CA9-97-034 37
CA 02212388 2000-11-17
socket which still maintains the connection. At this point, the client task is
directly
connected via the socket to the access agent, and further application specific
information
is exchanged over this socket.
The access agent lcmar uses Local Communications Access to request the list of
UDP
port numbers from IP Message Delivery 66 which it searches to find the
appropriate one
to return to its client over the socket.
3.7.4.2 Modules
3.7.4.2.1 lcmar
3.7.4.2.1.a Important Routines
~ main(). This is the main line of lcmar, which does the following:
1. invoke lcmar-init task to parse command line options.
2. checks that the socket to which it is connected is on the local lan if
required.
3. reads request over socket from client and compares it with expected value.
4. gets a semaphore to prevent simultaneous lcmar's trying to start the same
node.
S. checks whether the node is already up using lcm-ping system.
6. if node is up, skip to step 8
7. invoked the startup script specified on the command line.
8. check whether node is up, die and release semaphore if fails.
9. release semaphore protection.
10. invoke query ip addrs to get all the UDP ports from lcmlc.
11. find if one of these matches the network part of the clients socket
address.
12. return the matching LJDP port in OK message or log a FAIL message over the
socket.
~ lcmar init task(). This routine parses the command line options to lcmar and
sets
CA9-97-034 38
CA 02212388 2000-11-17
up some global variables and environme;nt variables for later use.
~ lcmar-ping-system(). This routine sends a message to the echo port on the
current
node and waits for a response. If the node is up it will get a return message.
~ lcmar start system(). This routine invokes the startup script (given as a
command
line parameter) and waits for it to return.
~ query ip addrs(). This routine packs the request message to lcmlc for the
list of
UDP ports and sends the message. It waits for the response which it returns
after
some processing.
0 3.7.4.2.2 lcmaa
3.7.4.2.2.a Important Routines
3.7.4.2.2.b inaas request application(). This routine is part of the interface
to Application Access
documented in s.3.2.2. Interfaces Provided. Client tasks invoke this routine
to gain
access to (usually ) remote application agents. This routine sets up a
connection to the
remote inaas.d daemon and exchanges information to identify the requested
application.
If the request is successful, it returns the socket that is now connected to
the access
agent.
3.7.4.2.2.c main(). This is the main line for client inaas-_ test that is
invoked by start_node.
3..7.4.2.3 lcmas
3.7.4.2.3.a Important Routines
~ U main. This routine is the mainline for inaas.d. It opens and binds a
socket to the
inaas port from /ete/services. It then listens on this port and forks a child
server
whenever a valid connection is established, and goes back to listening.
~ lemas yr script. 'This is a PERL script that is forked by inaas.d to handle
C.A9-97-034 39
CA 02212388 2000-11-17
requests. The child server parses inaas.conf , reads in the request (in two
parts)
over the socket which is attached to its stain, and sends back responses
through
stout which is connected to the socket. If the request matches an application
configured in inaas.cc>nf, the listed application access agent is exact in
place of
this script.
3.7.5 Application Access and Tasktalk Network Startup
An aspect of the interaction of the modules of the Application Access
component and
lcmle, acting as an application access client. that should be not be
overlooked is that it
t 0 provides a simple, powerful way, to start a network in accordance with
this invention
that is completely shutdown. As discussed in the above section on the lcmar
component,
and in the event sequence. "Start IJp", lcmar will initiate node startup if it
finds that the
node it must obtain the UDP port address for is down. This node will be called
node
A. The UDP port address is required by an lcmlc task on another node, node B,
that
needs to communicate directly with node A. Once node A has started, it will
try to
connect to all the nodes it must talk directl« to, and in the process, start
any of those
nodes that were down. Once all of node As directly connected nodes start, they
will also
try to connect to all their directly connected nodes. This process will
continue until all
nodes in the network are up and communicating with each other as specified in
their
2o communication configuration files lcmdb.conf.
The result, then, of starting a node as soon as another node attempts to
establish
communications to it, is that the entire network can be started by starting
any one of the
nodes in the network. As well, if a node goes down unexpectedly, the lcmlc
tasks of
directly connected nodes will attempt to re-f;stablish communications to it,
so as soon
as the failed node can be started, it will be started. In point of fact, a
network operator
for a network based on this invention must take explicit action to keep a node
down, if
required, as opposed to having to take action to get a node. up if it has gone
down.
CA9-97-034 40
CA 02212388 2000-11-17
3~.8 Operations Framework
3.8.1 Introduction
The Operations framework is responsible for making it simpler and faster to
build
executable tasks using the system of the invention by providing implementation
for
common task activities including: startup, argument processing, generic error
condition
handling, task shutdown, etc. This framework also forces most system tasks to
be
similarly structured, making them more consistent and thus easier to
understand.
to A typical server task will be structured as shown in Fig. 7.
The task will call tsk-openT'ask(), then provide some task specific
initialization code at
startup. It will then get a well known communications port, using tsk-
openPort(), so
other tasks can reach it to request services, and set it as the blocking port
using
~5 -tsk setBlockingPort(). Then a set of callback functions will be installed
using
tsk installCalIBack() (see Communication Services) that will be activated
later when
appropriate messages are received. Finally tsk-startProcessingEvents() (the
message
handling loop) will be called to start processing messages. The task will
normally end
by user defined code calling tsk exit() or tsb-closetask().
3.8.2 Interfaces Provided
This component provides part of the Tasktalk API.
3..9 Communications Services
3.9.1 Introduction
OPERATIONS Communications Services are services built on top of those provided
by
the COMMUNICATION Local C'.ommunications Access component. Some services
C.A9-97-034 41
CA 02212388 2000-11-17
available here map directly on to services from the Local Communications
Access
component library lanai, though with added value, while others are completely
new.
The main extension of the COMMZJNICATION communications functionality is that
client tasks do not explicitly receive messages. Instead they install
callbacks for various
message types or sources of messages and then activate the supplied message
handling
loop by calling tsk startProc:essingF?vents().
Other value added services include: abstraction/extension of communications
addresses
(primarily in the use of ports); message buffering to reduce kernel memory
usage; the
ability to use arbitrary length messages using message segmentation (library
lemai only
supports messages shorter than COM LOPRI- LEN=2048); and the packaging of
received messages, along with other pertinent information into special
TSK MSG HANDLER-PROC- T structures for more convenient argument passing.
These are used extensively with the callback mechanism just described.
New services include: message duplication; communication link status query and
status
change notification; task management including status query and status change
notification; and automatic pack/unpack of structures to be sent in messages.
Message duplication services are used when the intended receiver tasks of a
broadcast
message is unknown, and/or there is more than one intended receiver task. The
message
is sent to a special "duplicator address", where it is received by the dupT
task, and
forwarded to all interested receiver tasks. The receiver tasks will have
previously
registered with dupT to receive the messages they are interested in.
The communication link status ser~~ice provides link status query routines,
and automatic
notification of changes in communication link status to remote nodes
(establishment or
loss of communications). The status of commcmication links to remote nodes is
available
CA9-97-034 42
CA 02212388 2000-11-17
from monT, which in concert with the other communications tasks (the message
delivery
tasks lemlc, lcmlb, and Icmpc) and remote node's monTs maintains up to date
status
information. For details on this interaction bc;tween monT tasks, see the
event sequence
"Communication Link Status Change Notification". As mentioned in connection
with
the Local Communications Access component, monT must know the routes between
nodes so that it can determine which nodes are unreachable when a routing node
goes
down.
Operations management services are provided by the tmgT tasks in concert with
monT.
t o To provide this service, tmgT plays an analogous role to the message
delivery tasks in
the communication link status service. Instead of monitoring communication
link status,
tmgT monitors the status of all the tasks that comprise a node. If a task on
the node has
died or is otherwise not responding, tmgT reports the change in the node's
task status to
monT, and then initiates corrective action. This may only require restarting
the task, or
restarting the entire node. Tasks can register for automatic notification of
changes to a
node's task status, and the task status can be propagated to other nodes in
the network
using a mechanism very similar to that described in the event sequence
"Communication
Link Status Change Notification". Besides it's obvious use in detecting
problems in the
network, the task management services are also used during a cold node or
network
startup. As nodes startup around the network, application tasks will want to
establish an
information exchange with tasks on other nodes in the network. Using the task
management services, an application task can be notified when all tasks on a
particular
node are up.
Using SUN's rpcgen functionality, this compc>nent also adds the ability to
automatically
pack a message structure in a platform independent manner (managing the
necessary
memory allocation/deallocation) and send i1: in a message or use it in an RPC
call.
Automatic unpacking of these messages is also supported. For all these
functions, the
pack/unpack function (which produces <rrchitecture independent packed data)
C.A9-97-034 43
CA 02212388 2000-11-17
xdr YOUR-STRUCTURE-NAME must be supplied. The code for this function will
have been automatically generated by rpegen.
f~.9.2 Interfaces Provided
This component provides part of the Tasktalk API
3.10 Operations Support Services
3.10.1 Introduction
Operations Support Services is a group of services that provide more
convenient access
to operating system functionality and other low level services. This includes
task
debug/log services, timer services and command execution services.
Timer Services are used by clients of the system ofthe invention to replace
calls to the
POSIX alarm() system function. 'Timer Services add value because they support
more
than just second resolution, c:an provide both =message and signal based
notification, and
can support multiple active timers. The timT task provides a large portion of
this
functionality.
Command Services provide clients of system of the invention with the ability
to run Unix
commands on remote nodes, much like rsh or rcmd. Value is added because these
services provide a platform independent API, hide the network topology, and
also
provide convenient asynchronous notification of status changes in running
commands.
There is no interactivity to remotely executed commands except for returned
results.
Debug/Log Services support application task debugging, execution tracing,
stack and
memory dumps etc.
CA9-97-034 44
CA 02212388 2000-11-17
,..10.2 Interfaces Provided
This component provides part of the T'asktalk API.
?..11 Reliable Sequences Datagram Service Library, rsdsl
~'.ll.l Introduction
rsdsl, or the reliable sequenced data gram service library, is linked into a
client task to
provide reliable LTDP based datagram services.
3.12 ullpl
3.12.1 Introduction
ullpl is the LAB protocol library, which is linked into client tasks to
provide LAB
protocol communications services.
~ 5 4 INTERFACES
4.1 Interfaces Used
4.1.1 Configuration File Icmdb.conf
lcmdb.conf is one of the configuration files for the C'.OMMUNICATION
Configuration
Services task, lcmdb. Each node has its own unique lemdb.conf file. The file
specifies
which remote nodes should be reachable over IP and any indirect routing.
4. 1. I.a File Format
The file can have three different types of entries in it, as well as blank
lines and
comments (that begin with #'s) which are ignored. There is a VERSION
specification
line, used by lcmdb to determine if its copy of lcmdb.conf is up to date, and
then
COM ADDRESS and COM_ ROUTING entries for appropriate nodes. The formats of
the latter two are given below:
CA9-97-034 45
CA 02212388 2000-11-17
COM ADDRESS=node id.°comm type: hosaname: app id:app inst
C.'OM ROUTING=parent-id.~PRl: node id, oomm_type
The fields are as follows:
node id Numeric node id.
comm-type Communication type of node.
hostname Unqualified Internet hostname of the host on which the node runs.
app id Application Identifier, a printable text string, of up to 64
characters,
t o taken from [a-zA-ZO-9-_].
app inst Application Instance, aprintable text string, up to 64 characters,
taken
from [a-rA-ZO-9--]
parent id Numeric node id of parent node, the one through which all messages
to the node in question should be routed.
IS
Here's some sample lines from a Video Conferencing System:
COM ADDRESS-=1085:AT__.SNPC:atdncpc5:wave._vcsc:vcsc-1085
COM ROUTING==S1:PR1:~~54,AT_VC'.IU
The first of these specifies a BMS node (communications type AT_SNPC) that
lives on
the host atdncpc5 with node id 1085 that can be reached directly over TCP/IP.
The
second specifies a terminal (AVT ) node with node id SS4 that can only be
reached
through node 51 (which is an SNC').
4.1.2 Configuration File lapb.conf
lapb.conf is the configuration file for the LAB Message Delivery task lcmlb.
It is read
by lcmdb and the parsed information is forwarded to lcmlb. It details the
necessary
C.A9-97-034 46
CA 02212388 2000-11-17
configuration for a node to talk to other nodes over serial links using the
LAB protocol.
This is usually only used on SN(; (terminal server) nodes.
~G.l.2.a File Format
The file can have two different types of entries in it, as well as blank lines
and comments
(that begin with #'s) which are ignored. There is a VERSION specification line
and then
LAPB ADDRESS specification lines. The format for the latter is shown below:
LAPB ADDRESS'=node- id : comm_ type: dev~ath: dceymodem-type)
t o Here are the definitions of each of the field~~:
node id Numeric node id
comm type Communication type of node.
dev-path Full pathname of'serial device to use.
modem type Case insensitive specificarion of modem type that is connected to
the
serial device, omitted if direct serial connection.
To make this more concrete, consider the example lines taken from a Video
Conferencing platform that specify how to communicate with two different
terminals:
2o LAPB ADDRESS=55 I:AT-VCIU:/dev/ttyh08:dce:usrs
LAPB ADDRESS=5~~3:AT_ VCIU:/dev/microplexl.coml:dce
The first terminal listed, with nc>de id 551., is connected via a USR (US
Robotics)
modem that is attached to the serial device /dev/ttyh08 (one of the devices
created by a
multiport serial card driver). The second terminal is connected by what
appears to Video
Conferencing as a direct serial connection provided by a Microplex print
server daemon
which creates the device file /dev/bbd microplex.coml. No modem specification
is
required in this case.
CA9-97-034 47
CA 02212388 2000-11-17
~E.1.3 Configuration File poll.conf
poll.conf is the configuration file for the Bioscience 3270 Message Delivery
task lcmpc.
It is read by lcmdb and the parsed information is forwarded to lcmpc. It
details the
necessary configuration for a node to talk to other nodes over serial links
using the
Bioscience 3270 protocol. This is usually only used on SNC (terminal server)
nodes.
4~.1.3.a File Format
The file can have two different types of entries in it, as well as blank lines
and comments
(that begin with #'s) which are ignored. 'There is a VERSION specification
line and then
SPOLL ADDRESS specification lines. The format for tire latter is shown below:
SPOLL ADDRESS=node_id: comrn_type: card no: card line no: syrtc_poll addr:
async~oll addr
Here are the definitions of each of the fields
node id Numeric node id
comm_type Communication type of node.
card rco id of the synchronous polling card the node is connected (indirectly)
to.
card line no line number of the synchronous polling card the node is connected
(indirectly) to.
sync~oll addr The synchronous polling address of the node.
async~oll addr The asynchronous polling address of the node.
4..1.4 Configuration File inaas.conf
inaas.conf is the configuration file for the Application Access daemon process
inaas.d.
It describes all the applications (typically Wave nodes and user interface
applications)
that inaas.d can start and/or connect to.
4.1.4.a File Format
C.A9-97-034 48
CA 02212388 2000-11-17
The file consists of entries of the form shown below, one per line, while any
lines that are
empty or that begin with a # are ignored:
app id app inst proto user group agent-prod; agent, name [ agent-param... ]
Here are the definitions of each of the fields.
Application Identifier, a printable text string, of up to 64 characters
app id taken from [a-zA-ZO-9 -] .
0 app inst Application Instance, a printable text string, up to 64 characters,
taken
from [a-zA-Z0-9--]
proto IP prc>tocol, from /etc/protocols. Usually udp.
user User name on the local machine, not being a privileged system user.
group 'The default group for user, from the system password database, not
being a privileged system group.
2o agent~rog The full path to an application agent program that has executed
permission to usergr~~up, ~rithout any setuid or set setgid permissions.
agent name Short version of agent nay°ne.
agent~aram Parameter(s), if' any, for the agent program.
The combination of app id, app-inst, proto must be unique in each computer
running
the inaas server.
CA9-97-034 49
CA 02212388 2000-11-17
To make this more concrete, consider the example line taken from a wave
platform that
specifies how to start the cnc node:
wave ncpc ncpc 3 udp cnc wave /u/wave/cnc;/bin/lcmar lemar -d 0 -S
"$HOME/etc/hu"
So, when an Application Access client (inaa s-test) asks inaas.d to start the
application,
wave ncpcncpc 3udp,inaas.dwillstartuptheexecutable/u/wave/cnc/bin/lcmarasuser
cnc (group wave) and pass it the parameters -cl 0 -S "$HOMEletclhu ". As it
happens, the
-S parameter to lcmar specifies the name of a script to be run after setting
up the
l0 environment. Thus, $HOME/ete/hu is finally run to start up the node.
4.2 Interfaces Provided
4.2.1 Tasktalk API
The Tasktalk API includes definitions of all API functions, relevant data
structures, and
usage hints and warnings.
4..2.2 Utility tasks inaas test and inaas rg
2o The utility tasks, inaas test and inaa rg are exported from the
COMMUNICATION
component Application Access and are invol<:ed by shell scripts to during the
process of
starting up a node or a desktop GL~I respectively. Both of these tasks take
the same
command line arguments:
inaas_test hostname app i~ app_inst ~protocolJ
inaas_rg hostname app- icl app_._~nst lprotocolJ
Here are the definitions of each of the fields (~~ome are the same as for
inaas.conf above).
C.A9-97-034 50
CA 02212388 2000-11-17
hostname The hostname of the unix host on which the application
should be run.
Application Identifier, a printable text string, of up to 64
app_id characters, taken from [a-zA-ZO-9-_]
app inst Application Instance, a printable text string, up to 64
characters, taken from [a-zA-ZO-9--]
protocol Optional IP protocol specifier, defaults to UDP
Following along on the example from inaas. conf, the cnc node on host wavehost
could
be started using the following cornrnand:
inaas test wavehost wave_ncpc ncpc-3 udp
5 EVENT SEQUENCES
5.1 Introduction
The following conventions are used in the event sequence diagrams:
~ messages sent via the system of the invention (Tasktalk) are shown as dark
solid
lines;
~ messages sent via socket connections are shown as light sold lines;
~ forking or executing a process is shown as a dashed line.
5,2 Normal Operating Sequences
5..2.1 Message Delivery
Fig. 8 illustrates a typical event sequence to send a message between two
tasks running
on different nodes.
~ The message receiver task 72 starts up and gets its well known port,
CA9-97-034 51
CA 02212388 2000-11-17
<WELL KNOWN PORT>, from lcmnc 5.
~ The message sender task 73 starts up and gets a private port from lcmnc.
~ The message sender task 73 executes function tsk send() to address mode A,
WELL KNOWN__ PORT%-. The formatted and packed message is forwarded to
lcmnc 5 for handling.
~ lcmnc 5 determines the message is destined for a different node that is
reachable
over IP. The message is routed to the IP message task, lcmlc 17.
~ lcmle 17 forwards the message to lcmlc on the destination node over IP.
~ lcmlc 17 on the server node receives l:he message, checks that it has come
to the
1 o correct node and forwards it to the muter task, lcmnc 5, for delivery.
~ lcmnc 5 looks up the requested port and determines that the message should
be
forwarded to the message receiver task.
5.2.2 RPC client and server transaction
Figure 9 depicts a typical sequence of messages sent between a client and
server tasks
running on different nodes.
~ RPC server 74 starts up and gets its well known port, <WELL
KNOWN PORT:>, from lcmnc 17.
~ RPC client 75 startup up and gets a private port from lcmnc.
~ RPC client 75 executes function tsk rpc() to address mode A,
WELL KNOWN-PART>. The formatted and packed request message is
forwarded to lcmnc for handling.
~ lcmnc 5 determines the message is destined for a different node that is
reachable
over IP. The message is routed to the IP message task, lcmlc
~ Icmlc 17 forwards the message to lcrr~lc on the destination node over IP.
~ lcmlc 17 on the server node receives the message, checks that it has come to
the
correct node and forwards it to the router task, lcmnc, for delivery.
~ Icmnc 5 looks up the requested port and deterniines that the message should
be
forwarded to the RP(: server task 74.
CA9-97-034 52
CA 02212388 2000-11-17
~ the server task takes some action and generates a response that is directed
to the
source of the request.
~ the response message passes to lcmnc; which routes it to lcmlc after
determining
that this new message is destined for a different node that is reachable over
IP.
~ Icmlc on the client node receives thc: message, checks that it has come to
the
correct node and forwards it to the muter task, lcmnc, for delivery.
~ lcmne delivers the response message to the RPC client 75.
5.2.3 Communication Link Status Change Notification
1 o Fig. 10 depicts a typical sequence of messages that occur when application
tasks register
with the monT task to be notified of communication link alarms for directly
connected
nodes and remote nodes. Note that all messages actually pass through lcmnc en
route
to their destination.
In the time sequence shown node A 84 is directly connected to node B 85 and
node B is
directly connected to node C 86. Node A is not directly connected to node C,
but the
node As communication configuration specifies that node C can be reached by
using
node B as a routing node. All three nodes are IP network Tasktalk nodes.
~ Icmnc 5 on node A sends a list of all directly connected and routed nodes to
the monT
on node A using the MON MSCJ TYPE_ NODE REPORT ROUTE message.
~ The node A monT 80 registers with the node B monT 80 for communications link
status change notification for all nodes that node B routes for node A,
including node
C.
~ An application task 81 on node :B registers for communications link status
change
notification for node C.'.
~ An application task on node A 84 registers for communications link status
change
notification for node C.' 86.
~ The node B lcmlc tasks send echo messages to the node C lcmlc task, which
returns
CA9-97-034 53
CA 02212388 2000-11-17
the echo message, confirming the integrity of the communication link.
~ When node B lcmlc does not receive a reply to the echo message sent to the
node C
lcmlc, the communications link status is considered to be in alarm and the
communications link status change is reported to the node B monT.
~ The node B 85 monT reports the communications link status change for node C
86
to the node B application task 81.
~ The node B monT reports the communications link status change for node C to
the
node A monT.
~ The node A monT reports the communications link status change for node C to
the
1 o node A application task.
Note that this registration and forwarding mechanism for communication link
status
changes can be extended. to an arbitrary number of hops (number of hops is 2
from
node A to node C in this example), and also is used to propagate communication
link
status through the Tasktalk network for L.AB and Bioscience 3270 nodes.
5.2.4 Start Up
Referring to Fig. 11 is a typical sequence of messages sent between the
communications
tasks during node startup. N ote that all messages actually pass through lcmnc
en a route
to their destination.
~ lcmar 11 is exact by inaas.d to find a node's UDP port address (and start it
up if
necessary). In this case the node is not up yet so lcmar must start it.
~ lcmar 11 uses the system() command to start up the shell script hu 90.
~ hu 90 parses the tasklist and starts up the communications tasks one after
another (the
order is lcmne 5, monT' 80, lcmdb 14, lcmlc 17, other message delivery tasks,
application tasks). This continues as messages are sent around by the started
tasks.
~ lcmnc 5 is started by hu 90 and initial izes t:he shared memory segment that
other tasks
use to request ports and to monitor the status of their ports. It also
configures its own
port COM PORT ROUTING.
~ monT 80 is started by hu 90 and gets a port from lcmnc 5.
CA9-97-034 54
CA 02212388 2000-11-17
~ lcmdb 14 is started by hu and gets a port from lcmnc 5.
~ lcmnc 5 realizes lcmdb 14 is up and sends it a request for a database
download.
~ lcmdb 14 downloads the required information in a number of messages to
lemnc.
~ lcmlc 17 is started by hu and gets a port from lcnmc
~ lcmlc 17 sends a database reguest to lcmdb 14.
~ lcmdb 17 downloads the required information to lcmlc. At this point, all the
lcm
tasks know what the network looks like.
~ hu 90 starts other tasks from the tasklist then exits triggering lcmar to
continue
processing.
I o ~ lemar 11 verifies that a rnessal;e sent to the echo port returns to it.
~ lcmar 11 sends a request to lcmlc for all the active UDP port numbers.
~ lcmlc 17 sends the list to lcmar, which decides which is the appropriate
port number
to write down a socket to the application access client. It uses the
parameters of the
socket to decide which port to write.
~ lemle 17 sends lists of all the directly connected and routed nodes to monT
80.
5.2.5 Application Access
Referring to Fig. 12 shown is a typical ~~equence of events that occur when an
application is accessed using the ,~rpplications Access component above. For
the
2o purpose of this illustration, the client will be the lcmlc address hunter
for which the
appropriate access agent is lcmar 11 to be run on the node for which the UDP
address
is needed.
The two tasks (lcmlc 17 and hunter 10) at the left of the diagram are running
on a
different node (and often a different host) than the two (lcmlc 17 and lcmar
11 ) tasks
shown at the right. inaas.d 6a and child inaas.d 55 are tasks running as root
on the same
host as the node on the right.
~ the hunter 10 (acting as an application access client) initiates a socket
connection to
the inaas.d daemon on the host on which the application (usually a wave node)
C.A9-97-034 55
CA 02212388 2000-11-17
resides.
~ the inaas.d 6a accepts this connection and forks a child to handle the
upcoming
request.
~ information identifying the request is exchanged over the socket between the
hunter
10 and the child of inaas.d 55.
~ child inaas.d validates the request by comparing it with data in inaas.conf
(see
Configuration File lcmdb.conf in s. 4.1.1), and exec's the appropriate access
agent
task (in this case Icmar running as the node's user).
~ the hunter 10 writes a request for LJDP port information down the socket
which is
1o now connected to lcmar.
~ lcmar 67 checks that the node is up (see the event sequence Start Up in
s.5.2.4), then
sends a request for this information to lcmlc.
~ lcmlc 17 sends the list of all active UDP ports (one for each network
interface) back
to lcmar.
~ 5 ~ lcmar 67 uses parameters of its socket connection to the hunter to
decide with UDP
port's information should be written down the socket to the hunter.
~ the hunter 10 forwards t:he newly acquired address information to it's
parent lcmlc
which will make it possible for it to talk to the remote node's lcmlc.
20 5.2.6 Two nodes establishing communications over IP
Referring to Fig. 13 is a typical sequence of messages sent between tasks on
two
different nodes as they establish communications over IP.
Note that for purposes of clarity, the three tasks on the left will be
referred to as residing
25 on node A, while those on the right will reside on nc>de B. Also note the
messages from
a hunter to its lemlc actually pass through lcmnc (not shown for simplicity).
~ lcmlc 17 on both nodes fork children that hunt for other node's addresses.
These
"hunter"s make calls to Application Access functionality.
CA9-97-034 56
CA 02212388 2000-11-17
~ Node A hunter 10 finds node B ( see the event sequence entitled Fig. 12
Application
Access for more details) address and forwards details to lcmlc 17.
~ lcmlc 17 sends echo message to COM_ fORT_ ECHO on the node B. If it returns
node will be made up and monT' notified.
~ node B lcmlc receives message, notes it does not have the address for the
originating
node (A), and tells its hunter to look for l:hat node right away.
~ lcmlc 17 then forwards echo to lcmnc (where CC>M PORT ECHO logically
exists).
~ lcmnc 5 switches destination and source addresses and returns echo to lcmlc.
~ lcmlc 17 cannot send message back to original node (A) cause: does not have
its
o address, message discarded.
~ Node B hunter finds node A address, notifies lcmlc.
~ echo message is sent for Node B lcmlc, passing through A lcmlc, A lcmnc, A
lcmlc
before returning. On return lcmlc on node B notifies its monT that node A is
up.
~ Meanwhile, node A lcm:fc retries sending echo to node B which now succeeds,
and
~ 5 node A marks node B as up and notifies monT'.
5.2.7 Testing communications between two nodes
Referring to Fig. 14 is a typical sequence of messages that could be sent when
ncmat 102
is run to test communications to a remote node.
20 ~ ncmat 102 obtains its private port from ic;mnc.
~ ncmat sends echo message to COM POET ECHO on the remote node B.
~ this message is forwarded by lcmnc: to lcmlc to the remote lemlc on node B
to the
remote lcmnc.
~ remote lcmlc swaps the source and destination addresses and sends the
message back.
25 It is passed through remote lcmlc, lcmlc and lcmnc before returning to
ncmat 102.
6 APPENDICES
Appendix I describes a Communication Access API for the preferred embodiment
of the
invention described.
CA9-97-034 57
CA 02212388 2000-11-17
Appendix II describes an IP Message Delivery c~~mponent for the preferred
embodiment of
the invention.
While the above is a complete description of the preferred embodiment of the
present
invention it will be well known in the art that it is possible to use various
alternatives,
modifications, and equivalents. Therefore, the scope of the present invention
should be
determined with reference to the claims with their full scope of equivalents.
CA9-97-034 58
