Use client's reader guid for service introspection event gid.

[fujitatomoya]

part of ros2/rmw#357

[fujitatomoya]

@MiguelCompany what do you think about this change?

I am almost sure that using client's reader guid instead of writer guid here in the client for the service introspection event, will not affect any other behavior in rmw_fastrtps.

[fujitatomoya]

CI:

• Linux
• Linux-aarch64
• Linux-rhel
• Windows

[MiguelCompany]

This is ok... if only using rmw_fastrtps_cpp.

Should we consider the case of the server and the client using different vendors?
What would the expectation be in that case?

I am ok with merging this, and addressing the cross-vendor case in a follow-up, but I would like @clalancette opinion first.

[fujitatomoya]

atm, i think that is okay not to consider cross-vendor communication and current code does not seem to care about that either. (https://docs.ros.org/en/rolling/Concepts/Intermediate/About-Different-Middleware-Vendors.html#cross-vendor-communication) i understand we necessarily do not want to break that compatibility with this., but rosbag2 service problem

without this uniqueness capability during a single request-reponse pair, it cannot tell which request is mapped to which response, so that rosbag2 cannot know which message needs to play.

is much bigger problem happening right now...

[fujitatomoya]

@clalancette @wjwwood what do you think?

[MiguelCompany]

i think that is okay not to consider cross-vendor communication

In fact, we would first need to have service interoperability between all the RMWs, which is currently not the case.

Approved, and CI green, so I feel free to merge

[clalancette]

Did we run CI on RHEL Debug for this? That was the case that caused all of the problems before.

[clalancette]

It looks like not, here is a run. If this fails, we'll have to revert:

• Linux-rhel

[clalancette]

All right, all looks happy with this. We'll see what happens overnight.