Response channel - issues

[matteo-gsr]

I am testing the new response channel feature to build a duplex channel between a client and a server, very handy.

I have the following configuration:

  request_channel: "aeron:udp?endpoint=127.0.0.1:10000"
  request_stream_id: 1
  response_channel: "aeron:udp?control-mode=response|control=127.0.0.1:10001"
  response_stream_id: 2

1. server creates a subscription on the request channel and stream 1
2. client creates a subscription on the response channel and stream 2
3. client creates a publication on the request channel and stream 1
4. server detects new image and creates a publication to the response channel stream 2

so far so good, all working, I can send messages back and forth.

Now, if I shut down the client, I get an unavailable image callback on the server and drop the publication. However, if I look at netstat, I still see something listening on udp 127.0.0.1:10001. That's odd as that was really the client's subscription socket, which should go away after I shut down the client.

If I lsof the server process, I see:

server 4442 matteo   17u    IPv4 0xd61e8c9e97e260b8       0t0      UDP 127.0.0.1:10000
server 4442 matteo   28u    IPv4 0xedc1503ea6514c2f       0t0      UDP 127.0.0.1:10001

that's odd - why would it listen on the response channel? It should only listen on the request channel.

I am also then observing something weirder. If I leave the app running for a while, at some point the server (request) subscription silently closes and even though I keep polling the subscription, I don't see any error.

Note:

1. I am using the C media driver and the C client.
2. Server and client are running with embedded media drivers for this testing.

[mikeb01]

The two listening ports are expected. The reason that it works this way is that channels in Aeron are uni-directional, so to have bi-directional communication we need to have two channels. The way that this differs from a normal two channel setup is that the listening ports are both defined on the "server" side. The two ports are request subscription's endpoint and the response subscription's control. This has some similarities with dynamic MDC. This makes it much simpler to set up clients as the user does not need to specify a listening port on the client - which can be tricky and can make NAT traversal difficult.

With regards to the subscription closing, I'll have to look into that in more detail. Would you be able to do a run with debug logging enabled on the driver and post the log here?

[matteo-gsr]

let me collect some logs and report back. Btw, are response channels also supported with IPC? As in, can I just switch the channel from udp to ipc without having to change any code?

[vyazelenko]

@matteo-gsr The answer depends on the side you are looking at. The client code won't change when switching to IPC. But the server side will need to handle response streams separately from normal streams since it needs to establish correlations between incoming images and outgoing publications.