**CDM MEMORANDUM**

To: CDM Workgroup

From: Ken Howard

Subject: CDM Protocol for CDMNET

Date: August 9, 2000

The CDM message protocol has been revised to accommodate simplified
subs. Also, many changes in the ADL protocol have been incorporated to
reflect past changes to this code.

CDM Protocol for CDMNET

# 1 Introduction

This document describes the protocol for using TCP/IP communications for
CDM data exchange between airline applications and CDM/ETMS hub
applications. The combined set of networks that provide airlines with
TCP/IP connectivity for CDM are referred to as CDMNET. There are
currently three types of application data exchange that occurs over
CDMNET:

1.  The distribution of ADL data files from the ETMS hub site to the
    airlines, primarily for viewing via FSM.

2.  The feed of airline flight data messages (FC, FM, FX) from airline
    flight data systems to the ETMS hub site.

3.  The exchange of GDP data (slot lists and substitution messages) that
    is performed under the heading of "Simplified Subs".

This document describes the protocol for each item above.

## 1.1 Overview

Using the CDMNET, inter-process communications between processes at the
various sites (airline, FAA, Volpe) will be performed in "sessions"
through dedicated TCP/IP sockets. In each session, the application
running at the user site is considered the client and the application
running at the hub is considered the server. The general approach is as
follows:

1.  A client process opens a socket connection to a server process using
    a well-known IP address and starts a session.

2.  Data is exchanged between the client and server indefinitely.

3.  Either the client or server terminates the session and closes the
    connection.

For flight data messages, the session is opened and closed simply by
opening and closing the socket connection. In other words, the client
just opens a socket and begins sending messages. Each message contains
client information that is used by the server to validate the
connection.

For ADL distribution, additional messages are used to manage sessions.
The client sends an initial connect message identifying itself; the
server uses this information to validate the connection. Additional
messages are used to notify client/server of a shutdown.

For Simplified Subs, the session will operate similarly to flight data
messages with one exception. With simplified subs, the first application
message may be from the server to the client. That means that the client
must send some message after connecting to identify itself. The connect
message from the ADL session will be used for this purpose.

Message formats consist of a 24-byte header (binary) optionally followed
by a variable number of bytes containing application specific data. Some
of the fields in the header are now obsolete, but have been preserved
for backwards compatibility.

## 1.2 Scope

This document covers the protocol for managing socket connections and
transferring data. It does not provide descriptions of the
application-level data. For example, the flight data feed portion
describes how to open a connection, and how to fill the message headers.
However, it does not describe how to format an FC, FM, or FZ message and
under what circumstances to send them. The application-level data can be
found in the following documents:

### ADL Feed

1.  *ADL Format Version 3* dated March 10, 2000

### Flight Data Feed {#flight-data-feed .unnumbered}

2.  *CDM Message Formats Version 1.3* dated December 20, 1996

### Simplified Subs {#simplified-subs .unnumbered}

3.  *Requirements for Simplified Subs rev 6* dated April 19, 2000

## 1.3 Organization {#organization .unnumbered}

This document is organized into three main sections:

-   **1 Introduction** This section.

-   **2 ADL Protocol** -- Describes the protocol used to request and
    receive ADL files.

-   **3 Flight Data Protocols** - Describes the protocol used to
    exchange the CDM flight data messages between the airlines and the
    CDM hub site (Volpe).

-   **4 Simplified Subs Protocol** -- Describes the protocol used to
    send and receive simplified subs messages.

-   **5 Message Specifications** - Defines the detailed formats of the
    messages presented in the previous sessions.

# 2 ADL Protocol {#adl-protocol .unnumbered}

This section describes the protocol used between client and server to
exchange ADL data.

## 2.1 ADL Session Protocol {#adl-session-protocol .unnumbered}

### 2.1.1 Overview {#overview-1 .unnumbered}

An ADL client/server session will be established and maintained through
the following sequence of events:

1.  A client opens a socket connection to a server using a well-known IP
    address.

2.  The client sends a connect message.

3.  The server validates the connect message, and if valid, sends an
    accept message to the client.

4.  Various messages are sent between client and server to exchange
    data.

5.  When a client wants to terminate a session, it sends a disconnect
    message to the server and disconnects from the socket.

6.  When a server wants to terminate a session, it sends a shutdown
    message to the client(s) and closes the socket(s).

    The messages used to initiate and terminate sessions will be
    referred to as "session messages".

### 2.1.2 Security {#security .unnumbered}

At the transport level, security will be provided by firewalls. It is
the responsibility of each user to establish whatever firewall they feel
will ensure their security. All data exchange between clients and
servers will be through a socket connection; no FTP or telnet access is
required.

At the application level, Volpe will maintain a table of valid IP client
addresses, client names, and client tags. The server at Volpe will
validate the client data whenever a client connects, and will reject any
connection that is not authorized. The client data is validated when a
connect message is sent, and whenever included on a data message (e.g.,
a flight data message). At any time if the client data is invalid, the
server will immediately terminate the session and close the socket. As
long as the client data is valid, messages will be allowed to flow
freely between the client and server and will be processed as long as
the messages are of recognized type and format.

### 2.1.3 Session Messages {#session-messages .unnumbered}

\[1\] M_ATMS_CONNECT - \[CLIENT to SERVER\] This is the first message
sent to start a session. It identifies the source of the message (e.g.,
Metron, AAL).

\[2\] M_ATMS_ACCEPT - \[SERVER to CLIENT\] Notifies the client that the
connection has been accepted. The session is now started.

\[3\] M_ATMS_REJECT - \[SERVER to CLIENT\] Notifies the client that the
connection has been rejected. Includes an error code.

\[4\] M_DISCONNECT - \[CLIENT to SERVER\] Tells the server that the
client process is shutting down and going away (i.e., ends the session).

\[5\] M_SHUTDOWN - \[SERVER to CLIENT\] Tells the client that server
process is shutting down, and gives the client the opportunity to shut
down gracefully (i.e., ends the session).

\[6\] M_STATS (not used) - \[to SERVER or CLIENT\] Requests run-time
statistics from the process; used to monitor and debug the system.
Optionally includes a "stats" sub-type.

\[7\] M_STATS_REPLY (not used) - \[from SERVER or CLIENT\] Sends
run-time statistics back to the requester.

### 2.1.4 Error Handling {#error-handling .unnumbered}

#### Loss of Client {#loss-of-client .unnumbered}

A server will consider any of the following events to be a "loss of
client":

-   notification that the socket connection to the client has been lost

-   notification that a message to the client is undeliverable

-   a excessive backup in the sending queue (see below)

-   receipt of a disconnect message

    When a server detects a loss of client it shall close the connection
    and remove the client from the registration tables.

#### Loss of Server {#loss-of-server .unnumbered}

A client will consider any of the following to be a "loss of server":

-   notification that the socket connection to the server has been lost

-   notification that a message to the server is undeliverable

-   receipt of a shutdown message

    When a client detects a loss of server it shall close the
    connection, notify the user (as appropriate), and try to
    re-establish the connection.

    In either case when a connection is closed the session will be
    considered to be ended.

#### Queuing {#queuing .unnumbered}

The server will queue ADL files intended for a client in the event that
the socket is not being read as fast as it is being written. A maximum
queue of 50 ADL files will be allowed. Once the maximum is exceeded, the
server will consider the client to be inaccessible and will terminate
the session.

#### Redundancy {#redundancy .unnumbered}

Multiple servers will be provided for obtaining ADL files. A client
should have the capability to attempt connections to multiple IP
addresses. Only one IP address will be active at any given time.

## 2.2 ADL Application Protocol {#adl-application-protocol .unnumbered}

### 2.2.1 Overview {#overview-2 .unnumbered}

A client running at a user site will get data from the server in the
following manner:

1.  A client first establishes a session using the full protocol
    described in section 2.

    When a client wants data for an airport it sends a register message
    to the server.

    The server registers that client for that airport and starts
    periodically shipping data files to the client.

    When a client no longer wants data for that airport, it sends an
    un-register message.

    The server stops sending files to that client for that airport.

    When a client shuts down it ends the session by sending a disconnect
    message to server prior to closing the socket connection.

    In the event that server shuts down, it closes its sessions by
    sending shutdown messages to all clients prior to closing the socket
    connections.

### 2.2.2 File Transfer {#file-transfer .unnumbered}

ADL data files will be transmitted to CDMNET sites in the following
manner:

8.  The server will compress the file using GZIP.

    The server will send the file to the client through the socket in
    1000 byte records until the end of file is reached.

    The client will write the data to a file.

    When the data transmission is complete, the server will notify the
    client through the socket that the file is ready.

    The client will decompress and read the file.

### 2.2.3 ADL Messages {#adl-messages .unnumbered}

In addition to the general session messages described in section 2, the
ADL protocol will use the following messages:

\[201\] M_REGISTER - \[client to server\] Requests data for an airport.
Includes location to place the files.

\[202\] M_REGISTER_ACK - \[server to client\] Indicates whether the
registration was accepted. Includes an error code if rejected.

\[203\] M_UN_REGISTER - \[client to server\] Tells server to stop
sending data for the named airport.

\[204\] M_UN_REGISTER_ACK - \[server to client\] Indicates whether the
un-registration was accepted. Includes an error code if rejected.

\[205\] M_START_FILE - \[server to client\] Notifies client that a new
ADL file is being downloaded through the socket and provides the
filename of the ADL. This message can be thought of as a file open.
Always contains the sequence number 1.

\[206\] M_ADL_DATA - \[server to client\] Provides a packet of data from
the ADL file. This message can be thought of as a file write. Includes
sequence numbers 2-N.

\[207\] M_END_FILE - \[server to client\] Notifies client that the
download of an ADL file is complete. This message can be thought of as a
file close. Includes the sequence number N+1.

\[208\] M_ADL_ERROR (not used) - \[client to server\] Notifies server
that a the download of an ADL file has failed. Includes the pathname of
the file.

\[209\] M_NEW_ADL - \[server to client\] Notifies client that a new ADL
file has been transmitted and provides the pathname of the file.

# 3. Flight Data Protocol {#flight-data-protocol .unnumbered}

This section describes the protocol used to exchange flight data
messages (FC, FM, FX) between client and server.

## 3.1 Flight Data Session Protocol {#flight-data-session-protocol .unnumbered}

### 3.1.1 Overview {#overview-3 .unnumbered}

A client/server session will be established and maintained through the
following sequence of events:

13. A client opens a TCP/IP socket connection to the server using a
    well-known address.

    The server validates the IP address of the connecting client. If
    invalid, the server closes the connection. If valid, the session for
    that client has started.

    Flight data messages are sent from client to server. Each message
    includes client name and tag, as well as the body of the message
    text.

    The server validates the client name and tag when first flight data
    message is received. If there is any problem, the server closes the
    connection. Otherwise this and all subsequent messages are accepted.

    Optionally, replies are sent from server to the client IP or ARINC
    address.

    When a client wants to terminate a session, it closes the socket
    connection.

    When a server wants to terminate a session, it closes the socket
    connection.

    Additional notes about flight data sessions:

    An airline may open and close sessions whenever it wishes; that is,
    there is not a requirement to keep an open connection with the
    server at all times, although that is allowed.

    An airline may have multiple open connections if so desired.
    Multiple client tags must be assigned for this purpose.

    A client tag may only be associated with one active connection at a
    time.

### 3.1.2 Security {#security-1 .unnumbered}

Security will be provided at the application level. Volpe will maintain
a table of valid IP client addresses. The server at Volpe will validate
the connecting IP address whenever a client connects, and will reject
any connection that is not authorized. Once a session is established,
messages will be checked for a valid client tag. If any message is
received with an invalid client tag for the sending IP address, the
connection will be terminated.

Additionally, the server will maintain a table of which airline codes
each client is allowed to send data for, and reject any messages that
refer to unauthorized flights. (NOTE: This is the current method of
authorizing data on the ARINC network.)

To support the security checking, each airline is required to provide
the following parameters:

-   IP address where their flight data messages will originate from.

-   Three-letter code of sender (e.g. AAL)

-   Additional three-letter codes of flights which the sender is
    authorized to modify (e.g., EGF)

    Volpe will provide a client tag for each authorized user connection.

### 3.1.3 Error Handling {#error-handling-1 .unnumbered}

#### Loss of Client {#loss-of-client-1 .unnumbered}

A server will consider any of the following events to be a "loss of
client":

-   notification that the socket connection to the client has been lost

-   notification that a message to the client is undeliverable

    When a server detects a loss of client it shall close the connection
    and remove the client from the registration tables.

#### Loss of Server {#loss-of-server-1 .unnumbered}

A client will consider any of the following to be a "loss of server":

-   notification that the socket connection to the server has been lost

-   notification that a message to the server is undeliverable

    When a client detects a loss of server it shall close the
    connection, notify the user (as appropriate), and try to
    re-establish the connection.

    In either case when a connection is closed the session has ended.

#### Message Loss {#message-loss .unnumbered}

Sequence numbers will be used to track that all flight data messages and
replies are being received properly. The client will assign a sequence
to each message when it is sent. The server will return the sequence
number on the reply for that message (optional). The server will track
the sequence numbers and detect any out of sequence occurrences.
Sequence errors will be logged and examined periodically to assess the
performance of the communications. No recovery processing for individual
messages will be implemented at this time.

#### Redundancy {#redundancy-1 .unnumbered}

Volpe will provide multiple servers for flight data. The client should
be developed so that it will attempt to connect to different IP
addresses. In the case that one connect attempt fails, the client should
go on to try the next address. Only one connection should be active from
any given client at a time.

## 3.2 Flight Data Application Protocol {#flight-data-application-protocol .unnumbered}

### 3.2.1 Overview {#overview-4 .unnumbered}

Once the session is established, the client sends flight data messages
and the server optionally sends replies. The airline has control over
how their messages are acknowledged. The airline has two choices:

-   Whether a reply is sent for every message, or only when errors occur
    in processing the message.

-   Whether the replies go back to the sending address or to an
    alternate ARINC address.

    These choices are controlled by the airlines through the use of
    keywords in the packet header record, as in the current ARINC-only
    protocol.

    The hub site will handle generate replies in the following manner by
    default.

-   A reply will be sent for every message.

-   The reply will be sent to the address from which the message was
    received (i.e., either a IP CDMNET address or an ARINC address).

    If an airline does NOT wish to get an unconditional reply for a
    message, it will indicate so by using the NOACK keyword in the
    packet header line. In this case replies will only be sent when an
    error is encountered in processing the message.

    If an airline does NOT want to get replies at its sending address,
    it will indicate an alternate address in the message packet header.
    NOTE: The alternate address can only be an ARINC address!

    The use of the NOACK and ARINC address keywords is already accounted
    for in the CDM message format. This protocol simply preserves what
    is already being used.

    NOTE: There is no way to specify an alternate IP address for
    replies.

### 3.2.2 Messages {#messages .unnumbered}

The following two message types will be used to exchange flight data
messages.

\[101\] M_FLIGHT_DATA_PACKET - \[client to server\] Sends flight data
from airline to ETMS hub.

\[102\] M_FLIGHT_DATA_REPLY - \[server to client, optional\] Sends an
airline the result of the processing of a flight data packet.

The flight data messages are sent as a buffer attached to the
M_FLIGHT_DATA_PACKET header. The format of the messages themselves is
described separately in the *CDM Message Formats* document

# 4. Simplified Subs Protocol {#simplified-subs-protocol .unnumbered}

This section describes the protocol used to exchange simplified subs
messages (slot lists and SS packets) between client and server.

## 4.1 Simplified Subs Session Protocol {#simplified-subs-session-protocol .unnumbered}

### 4.1.1 Overview {#overview-5 .unnumbered}

A client/server session will be established and maintained through the
following sequence of events:

1.  A client opens a TCP/IP socket connection to the server using a
    well-known address.

    The server validates the IP address of the connecting client. If
    invalid, the server closes the connection. If valid, the session for
    that client has started.

    The client sends a connect message which identifies the client by
    providing a client name and tag. The client name must be configured
    as a simplified sub (SS) client by ETMS.

    When a GDP is issued, the server sends the slot list out to any SS
    clients currently connected.

    Once a GDP is issued, SS packets may be sent from client to server.
    Each message includes the body of the message text in the buffer.

    Replies are sent from server to the client over the same socket that
    the message was received on.

    At any time, the SS client can request information about the current
    GDPs. Replies are again sent back over the same socket.

    When the state of a GDP changes (substitutions turned off,
    substitutions turned on, GDP cancelled), a message is sent out to
    any currently connected SS clients.

    When an SS client wants to terminate a session, it closes the socket
    connection.

    When the server wants to terminate a session, it closes the socket
    connection.

    Additional notes about simplified subs sessions:

    The simplified subs will use the same port as the flight data
    message feed. Therefore, an SS client can send regular flight data
    messages as part of the same session as simplified subs, if desired.

    An airline may have multiple SS clients connected if so desired.
    These may share the same name, but each concurrent client must have
    a unique client tag.

### 4.1.2 Security

Security will be provided at the application level. Volpe will maintain
a table of valid IP client addresses. The server at Volpe will validate
the connecting IP address whenever a client connects, and will reject
any connection that is not authorized. Once a session is established,
messages will be checked for a valid client tag. If any message is
received with an invalid client tag for the sending IP address, the
connection will be terminated.

Additionally, the server will maintain a table of which airline codes
each client is allowed to send data for, and reject any messages that
refer to unauthorized flights. (NOTE: This is the current method of
authorizing data on the ARINC network.)

To support the security checking, each airline is required to provide
the following parameters (this data is required for configuration
purposes and is not part of the real-time session data):

-   IP address from which their flight data messages will originate.

-   Three-letter code of sender (e.g. AAL)

-   Additional three-letter codes of flights which the sender is
    authorized to modify (e.g., EGF)

    Volpe will provide a client tag for each authorized user connection.

### 4.1.3 Error Handling {#error-handling-2 .unnumbered}

#### Loss of Client {#loss-of-client-2 .unnumbered}

A server will consider any of the following events to be a "loss of
client":

-   notification that the socket connection to the client has been lost

-   notification that a message to the client is undeliverable

    When a server detects a loss of client it shall close the connection
    and remove the client from the registration tables.

#### Loss of Server {#loss-of-server-2 .unnumbered}

A client will consider any of the following to be a "loss of server":

-   notification that the socket connection to the server has been lost

-   notification that a message to the server is undeliverable

    When a client detects a loss of server it shall close the
    connection, notify the user (as appropriate), and try to
    re-establish the connection.

    In either case when a connection is closed the session has ended.

#### Message Loss {#message-loss-1 .unnumbered}

Sequence numbers should be used to track that all data messages and
replies are being received properly. The client should assign a sequence
number to each message when it is sent. The server will return the
sequence number on the reply for that message (replies may be optional).
The server will track the sequence numbers and detect any out of
sequence occurrences. Sequence errors will be logged and examined
periodically to assess the performance of the communications. No
recovery processing for individual messages will be implemented at this
time.

#### Redundancy {#redundancy-2 .unnumbered}

Volpe will provide multiple servers for flight data. The client should
be developed so that it will attempt to connect to different IP
addresses. In the case that one connect attempt fails, the client should
go on to try the next address. Only one connection should be active from
any given client at a time.

## 4.2 Simplified Subs Application Protocol {#simplified-subs-application-protocol .unnumbered}

### 4.2.1 Overview {#overview-6 .unnumbered}

### 4.2.2 Messages {#messages-1 .unnumbered}

The simplified subs protocol will use the following messages:

\[1\] M_ATMS_CONNECT - \[CLIENT to SERVER\] This is the first message
sent to start a session. It identifies the source of the message (e.g.,
Metron, AAL).

\[101\] M_FLIGHT_DATA_PACKET - \[client to server\] Sends a simplified
sub message packet to the ETMS hub for processing.

\[102\] M_FLIGHT_DATA_REPLY - \[server to client\] Sent from ETMS hub to
client to indicate the result of the sub processing.

\[103\] M_SLOT_DATA - \[server to client\] Sends slot list data to an
airline client as part of a GDP (e.g., initial GDP, compression,
revision).

\[104\] M_GDP_REQ - \[client to server\] Sent from client to ETMS hub to
request a new slot list. (NOTE: Reply is an M_SLOT_DATA message.)

\[105\] M_GDP_REPLY - \[server to client\] Sent from ETMS to client with
the response to the corresponding request.

\[106\] M_GDP_MESSAGE - \[server to client\] Sent from ETMS to client
when a GDP is purged (cancelled), when subs are turned off, or when subs
are turned on.

The detailed application-level message contents (e.g., slot list format,
SS packet format) are described in the Simplified Subs Requirements
document. The following section provides mroe detail on the message
header format.

# 5. Message Specifications {#message-specifications .unnumbered}

Messages consist of a message header, followed by a message body. The
message header is fixed length (24 bytes), consisting of six 4-byte
integers. The last field of the header specifies the byte count of the
optional data buffer. A message contains the following fields:

1\) Message Type - Integer value of the message type. \[4-byte integer\]

2\) Message Source - Encoded source identifier assigned by Volpe. Not
used for flight data messages. \[4-byte integer\]

3\) Message Destination - Encoded destination identifier assigned by
Volpe. Not used for flight data messages. \[4-byte integer\]

4\) Client Tag - Used to identify one of a set of clients (e.g., if
there is more than one client running at a site). \[4-byte integer\]

5\) Short Data - 32 bits of message-specific data. Included with every
message. \[4-byte integer\]

6\) Message Length - Length of the data buffer (may be zero; maximum is
128 Kbytes). \[4-byte integer\]

7\) Data Buffer - An array of bytes that is \'Message Length\' bytes
long. It is only sent if the Length field in the header is non-zero.
Maximum size is 128 Kbytes. Format of the information in the buffer is
message-specific.

The remainder of this section describes the detailed contents for each
of the message types described above. Literal constants are shown in
square brackets; that is, if the filed is supposed to contain the
integer value 1, it is shown is \[1\].

\[1\] M_ATMS_CONNECT

This message is used to tell a server at the ATMS hub site that a new
client process is coming on-line. The message identifies where the
client is running and includes an encrypted password. The server
validates the password and the request. If it is valid, the session
starts. The server notifies the client whether the connection was
accepted or not. If there is more than one client at this site, the
client tag field must contain different invocation numbers for each
client.

The detailed field contents are as follows:

1\) Message Type - M_ATMS_CONNECT \[1\]

2\) Message Source - encoded source identifier \[103\] for FSM; \[0\]
for flight data or simplified subs client\]

3\) Message Destination - encoded destination identifier \[1 or 0\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - \[0\]

6\) Message Length - \[0\]

7\) Data Buffer - N/A

\[2\] M_ATMS_ACCEPT

This message from the server tells the client that the socket connection
has been set up correctly. The short data field should be zero, and
there is no message body.

The detailed field contents are as follows:

1\) Message Type - M_ATMS_ACCEPT \[2\]

2\) Message Source - encoded source identifier \[1\]

3\) Message Destination - encoded destination identifier \[103\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - \[0\]

6\) Message Length - \[0\]

7\) Data Buffer - N/A

\[3\] M_ATMS_REJECT

This message from the server tells the client that the connection has
not been accepted. The short data field contains an error code
explaining the cause of the failure. I have started a list of error
codes, but we probably will come up with more along the way.

The detailed field contents are as follows:

1\) Message Type - M_ATMS_REJECT \[3\]

2\) Message Source - encoded source identifier \[1\]

3\) Message Destination - encoded destination identifier \[103\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - error code (see following list)

6\) Message Length - \[0\]

7\) Data Buffer - N/A

Error codes are as follows:

\[1\] - UNKNOWN MESSAGE SOURCE

\[2\] - INVALID PASSWORD

\[3\] - SERVER PROCESSING CURRENTLY NOT AVAILABLE

\[4\] - CLIENT WITH SAME INVOCATION NUMBER ALREADY RUNNING

\[4\] M_DISCONNECT

This message is sent from the client to the server to indicate that the
client process is shutting down. The short data field is zero and there
is no message body.

The detailed field contents are as follows:

1\) Message Type - M_DISCONNECT \[4\]

2\) Message Source - encoded source identifier \[103\]

3\) Message Destination - encoded destination identifier \[1\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - \[0\]

6\) Message Length - \[0\]

7\) Data Buffer - N/A

\[5\] M_SHUTDOWN

This message is sent from a server to a client to indicate that the
server process is shutting down. The short data field is zero and there
is no message body. This gives the client the chance to shut down
gracefully.

The detailed field contents are as follows:

1\) Message Type - M_SHUTDOWN \[5\]

2\) Message Source - encoded source identifier \[1\]

3\) Message Destination - encoded destination identifier \[103\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - \[0\]

6\) Message Length - \[0\]

7\) Data Buffer - N/A

\[6\] M_STATS

This message is sent from the server to a client to request information
pertaining to the execution and state of the client. The short data
filed may contain an optional stats type; if zero, defaults statistics
are provided. This message (along with the reply) makes it possible for
developers and system support personnel at Volpe to debug and monitor
the performance of the entire system.

The detailed field contents are as follows:

1\) Message Type - M_STATS \[6\]

2\) Message Source - encoded source identifier \[1\]

3\) Message Destination - encoded destination identifier \[103\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - stats type

6\) Message Length - \[0\]

7\) Data Buffer - N/A

\[7\] M_STATS_REPLY

This message is sent from a client to the server to respond to a stats
request (see previous message type). The information required varies by
client. The information will be in formatted ASCII strings, which are
placed in the data buffer.

NOTE: The information required in a stats reply is defined in Appendix
A.

The detailed field contents are as follows:

1\) Message Type - M_STATS_REPLY \[7\]

2\) Message Source - encoded source identifier \[103\]

3\) Message Destination - encoded destination identifier \[1\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - \[0\]

6\) Message Length - total number of bytes in the data buffer

7\) Data Buffer - formatted reply to the stats request

\[101\] M_FLIGHT_DATA_PACKET

This message from a client to the server sends flight data message or
simplified subs messages from the airline to the ATMS hub. The data
buffer contains the packet formatted as it currently is being sent
through ARINC; that is, packet header followed by a variable number of
messages terminated by line feeds. The short data field contains a
sequence number, which is simply an integer incremented by one for each
packet sent; the range of the sequence numbers is 1 to 9999.

The detailed field contents are as follows:

1\) Message Type - M_FLIGHT_DATA_PACKET \[101\]

2\) Message Source - \[0\]

3\) Message Destination - \[0\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - sequence number (1 to 9999)

6\) Message Length - total number of bytes in the data buffer

7\) Data Buffer - a message packet containing a header line and a
variable number of messages as defined in the simplified subs
requirements document

\[102\] M_FLIGHT_DATA_REPLY

This message from the server to a client sends the replies to the flight
data packets or simplified subs packets from the ATMS hub to the
airline. The data buffer contains the same reply that is currently being
sent through ARINC; that is, an acknowledgment line followed by a
variable number of error messages. The same options will exist: NOACK if
no "good" acknowledgment is desired and an optional ARINC address for
errors. (The FDP server will always send errors back to the FDS client
through the socket, but will optionally also send error messages to the
ARINC address if provided.) Packet components are not terminated by line
feeds, as in the ARINC protocol, but sent as separate strings in the
data buffer. The short data field contains the sequence number from the
flight data message to which the server is replying.

The detailed field contents are as follows:

1\) Message Type - M_FLIGHT_DATA_REPLY \[102\]

2\) Message Source - \[0\]

3\) Message Destination - \[0\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - sequence number (from flight data message)

6\) Message Length - total number of bytes in the data buffer

7\) Data Buffer - a message packet containing an acknowledgment and a
variable number of error messages as defined in the simplified subs
requirements document

\[103\] M_SLOT_DATA

This message from the server to the client sends slot lists (as part of
a GDP) from the ATMS hub to the airline. The data buffer contains the
slot list formatted as a stream of ASCII as specified in the simplified
subs requirements documents. The short data field contains a sequence
number, which is simply an integer incremented by one for each packet
sent; the range of the sequence numbers is 1 to 9999.

The detailed field contents are as follows:

1\) Message Type - M_SLOT_DATA \[103\]

2\) Message Source - \[0\]

3\) Message Destination - \[0\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - if in response to an M_LOST_DATA_REQ, the sequence
number from the request message; otherwise \[0\]

6\) Message Length - total number of bytes in the data buffer

7\) Data Buffer - a slot list formatted according to the simplified subs
requirements document

\[104\] M_GDP_REQ

This message from the client to the server sends slot list to the ATMS
hub. The data buffer contains the slot list request formatted as a
stream of ASCII as specified in the simplified subs requirements
documents. The short data field contains a sequence number, which is
simply an integer incremented by one for each packet sent; the range of
the sequence numbers is 1 to 9999.

The detailed field contents are as follows:

1\) Message Type - M_SLOT_DATA_REQ \[104\]

2\) Message Source - \[0\]

3\) Message Destination - \[0\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - sequence number (1 to 9999)

6\) Message Length - total number of bytes in the data buffer

7\) Data Buffer - a slot list request formatted according to the
simplified subs requirements document

\[105\] M_GDP_REPLY

This message from the server to the client sends the response to a GDP
request. The data buffer contains the message formatted as a stream of
ASCII as specified in the simplified subs requirements documents.

The detailed field contents are as follows:

1\) Message Type - M_GDP_REPLY \[105\]

2\) Message Source - \[0\]

3\) Message Destination - \[0\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - sequence number from M_GDP_REQ message

6\) Message Length - total number of bytes in the data buffer

7\) Data Buffer - a GDP message formatted according to the simplified
subs requirements document

\[106\] M_GDP_MESSAGE

This message from the server to the client sends GDP messages from the
ETMS hub to the airline. The data buffer contains the message formatted
as a stream of ASCII as specified in the simplified subs requirements
documents.

The detailed field contents are as follows:

1\) Message Type - M_GDP_MESSAGE \[106\]

2\) Message Source - \[0\]

3\) Message Destination - \[0\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - \[0\]

6\) Message Length - total number of bytes in the data buffer

7\) Data Buffer - a GDP message formatted according to the simplified
subs requirements document

\[201\] M_REGISTER

This message from the server client tells server that this server wants
data for a particular airport. The short data field tells the server
what type of site the client is (CDMNET or ETMS). The message body
should contain the name of the airport and the pathname where the file
will go. For ETMS sites, two pathnames will be sent: the pathname that
the server should use to FTP the file to the user site, and the pathname
that the server will use to access the file. The server will construct
full pathnames for the files. For CDMNET sites, server will send this
pathname to client in the M_START_ADL message.

The detailed field contents are as follows:

1\) Message Type - M_REGISTER \[201\]

2\) Message Source - encoded source identifier \[103\]

3\) Message Destination - encoded destination identifier \[1\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - 0 for CDMNET; 1 for ETMS

6\) Message Length - total number of bytes in data buffer

7\) Data Buffer - airport name, client pathname, and ETMS pathname (ETMS
sites only); fields are space delimited

\[202\] M_REGISTER_ACK

This message from the server to the client client tells client whether
the registration was accepted or not. The short data field is 0 if the
registration was accepted, or contains an error code is the registration
was not accepted. The data buffer contains the name of the airport for
which the registration was requested.

The detailed field contents are as follows:

1\) Message Type - M_REGISTER_ACK \[202\]

2\) Message Source - encoded source identifier \[1\]

3\) Message Destination - encoded destination identifier \[103\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - 0 if OK; error code if rejected

6\) Message Length - total number of bytes in data buffer

7\) Data Buffer - airport name

Error codes are as follows:

1 - UNKNOWN AIRPORT

2 - AIRPORT ALREADY REGISTERED

3 - MAXIMUM NUMBER OF AIRPORTS EXCEEDED

\[203\] M_UN_REGISTER

This message from the client client tells server to stop collecting data
at a particular airport for this client. If this is the last client
attached to that airport, then the ADL Data Distributor may stop
collecting data completely for that airport. The short data field should
be zero. The message body should contain the airport name, or the
keyword \"ALL\". If \"ALL\" is specified, then the ADL Data Distributor
should stop collecting data for all airports which have been previously
registered by this client.

If a client client is shutting down, it should send an un-register for
all airports currently being collected prior to sending a M_DISCONNECT
message.

The detailed field contents are as follows:

1\) Message Type - M_UN_REGISTER \[203\]

2\) Message Source - encoded source identifier \[103\]

3\) Message Destination - encoded destination identifier \[1\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - 0

6\) Message Length - total number of bytes in data buffer

7\) Data Buffer - airport name or "ALL"

\[204\] M_UN_REGISTER_ACK

This message from the server to the client client tells client whether
the un-registration was accepted or not. The short data field is 0 if
the un-registration was accepted, or contains an error code is the
un-registration was not accepted. The data buffer contains the name of
the airport for which the un-registration was requested.

The detailed field contents are as follows:

1\) Message Type - M_UN_REGISTER_ACK \[204\]

2\) Message Source - encoded source identifier \[1\]

3\) Message Destination - encoded destination identifier \[103\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - 0 if OK; error code if rejected

6\) Message Length - total number of bytes in data buffer

7\) Data Buffer - airport name

Error codes are as follows:

1 - AIRPORT NOT REGISTERED

2 - NO AIRPORTS REGISTERED

\[205\] M_START_ADL

This message from the server to client tells client that server is
beginning to send a new ADL file. The data buffer contains the pathname
of the file. client opens the file and waits for data packets, which it
will write to the file. client also starts a sequence counter for the
file packets. The short data field contains the first sequence number
which is always one.

The detailed field contents are as follows:

1\) Message Type - M_START_ADL \[205\]

2\) Message Source - encoded source identifier \[1\]

3\) Message Destination - encoded destination identifier \[103\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - 1

6\) Message Length - total number of bytes in data buffer

7\) Data Buffer - pathname of file

\[206\] M_ADL_DATA

This message is used to send a piece of an ADL file from server to
client. The data buffer contains the data. client will extract the data
from the buffer and write to the file that is already open. The short
data field contains the packet sequence number. client checks the
sequence number and notifies server if there is an error.

The detailed field contents are as follows:

1\) Message Type - M_ADL_DATA \[206\]

2\) Message Source - encoded source identifier \[1\]

3\) Message Destination - encoded destination identifier \[103\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - sequence number

6\) Message Length - total number of bytes in data buffer

7\) Data Buffer - data

\[207\] M_END_ADL

This message from the server to client tells client that the ADL file is
complete. The data buffer contains the pathname of the file. The short
data field contains the last sequence number. client checks it and if
all is well, closes the file.

The detailed field contents are as follows:

1\) Message Type - M_END_ADL \[207\]

2\) Message Source - encoded source identifier \[1\]

3\) Message Destination - encoded destination identifier \[103\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - sequence number

6\) Message Length - total number of bytes in data buffer

7\) Data Buffer - pathname of file

\[208\] M_ADL_ERROR

This message from client to server tells server that there was an error
in the file transmission; that is, packet was missing or received out of
sequence. The short data field should be zero. There is no data buffer.
This message tells server to abort the transmission.

The detailed field contents are as follows:

1\) Message Type - M_ADL_ERROR \[208\]

2\) Message Source - encoded source identifier \[103\]

3\) Message Destination - encoded destination identifier \[1\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - 0

6\) Message Length - 0

7\) Data Buffer - N/A

\[209\] M_NEW_ADL

This message from server to the client client is sent after an ADL file
has been successfully transferred to the client site. The message is
sent whether the file is FTP'd or sent through the socket using the
above messages. The short data field is zero. The message body contains
the full pathname of the new ADL.

The detailed field contents are as follows:

1\) Message Type - M_NEW_ADL \[209\]

2\) Message Source - encoded source identifier \[1\]

3\) Message Destination - encoded destination identifier \[103\]

4\) Client Tag - client identification number assigned by Volpe

5\) Short Data - 0

6\) Message Length - total number of bytes in data buffer

7\) Data Buffer - pathname of file

# Appendix A - Stats Information {#appendix-a---stats-information .AppHead-1 .unnumbered}

The stats messages are currently used in ETMS to allow system developers
and support personnel to better debug and monitor the wide-area system.
It has proven enormously valuable. The information allows one to quickly
find information such as:

-   has a process restarted recently?

-   are replies taking too long?

-   is there a logical disconnect between a client and server (e.g.,
    client is waiting for ADL but server is not planning to send it)?

The statistics required for each client or server vary by the
application, and are defined below. Anyone developing a client should
adhere closely to the format defined below!

The data collector should provide the following information in a stats
reply:

Line 1 - Software version number

Line 2 - Site name of the client

Line 3 - Elapsed time since execution

Line 4 - Current time in GMT

Line 5 - blank

Line 6 - Number of airports monitored

Line 7.N - Last ADL file and time received for each airport.

A sample output follows:

client Version: 3.01

My Site: 0101

Elapsed: 5 days 12 hours 46 minutes

Current time: 19:40:17

Monitoring 2 airports

BOS last update: bos\_\_.lcdm.22193023.01 recd at: 19:31:30

PIT last update: pit\_\_.lcdm.22193145.01 recd at: 19:32:30