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 <p...@imatix.com> wrote: > On Tue, Feb 3, 2015 at 1:01 PM, Doron Somech <somdo...@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@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
