Hi
I have two questions;
1- What is the data overhead of DDS Connext v 5.2.0? I read a document about it (https://www.rti.com/hubfs/docs/DDS_Over_Low_Bandwidth.pdf) which said it is 56 byte. But I'm wondering where the dynamic data and dynamic type of every packet are stored. I think they definitely need more space.
2- Is it possible to increase domain ID size? It's 8 bits (0 to 232 plus reserved IDs) (For example increase it to a 16 bits word)
Thanks in advance for your answer :)
Hey,
I only know the answer for the first question and I'll break it into two parts:
The data type is typically (assuming default settings and reasonbly sized data types) sent over the net during the discovery phase, thus saving you from the need of sending it every time.
The overhead of a best-effort basic qos channel (assuming you are using final extensibility) is indeed only the rtps header, which includes the id of the writer, the sequence number, and some other data used by the mechanism.
How ever, using reliability forces you to send acknacks (you can control it but it is part of the mechanism), using liveliness forces you to send heartbeats, and even if you don't do the former, the normal behavior of rti is to publish multicast discovery data periodically (although, arugably, it has little to no effect)
If you choose to use mutable types (instead of using final extensibility), there will be more overhead, as each sample must include the data of which fields are present.
The above being said, the overhead of rti for data that is around 1KB is marginal at best (and if you can utilize batching and have 64KB sized packets then it's even much better, although latency may suffer a bit in those cases)
Hope this helps,
Roy.
Hi Bonjefir,
Edited: Roy beat me to the answer, but I had already typed most of it, so here it goes even if it duplicates some of what he already said...
(1) Data Overhead
The dynamic type is not sent along with each data message. Rather it is sent just over discovery along with the declaration of the DataReader or DataWriter, so it is not counted as part of the "data overhead".
I am not sure what you mean by the "dynamic data". The data is sent in serialized form. "DynamicData" is just an API to access it if an application did not have compile-time knowledge. But regardless of the access API the format on the wire is always the same. It is a binary format called XCDR defined in the DDS-XTYPES specification.
There is no single answer to the overhead. There are multiple situations and configuration options that affect it. I will explain it below, but the number 56 Bytes is a good approximation to hat you will see in common situations. When in doubt, the simplest may be to run wireshark and see the overhead you get on a particular scenario.
According to the DDS-RTPS protocol the "minimal" overhead to send application data on the wire is 48 bytes. This is in addition to the UDP/IP transport headers. I have copied below a sketch of the format on the wire from the DDS-RTPS specification:
0 8 16 24 32 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 000 | ‘R’ | ‘T’ | ‘P’ | ‘S’ | +---------------+---------------+---------------+---------------+ 004 | protocolVersion | vendorId | +---------------+---------------+---------------+---------------+ 008 | | + + 012 | guidPrefix (12 bytes) | + + 016 | | +---------------+---------------+---------------+---------------+ 020 | DATA |X|X|X|X|K|D|Q|E| octectsToNextHeader | +---------------+---------------+---------------+---------------+ 024 | extraFlags | octectsToInlineQos | +---------------+---------------+---------------+---------------+ 028 | readerId (4 Bytes) | +---------------+---------------+---------------+---------------+ 032 | writerId (4 Bytes) | +---------------+---------------+---------------+---------------+ 036 | | + writerSequenceNumber (8 Bytes) + 040 | | +---------------+---------------+---------------+---------------+ 040 | | ~ inlineQos (ommitted if Q==0) ~ 040 | | +---------------+---------------+---------------+---------------+ 044 | encapsulationIdentifier | encapsulationOptions | + - - - + - - - + - - - + - - - + 048 | | ~ serializedData ~ | | +---------------+---------------+---------------+---------------+However there is a couple of things. Typically the data includes also a source timestamp. Although it can be shared accross multiple "DATA" messages within the same RTPS message you need to have at least one. This adds another 12 bytes (see below):
0 8 16 24 32 +---------------+---------------+---------------+---------------+ 000 | INFO_TS |X|X|X|X|X|X|I|E| octectsToNextHeader | +---------------+---------------+---------------+---------------+ 004 | | + timeStamp (8 Bytes) + 008 | | +---------------+---------------+---------------+---------------+Finally for keyed data it is common to send the KeyHash inside the "inlineQos" section. This adds another 16 bytes, see below:
0 8 16 24 32 +---------------+---------------+---------------+---------------+ 000 | PID_KEYHASH | length = 8 | +---------------+---------------+---------------+---------------+ 004 | | + keyHash (8 Bytes) + 008 | | +---------------+---------------+---------------+---------------+ 012 | PID_SENTINEL | padding | +---------------+---------------+---------------+---------------+Taking all this into consideration I would say the overhead is 60 to 76 bytes. But this is if you send a single DATA item in the RTPS message.
Typically multiple DATA can fit into the same RTPS message. In this case the RTPS header and INFO_TS are shared and the "extra" overhead per message is 28 Bytes (or 44 with KeyHash).
Finally there is also a "Batching" feature that can be configured in Connext DDS that will combine multiple payloads within the same DATA message. With this feature the "overhead" per data message can be as low as 8 Bytes (with no timestamp or KeyHash), 16 Bytes (with Timestamp), 24 Bytes (with KeyHash) or 32 Bytes (with both Timestamp and KeyHash).
(2) Increase of DomainId size
Can you explain a bit your goal here? The domainId itself is 32 bytes. However DDS-RTPS restricts domain to be between 0 and 200 because of port-number reservations. Each domain reserves a range of 250 ports (see this post for details) to allow up to 124 domain participants to run on a single IP address with deterministically-assigned and non-conflicting port numbers.
If what you are trying to do is increase the number of domains and you do not need so many particpants on the same IP address you can change those default RTPS port mappings. This is done via Qos. See here for some indication of how to do this).
I would be very interested in understanding your use-case for this because we are implementing a new feature called "virtual domains" that perhaps could help do something similar in a much cleaner way.
Gerardo