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
