TCIP Communications Profile Definition
Profile 1
Simple Socket Message Exchange Profile
June 15, 2009
Revision History
Date
Purpose
June 15, 2009
Initial Release
Comments
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.
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 socket open 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.
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.
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.
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.
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.