A problem on how to identify 2 or more entities are on the same host [8981]

[Barry-Xu-2018]

About #854

Use below codes to judge whether different entities on the same host.

bool is_on_same_host_as(
            const GUID_t& other_guid) const
    {
        return memcmp(guidPrefix.value, other_guid.guidPrefix.value, 4) == 0;
    }

guidPrefix was generated as follows,

RTPSParticipant* RTPSDomain::createParticipant(
        const RTPSParticipantAttributes& attrs,
        RTPSParticipantListener* listen) {
    ...
    LocatorList_t loc;
    IPFinder::getIP4Address(&loc);

        guidP.value[0] = c_VendorId_eProsima[0];
        guidP.value[1] = c_VendorId_eProsima[1];

            MD5 md5;
            for (auto& l : loc)
            {
                md5.update(l.address, sizeof(l.address));  <== Bind the IP address.
            }
            md5.finalize();
            uint16_t hostid = 0;
            for (size_t i = 0; i < sizeof(md5.digest); i += 2)
            {
                hostid ^= ((md5.digest[i] << 8) | md5.digest[i + 1]);
            }
            guidP.value[2] = octet(hostid);
            guidP.value[3] = octet(hostid >> 8);

guid is related to IP address.

For below case:

1. run process A.
2. Network changed (DHCP lease or insert a network). process A not change its guid value dynamically
3. run process B (on the same machine).

Now A, B are on the same machine, but Fast-RTPS doesn't think about that since guid is different at this case.

Beside, intra-process to use multiple Participants is affected if network changed.
Process A

Begin:
   Create Participant A
   ... <snip>

Running:
    Dynamically create other Participant B, C  (network changed) 

Is there any solution ?

thanks,

[rburchell]

(I'm not an expert on Fast-RTPS, just someone interested in RTPS/DDS driving by, so YMMV, I don't really know what I'm talking about here.)

My reading of the specification is that there's not strictly speaking a requirement that the GUID prefix be based on IP address, just that all GUIDs are unique across a domain, and that all endpoints from the same participant have the same prefix.

Indeed, it can be beneficial to not pick the prefix based on the address, as this means that it's possible to have a participant come up without network interfaces yet being available.

So if the current behaviour is to pick a prefix based on the network address, not doing so would indeed seem to be a possible (and perhaps sensible) idea.

Another case of problem that using repeatable sequences like this can cause is that a (fast) restart/reboot could end up with the same GUIDs being assigned, which causes its own set of havoc when it happens inside of a liveness timeout - which is something I have seen happen.

[fujitatomoya]

@Barry-Xu-2018

DDSI-RTPS just specifes the vendor id in the GUID prefix, not the rest of the field. (as @rburchell mentioned.)

#854 is intra-process communication, it is NOT inter-process. so your catch does not actually apply to #854, right? because it is inside the process space.

but i do understand what you care once it comes to the inter-process communication. this would lead not to use shared memory even all processes reside in the same host. but not a problem for intra-process communication.

maybe this is something we could consider for shared memory feature.

[MiguelCompany]

@fujitatomoya

This affects both inter- and intra- process. Right now, we consider two GUIDs to be in the same process if the first 8 octets are equal, and we consider them to be in the same host if the first 4 octets are equal. As the first 2 are the vendor id, we will always consider GUIDs from other vendors as being on a different host, which is desirable as it implies we will only use the standard transport (UDP) with them.

@Barry-Xu-2018
Thanks for spotting this. I see two ways of approaching this:

1. Having a collection of locally generated GUIDs
2. Use another mechanism to fill guid[2] and guid[3]
   1. Use a similar process to the current one, but using the physical addresses instead of the network ones
   2. Using gethostid on Linux and an alternative mechanism on other platforms

Thoughts?

[fujitatomoya]

@MiguelCompany

there could be rare situation that multiple participants in the same process could have different guid based on IP adress. but originally this issue is for inter-process, so i was saying not exactly related. sorry to confuse you.

As the first 2 are the vendor id, we will always consider GUIDs from other vendors as being on a different host

i believe that this is reasonable, different vendor with different implementation on intra/inter-process, so standard transport should be used.

Thoughts?

maybe too much, uuid based unique id?

[MiguelCompany]

@fujitatomoya

uuid based unique id?

We should think of a mechanism to identify that two processes are on the same host. This means we need a deterministic mechanism, so the two processes give the same result. And we also need the result to be different when run on different machines.

The typical options are:

• Network physical addresses
• HDD volume ids
• CPU serial number
• Hostname
• A hash of all the above, like the one here

[Barry-Xu-2018]

@fujitatomoya

#854 is intra-process communication, it is NOT inter-process. so your catch does not actually apply to #854, right? because it is inside the process space.

No. I think it is possible to get wrong judgement on whether intra-process communication (Special case).
There are lots of participants created while the network changed. is_on_same_host_as() will return wrong result.

About shared memory feature, we also care how to judge processes are on the same host.

[Barry-Xu-2018]

@MiguelCompany @fujitatomoya

We should think of a mechanism to identify that two processes are on the same host. This means we need a deterministic mechanism, so the two processes give the same result. And we also need the result to be different when run on different machines.
...

Yes. Need In-depth consideration.
Such as ‘Network physical addresses’, device have more than one network physical device, or user plugin USB network physical device.

[adolfomarver]

@MiguelCompany

Use a similar process to the current one, but using the physical addresses instead of the network ones

@Barry-Xu-2018

Such as ‘Network physical addresses’, device have more than one network physical device, or user plugin USB network physical device.

May be a file with an ID (derived from physical addesses) can be generated by the first participant created. The next ones just read the ID from the file. That way, changes in physical devices while programs running will not affect the ID.

[Barry-Xu-2018]

@adolfomarver

@Barry-Xu-2018

Such as ‘Network physical addresses’, device have more than one network physical device, or user plugin USB network physical device.

May be a file with an ID (derived from physical addesses) can be generated by the first participant created. The next ones just read the ID from the file. That way, changes in physical devices while programs running will not affect the ID.

Thanks for your suggestion. But I think there is race condition. Such as 2 participant are executed at the same while no file with ID exist. Of cause, this can be resolved by lock. Beside, I think there is a security risk. Any participant have permission to change this file.

[fujitatomoya]

@MiguelCompany @adolfomarver @Barry-Xu-2018

i think the followings, not saying perfect, but enough for the requirement?

• id data resides in memory. (in process space)
• consistent id data as long as system/process running.
• hostid to tell which host the process running.
• pid to tell which process the participant running.

and also i was thinking what if the process fork()?
guid.pid could be different from actual process id after fork().

[richiware]

Using shared memory we will know which processes are in the same host, even having different GUID_t, because they discovered themself through shared memory transport. If NetworkFactory offers such information to the upper level, maybe giving the Locator_t where the DATA(p) was received. Or another mechanism.

[adolfomarver]

This issue affects two mechanisms:

1) identify 2 entities on the same host: I think @richiware suggestion is good. But for that to work implies that shared-memory locators must only be send over shared-memory transport, never by UDP / TCP.

2) identify 2 entities on the same process: I think the problem could be solved by using @fujitatomoya suggestion, that is, generate the hostid as an in-process global variable only the first time guid is calculated. It’s worth to consider if there is a, portable, better alternative to the MD5 of IPs to derive the ID.

[Barry-Xu-2018]

This issue affects two mechanisms:

1) identify 2 entities on the same host: I think @richiware suggestion is good. But for that to work implies that shared-memory locators must only be send over shared-memory transport, never by UDP / TCP.

2) identify 2 entities on the same process: I think the problem could be solved by using @fujitatomoya suggestion, that is, generate the hostid as an in-process global variable only the first time guid is calculated. It’s worth to consider if there is a, portable, better alternative to the MD5 of IPs to derive the ID.

Thanks for summary.
I'll second that.

[JLBuenoLopez]

This caveat has been documented in eProsima/Fast-DDS-docs#487. I am moving the discussion to the Ideas discussion forum and labeling it as an enhancement.