Request/Response communication with iceoryx

[budrus]

Brief feature description

Besides publish/subscribe also request/response communication shall be supported

Detailed information

So far iceoryx only supports publish/subscribe. For frameworks like ROS2 also a request/response communication shall be supported (services in ROS2). The building blocks in posh can be re-used here, so start with client and server ports and then do the layers above

We will have the same layered architecture as for publishers and subscribers. With ChunkSender and ChunkReceiver common building blocks are reused but a Client and a Server will use one of each for the bidirectional data transfer with requests and responses.
This image is a simplified view that shows the class hierarchy and the public method names for the typed C++ API.

1. It will also have a zero-copy API, i.e. we can loan requests and take responses on the Client side and take requests and loan responses on the Server side.
2. Like a Publisher, a Server can offer() or stopOffere()
3. Similar to a Subscriber subscribe() and unsubscribe(), the Client can connect(), disconnect() and getConnectionState()
4. You can poll the Server for requests and the Client for responses or use a Waitset to wait for requests and responses

• 1. Design and interface implementation for ports

• 2. Implementation and unit tests for ports

• 3. Integration test for ports

  • including QueueFullPolicy tests with a real Client- and ServerPort

• 4. C API

  • client
  • request/response header
  • server
  • examples
  • (optional) add iceoryx_posh_types.hpp RPC related config stuff to config.h.
  • (optional) add missing functionality to chunk header

• 5. C++ API

  • typed C++ API
  • tests for typed C++ API
  • untyped C++ API
  • tests for untyped C++ API
  • send returns an expected instead of void

• 6. Integration in runtime and RouDi

  • Make ServerPort's findable via ServiceDiscovery

• 7. Common port queue policies

  • rename SubscriberTooSlowPolicy -> ConsumerTooSlowPolicy
    • alias for ConsumerTooSlowPolicy for easy migration to new API
    • rename WAIT_FOR_SUBSCRIBER -> WAIT_FOR_CONSUMER
    • add WAIT_FOR_SUBSCRIBER = WAIT_FOR_CONSUMER for migration purposes
  • rename QueueFullPolicy::BLOCK_PUBLISHER -> QueueFullPolicy::BLOCK_PRODUCER
    • add BLOCK_PUBLISHER = BLOCK_PRODUCER for migration purposes
  • decide if SubscriberTooSlowPolicy, WAIT_FOR_SUBSCRIBER and BLOCK_PUBLISHER should be deprecated

• 8. Integration test with clients, server and waitsets (user API level)

• 9. Example

[budrus]

@Karsten1987 let's get the party started

[tolga-talkme]

is it possible to use iceoryx in this way?
I mean as in request<->response way

[elBoberido]

@tolga-talkme yes. There is a request/response example