# LCM UDP Multicast Protocol Description Conceptually, an LCM message consists of a channel name and a payload. The channel name is a string identifying the semantic grouping of the message (e.g. "ODOMETRY"). The payload is a binary blob of data that corresponds to the contents of the message. Usually, the payload is the binary encoding of a marshalled LCM type. Each LCM message is transmitted using one or more UDP datagrams to a UDP multicast group and port. The address and port must have been agreed on beforehand -- LCM does not have an automatic discovery mechanism. To publish a message on a channel, an LCM client packages it up as described in the next two sections, and then transmits it directly to the multicast group. If the size of the LCM message is small, then it can be transmitted using a single UDP datagram. Otherwise, the message must be fragmented and transmitted in several parts. To subscribe to a messaging channel, an LCM client joins the multicast group and inspects each message transmitted to the multicast group, retaining messages of interest and discarding the remainder. ## Small messages A small message is defined as one where the LCM small message header, channel name, and the payload can fit into a single UDP datagram. Small messages have an upper size limit of 64 kB, after which they must be fragmented. The header for a small message is 8 bytes long and has the following form: 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | short_header_magic | +--------+--------+--------+--------+ | sequence_number | +--------+--------+--------+--------+ `short_header_magic` is an unsigned 32-bit integer with value `0x4c433032` `sequence_number` is a monotonically increasing (subject to integer wraparound) unsigned 32-bit number identifying the message. Both values are encoded in network byte order (Big-Endian). The header is followed by the null-terminated UTF-8 encoding of the channel name. The channel name is followed by the payload. ## Fragmented messages Large messages can be split into multiple fragments for transmission. Each fragment is transmitted in a single UDP datagram. The very first fragment consists of a header, followed by the channel name, followed by the first payload bytes. Subsequent fragments consist of a header followed by payload data. The header for each fragment is 20 bytes long and has the following form: 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | fragment_header_magic | +--------+--------+--------+--------+ | sequence_number | +--------+--------+--------+--------+ | payload_size | +--------+--------+--------+--------+ | fragment_offset | +--------+--------+--------+--------+ | fragment_number | n_fragments | +--------+--------+--------+--------+ `fragment_header_magic` is an unsigned 32-bit integer with value `0x4c433033` `sequence_number` is a monotonically increasing (subject to integer wraparound) unsigned 32-bit integer identifying the message. The same counter should be used for fragments and for short messages, and all fragments for a single LCM message should have the same sequence number. `payload_size` is an unsigned 32-bit integer indicating the length of the payload, in bytes. This does not include the length of the channel name. `fragment_offset` is an unsigned 32-bit integer indicating the payload byte offset of the fragment data within the message payload. `fragment_number` is an unsigned 16-bit integer with value 0 for the first fragment, 1 for the second, and so on. `n_fragments` is an unsigned 16-bit integer with value corresponding to the total number of fragments in the message. All header fields are packed in network byte order (Big-Endian). The null-terminated UTF-8 encoding of the channel immediately follows the header for the very first fragment of a message. This is followed by the first bytes of the message payload. In subsequent fragments, the payload data immediately follows the fragment header.