RTPS Domain hostid part of the GUID match first interface IP [4969] #456
Comments
|
Pull request #53 suggested a different way to adress this, by using the MD5 hash of all the returned interfaces. It may be a nice mechanism ... ¿thoughts? |
|
I supposed we could do something with the hash of the MAC address of all the interfaces, yes. This would be a lot more unique compared to an ip especially when you have many interfaces. |
|
Just looked at the original pull request. I'll play around with it and see how I can make it work more broadly. |
guillaumeautran
added a commit
to clearpathrobotics/Fast-RTPS
that referenced
this issue
Apr 11, 2019
Because of the code [here](https://github.com/eProsima/Fast-RTPS/blob/f6ebf154a97089136c4906de11f535969708f2a0/src/cpp/rtps/RTPSDomain.cpp#L113), the RTPS Domain GUID can potentially be not unique between multiple participant hosted on different computer. This happens because the host ID component is initialized with eProsima magic number (0x010f) and the last two digit of the IPv4 address of the first interface enumerated by `getifaddrs`. On some systems where there are several network interfaces, this scheme is not sufficient for generating a mostly unique hostid to be used for the RTPS Domain and collision can happen in the case where the first interface enumerated is an interface used by the system in isolation with the actual network. In addition, the `appId (the process ID running the stack) is only unique within the computer itself and does not provide enough uniqueness especially when the process is started as part of a systemd job on boot. This fix generates a MD5 sum of all IPv4 addresses for all interfaces, then "folds" that 16 bytes MD5 sum into a 16 bits value to be used as the lower two bytes of the hostid field. Doing it this way provides more guarantee that the field will be unique across multiple identical systems. issue: eProsima#456
guillaumeautran
added a commit
to clearpathrobotics/Fast-RTPS
that referenced
this issue
Apr 15, 2019
Because of the code [here](https://github.com/eProsima/Fast-RTPS/blob/f6ebf154a97089136c4906de11f535969708f2a0/src/cpp/rtps/RTPSDomain.cpp#L113), the RTPS Domain GUID can potentially be not unique between multiple participant hosted on different computer. This happens because the host ID component is initialized with eProsima magic number (0x010f) and the last two digit of the IPv4 address of the first interface enumerated by `getifaddrs`. On some systems where there are several network interfaces, this scheme is not sufficient for generating a mostly unique hostid to be used for the RTPS Domain and collision can happen in the case where the first interface enumerated is an interface used by the system in isolation with the actual network. In addition, the `appId (the process ID running the stack) is only unique within the computer itself and does not provide enough uniqueness especially when the process is started as part of a systemd job on boot. This fix generates a MD5 sum of all IPv4 addresses for all interfaces, then "folds" that 16 bytes MD5 sum into a 16 bits value to be used as the lower two bytes of the hostid field. Doing it this way provides more guarantee that the field will be unique across multiple identical systems. issue: eProsima#456
richiware
pushed a commit
that referenced
this issue
Apr 30, 2019
Because of the code [here](https://github.com/eProsima/Fast-RTPS/blob/f6ebf154a97089136c4906de11f535969708f2a0/src/cpp/rtps/RTPSDomain.cpp#L113), the RTPS Domain GUID can potentially be not unique between multiple participant hosted on different computer. This happens because the host ID component is initialized with eProsima magic number (0x010f) and the last two digit of the IPv4 address of the first interface enumerated by `getifaddrs`. On some systems where there are several network interfaces, this scheme is not sufficient for generating a mostly unique hostid to be used for the RTPS Domain and collision can happen in the case where the first interface enumerated is an interface used by the system in isolation with the actual network. In addition, the `appId (the process ID running the stack) is only unique within the computer itself and does not provide enough uniqueness especially when the process is started as part of a systemd job on boot. This fix generates a MD5 sum of all IPv4 addresses for all interfaces, then "folds" that 16 bytes MD5 sum into a 16 bits value to be used as the lower two bytes of the hostid field. Doing it this way provides more guarantee that the field will be unique across multiple identical systems. issue: #456
|
I think the PR to address this issue has been merged. Can we close this issue then? |
|
Should automatically close tomorrow when it gets into master |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Given the code here to determine and assign a participant GUID, the "hostid" portion of the GUID (first 4 bytes) is initialized with eProsima prefix (0x010f) and the last two digit of the IPv4 address of the first network interface found.
On system with several interfaces, most of which internals, this scheme is not sufficient for generating a mostly unique hostid to be used for the RTPS Domain.
When the Fast-RTPS process is started as part of the boot sequence, the process ID can often be the same on multiple machines causing multiple participant to have the exact same GUID and confuse each-others.
A more robust approach (on linux and osx) would be to make a call to the gethostid(2) method and use the information received to initialized the hostid portion of the RTPS GUID.
The text was updated successfully, but these errors were encountered: