Somos: 6. TCP/IP Application Messages

6.1      Transport Header Message Types Supported

The following TCP/IP Message Types must be supported:

 

Table 6-1. Application Messages

Message Code	Transport Header Message Type	Description
01	Good Day	used to request the Identification of peer NodeName, or to test if the session is still alive.
05	Good Night	used to notify the peer that the sending process is shutting down immediately.
06	Good Bye, Disconnect Request	used to invite the peer to disconnect the current session. Graceful disconnect.
09	Error	used to indicate a protocol error.
19	Data (UPL Header/UPL Message Data)	used to facilitate the transfer of administrative messages and operational data. This message contains the application layer UPL header with the application message UPL data.

 

R6-1          

 

[5] Each application message sent to/from the SMS/800 and SCP shall include a Transport message header consisting of the above information

 

6.1.1       Connect / Disconnect Sequence Example (Figure 3-1)

 

This Figure does not depict the Symmetric Peer-to-Peer relationship that TCP/IP supports; however, it does illustrate which side usually initiates the message type.                                                       

                                                         

6.1.2       Connect/Disconnect Dialogue

TCP connections are viewed as full duplex (i.e., two independent data paths, one in each direction).Once a TCP connection is requested and accepted, both sides are in “data transfer phase”. Both sides can send both data and Good Day messages.

 

The SMS/800 processes on each DCMServer will listen for socket connection request from the SCP. Once the connection is established, the SCP sends the Good Day message with a zero-length desNodeName. The SMS/800 responds with a Good Day message with both srcNodeName and desNodeName filled in.

 

If either side wants to terminate the socket connection, the Good Bye or Good Night mes- sage can be used. When a system (SMS/800 or SCP) receives a Good Bye message, it should complete the sending of any message in progress, then close down the socket con- nection. If either side needs to shutdown the socket connection immediately, a Good Night message shall be sent.

 

6.1.2.1       Good Day Message (mcommgdy)

 

Good day messages can be used by either side if verification of the other side’s identity is needed. Good day messages can also be used to test if the session is still alive. Whenever the TCP connection between an SCP and SMS/800 is restored or whenever an SCP or SMS/800 is activated, it is recommended that at least one Good day message be exchanged; however, extensive use of this message is not advised.

 

The SCP application layer will send a Good Day message each time the TCP connection request is accepted by SMS/800. The initial Good Day message contains the application layer message header parameters with no application message data. This initial Good Day has a null destNodeName, and a response is required - it can be a Good Day message, or any message with both destNodeName and srcNodeName filled. The sender runs a timer for the null destNodeName message.

 

This message is to let the peer application know “who I am” and/or ask “who are you/are you there” This message can be sent anytime during a connected session. The following rules must be adhered to:

 

1. “who are you/are you there”-If the destNodeName is null (zero length), the receiving side MUST return a “mcommgdy” or any message with both the destNodeName and the srcNodeName filled. For a process accepting TCPconnection, it only knows the requester’s IP-address/TCP-port#. This message can be used to find out the Node Name of the peer.

 

2. “who am I”- If the destNodeName and srcNodeName contains a non-zero-length value, the receiving side MUST NOT respond with a mcommgdy”. This is done to avoid infinite good-day handshakes. Although any side may send a “mcommgdy” to the other side at anytime, it is recommended that the connect-requester send the “mcommgdy” immediately after the connection is accepted by the other side.

R6-2          

 

[6] The “mcommgdy” message must be supported to respond to the “mcommgdy” request, and it must adhere to the above-mentioned rules.

 

6.1.2.2       Good Night Messages (mcommgnt)

This message is used to notify the peer that the sending process is “shutting down”. It is usually followed by a transport layer disconnect (i.e., TCP DISCONNECT). Upon receipt of this message, the receiving process should close the connection. When the SCP or SMS/800 is deactivated for such activity as periodic maintenance, the terminating application should send the peer application a Good Night message. The Good Night message contains the application message header parameter with no application message data. The source and destination node name for the Good Night message will be non-null (a valid CLLITM code), with the source node name representing the receiving application.

 

R6-3           [7] The Good Night message (mcommgnt) shall be supported for process termination.

 

6.1.2.3       Good Bye, Disconnect Request (mcommbye)

This message is used to invite the peer to disconnect the current session. The message could be sent after the connection has been idle for a time designated by the idle timer, and the sender has nothing to send. Note, to disconnect after idle time is not a requirement, and is not encouraged.

 

After sending the next message boundary, the receiving side must disconnect the TCP session. This message is needed to prevent a process from sending a disconnect while the other side starts sending new messages (i.e., prevents lost messages). The sending process should receive, but not send, more messages. The Good Bye sender should send the newly arrived messages, if any, through a new connection. The Good Bye message contains the application message header parameter with no application message data.

 

R6-4          

 

[8] The “mcommbye” message shall be supported for graceful disconnection of the current session.

 

6.1.2.4       Data Message

The UPL Header/UPL message is used to facilitate the transfer of administrative messages and operational data, in both directions, between the SMS/800 and the SCPs in order to support the various operations functions performed by SCP applications. The administrative and operations data to be exchanged are defined in this section. This document provides detailed descriptions of the following types of UPL Header/UPL messages that are required to be supported by the SMS/800 and SCPs.

 

The UPL Header/UPL Message contains the application layer message header parameter with the application message data portion as defined therein.

 

R6-5           

 

[9] The “mUPL” message shall be supported to facilitate the transfer of administrative messages and operational data between the SCP and SMS/800.

 

6.1.2.5       Message Error Processing

 

An application message sent between the SMS/800 and SCP may fail for one of the following reasons:

• Bad Source
• Bad Destination
• Bad Version.

Any one of these errors will result in the application message not being delivered to its destination. If an application message cannot be delivered to its destination, the application message will fail and be discarded. When an application message fails, an error message may be returned to the originator of the message. The error message should consist of the application message header with the appropriate error code. No data is returned.

 

The selection of the appropriate error code for an error message should correspond to the following guidelines:

• If the SCP receives an application message with an invalid source node name, the error code should indicate “bad source” (error code: 1).
• If the SCP receives an application message with an invalid destination node name, the error code should indicate “bad destination” (error code: 2).
• I f the SCP receives an application message with an invalid version, the error code should indicate “bad version” (error code: 3).
• If the SCP receives an application message with an error not defined above, the error code should indicate “other” (error code: 9).

The SCP shall fail and discard any application message that cannot be processed.

 

R6-6          

 

[10] The SCP or SMS/800 may choose to send an error message to one another with the appropriate error code as described in the above guidelines if the SCP cannot process an application message.