Hi Biju, If you want any information at all (including presence) to flow back from client to server, you need a TCP connection.
Your clients would send heartbeats to the server, and if the server doesn't get one within a maximum delay, it treats the client as dead or disconnected. Regarding data plants, there have been no usable advances in that area but if you need such functionality, contact me to discuss it further. -Pieter On Thu, Feb 17, 2011 at 6:34 PM, Biju Chandran <[email protected]> wrote: > Hello, > I have read the mailing list on this topic and found the > following:- > http://lists.zeromq.org/pipermail/zeromq-dev/2010-July/004349.html > http://lists.zeromq.org/pipermail/zeromq-dev/2010-July/004674.html > http://lists.zeromq.org/pipermail/zeromq-dev/2010-July/004635.html > The requirement is as follows > 1. The PUB is bound to a multicast(epgm) endpoint for local multicast and > tcp endpoint for over the internet. > 2. There will be a license scheme based on the number of concurrent clients > and expiry date criteria. For example if company A, has 30 evaluation > licenses and all expiring on 30thMarch 2011, then at a time only 30 SUBs > from company A will receive data and only till 30th of March. > 3. The initial solution that came into my mind was use of separate REQ-REP > over tcp for authentication. Every company will be given a product key which > will be AES encrypted combination of > COMPANYID~NOOFCONCURRENTUSERS~EXPIRYDATE. Within the company the unique > client will be identified by zeroMQ identity. When the very first client for > that company connects,the server will first check the EXPIRYDATE. IF it is > valid then the server will persist > the COMPANYID~NOOFCONCURRENTUSERS~EXPIRYDATE temporarily for the server > session. Then when subsequent clients connect , it will subtract one from > the NOOFCONCURRENTUSERS and if the NOOFCONCURRENTUSERS turns zero it will > give a reject response for that company ID. On the client side , the REQ is > closed and released as soon as it receives the response as SUCCESS or > FAILURE. On success, the client will start listening to the PUB. > 4. I understand that one immediate flaw with this design would be to keep > track of dead connections. Say if a client has been closed by the user, then > client before exit can notify the server. But what if the client exits > abruptly say due to a power failure or innumerable situations. From one of > the above mailing , i understand that one solution would be polling. Where > the server polls on the client to check if it is alive. But this would then > mean keeping one TCP socket alive for each client defeating the advantage of > multicast. > The above mailing posts are more than 6 monts old. I would like to know if > there has been any advances after that especially with the Data Plant Layer > that Pieter mentions. > Also i would like to invite suggestion /advice/recommendations/any help > possible. > Many Thanks, > Biju Chandran > _______________________________________________ > 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
