Unique Client GID for Service Introspectino Event.

[fujitatomoya]

part of ros2/rmw#357

[fujitatomoya]

@MiguelCompany i would like to know what you think about this fix, could you take a look?

[fujitatomoya]

This PR fixes the issue ros2/rmw#357

info:
  event_type: 0
  stamp:
    sec: 1726873574
    nanosec: 967201238
  client_gid: [1, 15, 163, 43, 147, 68, 18, 20, 0, 0, 0, 0, 0, 0, 21, 3]
  sequence_number: 1829
request: [{a: 2, b: 3}]
response: []
---
info:
  event_type: 1
  stamp:
    sec: 1726873574
    nanosec: 967516329
  client_gid: [1, 15, 163, 43, 147, 68, 18, 20, 0, 0, 0, 0, 0, 0, 21, 3]
  sequence_number: 1829
request: [{a: 2, b: 3}]
response: []
---
info:
  event_type: 2
  stamp:
    sec: 1726873574
    nanosec: 967806970
  client_gid: [1, 15, 163, 43, 147, 68, 18, 20, 0, 0, 0, 0, 0, 0, 21, 3]
  sequence_number: 1829
request: []
response: [{sum: 5}]
---
info:
  event_type: 3
  stamp:
    sec: 1726873574
    nanosec: 968045402
  client_gid: [1, 15, 163, 43, 147, 68, 18, 20, 0, 0, 0, 0, 0, 0, 21, 3]
  sequence_number: 1829
request: []
response: [{sum: 5}]

[fujitatomoya]

Pulls: #779
Gist: https://gist.githubusercontent.com/fujitatomoya/24d1b9af9d8b36fe3501d79b78658833/raw/e9b7750a54ef63afe0206b53106c12aaec6ecc73/ros2.repos
BUILD args: --packages-above-and-dependencies rmw_fastrtps_shared_cpp
TEST args: --packages-above rmw_fastrtps_shared_cpp
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/14587

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

[MiguelCompany]

Nice catch!
LGTM

[ahcorde]

Pulls: #779
Gist: https://gist.githubusercontent.com/ahcorde/8df2c5e69dda0758460e6f1e7d63527c/raw/e9b7750a54ef63afe0206b53106c12aaec6ecc73/ros2.repos
BUILD args: --packages-above-and-dependencies rmw_fastrtps_shared_cpp --packages-above-and-dependencies rmw_fastrtps_shared_cpp
TEST args: --packages-above rmw_fastrtps_shared_cpp --packages-above rmw_fastrtps_shared_cpp
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/14594

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

[fujitatomoya]

@MiguelCompany so this did not work, actually it generated the instability for CI. (not often happen, but reproducible with CI)

i am not 100 sure but i believe that the following behavior change can be a reason for this CI hang-up problem.

rmw_fastrtps/rmw_fastrtps_shared_cpp/src/rmw_response.cpp

Lines 140 to 156 in 6bdff0b

	if ((related_guid.entityId.value[3] & entity_id_is_reader_bit) != 0) {
	// Related guid is a reader, so it is the response subscription guid.
	// Wait for the response writer to be matched with it.
	auto listener = info->pub_listener_;
	auto writer_max_blocking_time =
	info->response_writer_->get_qos().reliability().max_blocking_time;
	auto max_blocking_time =
	std::chrono::seconds(writer_max_blocking_time.seconds) +
	std::chrono::nanoseconds(writer_max_blocking_time.nanosec);
	client_present_t ret = listener->check_for_subscription(related_guid, max_blocking_time);
	if (ret == client_present_t::GONE) {
	return RMW_RET_OK;
	} else if (ret == client_present_t::MAYBE) {
	RMW_SET_ERROR_MSG("client will not receive response");
	return RMW_RET_TIMEOUT;
	}
	}

that said, we cannot keep the request publisher gid in rmw_request_id_t * request_header.
i do not have good idea to keep (or get?) the request publisher gid during the process of receiving request and sending response, unless adding the field in rmw_request_id_t. any thoughts?

[MiguelCompany]

@fujitatomoya I think we could use in the client the same trick we use in the server, make the request id use the GUID of the response reader, instead of the request writer