TCPROS

TCPROS is a transport layer for ROS Messages and Services. It uses standard TCP/IP sockets for transporting message data. Inbound connections are received via a TCP Server Socket with a header containing message data type and routing information. For more information about this header format, see Connection Header.

TODO: more information about wire protocol

TCPROS Header Fields

Inbound connections to a TCPROS Server Socket are routed by information contained within the header fields. If the header contains the 'topic' field, it will be routed as a connection to a ROS Publisher. If it contains a 'service' field, it will be routed as a connection to a ROS Service.

A TCPROS subscriber is required to send the following fields:

• message_definition: full text of message definition (output of gendeps --cat)
• callerid: name of subscriber
• topic: name of the topic the subscriber is connecting to
• md5sum: md5sum of the message type
• type: message type

A TCPROS publisher is required to reply with the following fields on a successful connection:

• md5sum: md5sum of the message type
• type: message type

A TCPROS service client is required to send the following fields:

• callerid: node name of service client
• service: name of the topic the subscriber is connecting to
• md5sum: md5sum of the message type
• type: service type

A TCPROS subscriber may optionally send the following fields:

• tcp_nodelay: if '1', indicates that the publisher should set TCP_NODELAY on the socket, if possible.

A TCPROS publisher may optionally send the following fields:

• callerid: name of publisher. Although this field is not required, it is highly recommended for debugging purposes.
• latching: if '1', indicates that the publisher is sending latched messages. The protocol for exchanging latched messages is identical, but subscribers may wish to take note of the latched status.

A TCPROS service client may optionally send the following fields:

• persistent: if '1', indicates that the service connection should be kept open for multiple service requests

A TCPROS Service is required to reply with the following fields on a successful connection:

• callerid: node name of Service

TCPROS has the following optional fields:

• error: human-readable error message if the connection is not successful

Service-specific

Services include an 'ok' byte in response to each service request message.

If the ok byte is true (1), it must be followed by the service response message.

If the ok byte is false (0), it must be followed by a serialized string representing the error message (same length + bytes format that ROS messages use for serializing strings, potentially the string can be empty which is the case if a service just returns false).