TCIP Communications Profile Definition

Profile 1

Simple Socket Message Exchange Profile

June 15, 2009

Revision History

Date / Purpose / Comments
June 15, 2009 / Initial Release

Background

The American Public Transportation Association (APTA) promulgates the Transit Communications Interface Profiles Standard (TCIP). TCIP provides standardized information exchanges among transit business systems and components, simplifying the integration of these systems and reducing the life cycle costs of these systems.

TCIP specifies numerous Extended Markup Language (XML)-based messages, but does not specify the communications protocols to be used to exchange these messages. TCIP Communications Profile Definitions such as this document provide a mechanism to specify and share communications protocol profiles to be used with TCIP messages to exchange data.

Simple Socket Message Exchange Profile Overview

The Simple Socket Message Exchange Profile (SSMEP) provides two mechanisms for exchanging TCIP messages: Mechanism 1 - Transport Control Protocol/Internet Protocol (TCP/IP) message exchanges (SSMEP-TCP), and

Mechanism 2 – Unnumbered Datagram Protocol/Internet Protocol (UDP/IP) message exchanges (SSMEP-UDP).

All SSMEP messages use the standard ASCII character set, one byte per character, no parity.

SSMEP-TCP is intended to be used with messages that are either too long to be sent in a single packet over a typical network, or which require reliable delivery, or both. SSMEP-TCP allows the sender of the message to verify that the destination host received the message, thus the sender can optionally retry a failed message later. SSMEP does not however verify that the destination host can process the message.

SSMEP-UDP is intended to be used with messages that are relatively short, and which do not require the network to provide reliable delivery. SSMEP-UDP does not report failed messages to the sender. The maximum allowable size of a UDP message varies from network to network.

SSMEP-TCP Profile Definition

SSMEP-TCP uses TCP as the transport layer protocol. TCP requires established connections between the communicating entities. To establish these connections the message receiver must have a listener socketopen on Port 62628. The message originator must know the IP address of the receiver, and must first send a socket connect request to the receiver's listener socket. The connect request originates from a socket in the range (62000-62620) selected by the originator. On some platforms the originator must first bind to the sending {local} socket before sending the connect request. Upon receipt of the connect request, the listener assigns a receive socket and connects the sending socket to this new receive socket Once both ends have successfully, connected communications can begin.

Note: On some platforms, the accept function implicitly creates the new receive socket, and connects the sending socket to the new receive socket. As a result, the receiver may not have visibility of the port number of the message receive socket.

The originator initiates communications by sending the ASCII.STX (value decimal 2) followed by the TCIP message in ASCII-encoded XML, followed by the ASCII.ETX (value decimal 3). The receiver detects that it has received a string of ASCII characters bounded by STX/ETX and sends an ASCII.ACK (value decimal 6) to indicate successful message receipt. The receiver waits for a small interval (e.g. 50 ms) and closes the connection. Upon receiving the ASCII.ACK, the originator closes the connection and declares message success.

If the receiver detects a message not bounded by an ASCII.STX/ASCII.ETX, the receiver discards the message, sends an ASCII.NAK to the sender, waits for a small interval, and closes the connection.

If the receiver receives a connection terminated indication from the network before receiving the ASCII.ETX, the receiver closes the socket, and discards any received information.

If the originator receives a connection terminated indication from the network prior to receiving an ASCII.ACK, the originator closes the socket and declares message failure.

If the originator receives an ASCII.NAK terminated indication from the receiver at any time, the originator closes the socket and declares message failure.

Upon declaring a message failure, the originator may optionally reschedule the message for another transmission attempt later. Application developers may design their applications to retry selected messages, but not others.

Note: Each SSMEP-TCP message requires a separate socket connection. Both the originator and the receiver must take down the connection when the message completes. It is not possible to establish a TCP connection and transmit multiple SSMEP-TCP messages over this interface.

SSMEP-UDP Profile Definition

SSMEP-UDP relies on the Unnumbered Datagram Protocol (UDP). UDP does not establish a connection between the sender and receiver prior to sending a message. If the receiver's IP address is unknown or unreachable, the message is lost. SSMEP-UDP messages must be small enough to fit within a single datagram packet. For most networks, it is safe to use SSMEP-UDP if the message length is less than 2000 characters.

To send a SSMEP-UDP message, the originator sends an ASCII string containing the entire message via a UDP socket. The message does not contain an ASCII.STX or an ASCII.ETX, as does the SSMEP-TCP message. The destination port address must be 62626. To receive SSMEP-UDP messages, the receiver opens a socket on port 62626 and interprets the contents of each received datagram as a discrete message.

There are no acknowledgements or retries using SSMEP-UDP.

Public Domain. The authors of this document have placed it in the public domain. You are free to copy this document for any purpose, as long as this notice remains attached. You may use the technical information within this document for any purpose, however, no warranty express or implied is granted. Any user of the technical information in this document does so at their own risk.