Ah sorry you're right I didn't correctly understand your question. If your client disconnects its socket the router should free the resources. If you set ZMQ_ROUTER_MANDATORY an error will be returned if the peer no longer exists.
-Michel On Thu, Apr 23, 2015 at 8:03 AM, Diego Fons <[email protected]> wrote: > Hi Michel, > > I'm aware of that, but I still don't know how that can help me with the > problem (may be I was not clear enough). > > Using credit-based flow: > - The client connects with identity A. > - The client asks for chunks 0 to 9. > - The client dies (it means the socket will be re-created and > re-connected). > - The server sends all the 10 chunks. > - The server detects the client is dead. > - The client reconnects with identity B (we can not reuse identities). > - The client asks for chunks 0 to 9 again. > - etc... > > I know that if the server tries to send a chunk to client with identity A > after the crash, the chunks are dropped. But, what happen with the 10 > chunks already sent to client with identity A? > > Am I misunderstanding the guide? Is there anything implicit in the ROUTER > behavior that I missed? Should I assume that a message being dropped by the > ROUTER implies that all queued messages were already dropped? > > Regards. > > On Wed, Apr 22, 2015 at 1:10 PM, Michel Pelletier < > [email protected]> wrote: > >> There's good information in the guide about solving these kinds of >> problems. In particular: >> >> http://zguide.zeromq.org/hx:chapter7#State-Machines >> >> But read the whole chapter, it will explain credit based flow control and >> heartbeating as well. >> >> -Michel >> >> On Wed, Apr 22, 2015 at 8:01 AM, Diego Fons <[email protected]> >> wrote: >> >>> Hi, >>> >>> I'm building an application that consists of several clients using >>> DEALER sockets which connects to one server using ROUTER socket. >>> >>> The communication is quite simple: >>> - Client sends a START message to server. >>> - Server sends back an OK message to client. >>> - Server starts sending a stream of data to server (until client asks >>> to stop it). >>> - Client sends a STOP message to server. >>> - Server sends back an OK message to client. >>> >>> The problem: >>> - Client sends a START message to server. >>> - Client crashes. >>> - Server sends back an OK message to client. >>> - Server starts sending a stream of data to server (until client asks >>> to stop it). >>> >>> The client never sends the STOP an the server will continue sending >>> messages until the HWM is reached. The problem is not how to know when a >>> client dies, I'm able to know it. The problem is how to release all the >>> resources used by ZMQ in order to handle the dead client, I mean, all those >>> enqueued messages. >>> >>> The only solution I see untill now, is to close the ROUTER and re-bind >>> it, but I face the problem that another client (several ones) could be >>> perfectly working ans if I close the ROUTER, may be some data could be lost. >>> >>> So, I have two options: >>> 1) Wait untill no clients are active and close the ROUTER. >>> 2) Try to change the pattern (possibly use a pattern with two >>> communication channels). >>> >>> Any comments about his? >>> >>> Regards. >>> >>> -- >>> Diego Andrés Fons >>> Intraway Corp. >>> Solution Developer >>> AR Office: +54 (11) 6040 4000 >>> US Office: +1 (516) 620 3890 >>> Email: [email protected] >>> >>> Visit our website at http://www.intraway.com >>> Proud to be an ISO 9001:2008 certified company >>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> > > > -- > Diego Andrés Fons > Intraway Corp. > Solution Developer > AR Office: +54 (11) 6040 4000 > US Office: +1 (516) 620 3890 > Email: [email protected] > > Visit our website at http://www.intraway.com > Proud to be an ISO 9001:2008 certified company > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
