Transport component

The transport component of the DoIP specification is concerned with how commands (usually referred to as messages) are sent over the network to endpoint devices. The transport component consists of a transport protocol and a message format. An endpoint vendor is free to choose a protocol and format that suits the application, but it is advisable to choose one of the commonly used protocols described on this page to make sure that all clients can communicate with the endpoint. Because the definition file can describe multiple transports, it is possible to use a less well-known or proprietary protocol or format side-by-side a transport that uses a well-known protocol or format.

Transport protocols send messages (in a particular format) from device to device.

UDP is a datagram-based protocol that is lightweight and easy to use. UDP messages are sent and processed on a best-effort basis; this means that under high network load, some messages may get lost. Messages are not processed in a strict order. Nevertheless, because UDP messages are so small, they are great for non-essential messages that simply need to be sent and processed as fast as possible. Because UDP is datagram-based, it does not need a framing layer like SLIP. UDP over IPv4 as well as over IPv6 is supported, either with unicast addresses (i.e. IP address of a single machine) or multicast/broadcast.

TCP is a reliable, stream-based protocol that makes sure that every message sent actually arrives at the other end in the order in which they were sent. TCP does this by requiring 'acknowledging' each packet it sent; therefore, it uses more bandwidth and is not as fast and lightweight as UDP. Nevertheless, this is the protocol to use for messages that need to be sent in a reliable way. Because TCP is stream-based, it needs a framing protocol to separate messages. The most commonly used protocol with TCP is SLIP, which is very simple to implement. TCP works over both IPv4 and IPv6; because of its nature, TCP/IP only works with unicast connections.

Currently, the recommended message format is OSC (OpenSoundControl). It provides a very simple to implement and efficient format. Packets using the OSC format can contain OSC 'messages' as well as OSC 'bundles'. If an endpoint received a bundle, it should try to process the bundle as a single atomic command whenever possible (i.e. if a bundle is sent that contains the messages '/x 12' and '/y 30', the variables x and y should be changed simultaneously).