## page was renamed from Implementing_Client_Libraries = Implementing Client Libraries = NOTE: this page is just a collection of notes right now. Apologies. It is ''highly recommended'' that you read the [[ROS/Technical Overview|ROS Technical Overview]] first. It describes the general interaction of these APIs. At a minimum, a client library MUST: * implement the slave side of the [[ROS/Master_Slave_APIs|master/slave API]]. This involves managing an XML/RPC server, and issuing and responding to XML/RPC requests. * handle node-to-node transport negotiation and connection setup. A client library may only support a subset of the possible transport mechanisms, most likely [[ROS/TCPROS]] * handle transport-specific serialization and deserialization of messages. A client library SHOULD also: * parse command-line [[Remapping Arguments]]. A node that cannot do this will not be reconfigurable. * Subscribe to a simulated [[Clock]] * publish debugging messages to [[rosout]] * depend on the [[roslang]] package, which allows [[rosbuild]] and other tools to perform appropriate actions, such as msg- and srv-based code generation In addition, client libraries generally offer other features, such as: * object representation of message types * event loop for connection servicing * user callback invocation on message receipt == Message generation == Message generators commonly include two fields within the generated source code that is required during Topic/Service connection: * md5sum: this is computed by `roslib/scripts/gendeps --md5 msg-file` * Message definition: this is computed by `roslib/scripts/gendeps --cat msg-file` == Topic/Service Connection == Nodes usually spin up a TCP/IP server socket to receive both TCPROS-based Topic connections as well as all Service connections. The client will send the server a [[ROS/Connection_Header]], which can be used the route the inbound connection to the appropriate Topic/Service handler. For more information on these fields, see the [[ROS/Connection_Header]] documentation.