add reply stream feature

[rixmann]

We have the following problem:

As client we want to receive an update stream as response to a request. Currently this is solved by starting a server at the client and then streaming to this server. Which is working fine. But as many streams may be received by one component via hello, many holes have to be punshed into firewalls, configuration for more endpoints has to be done etc.

The administration overhead is not acceptable, especially as we already use a transport (ZMTP) which can send bidirectional messages over a established link (socket).

[hwinkel]

There are different options to do this:

ZMTP transport: send messages in both directions, no need to establishing a new connection HTTP transport stateless: Register callback URLs and call the callback URL (similar to the existing schema) HTTP transport stateful: keep the HTTP connection open and send messages from server to client (long polling, server send events model) HTTP transport websocket: is websockets really a option for the hello use case?

[rixmann]

mapping to HTTP SSE would be perfectly fine when using HTTP transport

[hwinkel]

@rixmann if you rely on TCP session state, yes. If you cant rely on it you need to use callback methods. In ZMTP you can rely on the ZMTP sockets as they getting reestablished once the TCP link is broken. is this the same with SSE in HTTP? does the client reestablish the connection? If yes is the new connection in the same context to receive the required messages?

[rixmann]

The client will try to reestablish a lost connection. SSE has optional support for event ids.

So if the endpoint is specific enough and if the server still knows the old events, a connection can be reestablished at the state where the client lost it.

[hwinkel]

this sounds good to me, as long a regular HTTP client (not always a browser) behaves like this

[surik]

zmq server-side notifications were added in #88

[rixmann]

tested, seems to be working fine. but i think we should at least provide the possibility to have multiple notification sinks per client.

not required at this time, so i close this issue.