[zeromq-dev] Notes from a hackathon

Doron Somech somdoron at gmail.com
Tue Feb 3 15:38:38 CET 2015


I agree that the best place for session management is at the transport.
However implementing the session management at the server socket level
should be pretty simple, even as POC. Only issue is how to make sure user
is not sending the same messages as the socket sending, but we might ignore
the problem at the beginning. Do you think it worth a try or to leave it to
the transport?

On Tue, Feb 3, 2015 at 3:06 PM, Pieter Hintjens <ph at imatix.com> wrote:

> On Tue, Feb 3, 2015 at 1:01 PM, Doron Somech <somdoron at gmail.com> wrote:
>
> > Pieter - regarding the blog post, I'm not sure about setting the routing
> id
> > on the socket
>
> Indeed, that isn't atomic with sending and so can't work with
> threadsafe sockets. I've changed the article.
>
> I think we can either get the routing id as a message property, and/or
> add a "reply to message" semantic that does this implicitly. The
> second is easier for simple servers, the first is better for realistic
> servers.
>
> Since it only applies to server sockets, I think we would benefit from
> a zserver_reply () method (or similar).
>
> We might also think of moving the picture send/recv API into libzmq at
> some point since it's the immediate replacement for framing.
>
> > I also have a question regarding the session management (really liked
> it),
> > but how would know it is a socket level message and not a application
> level?
> > Also do you think it should be enabled by default or only if an option is
> > set?
>
> To make session management work we'd have to implement it using ZMTP
> control commands, invisibly to the application. Same as heartbeating
> at that level.
>
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150203/1202bf74/attachment.htm>


More information about the zeromq-dev mailing list