some confusion about send/recv ident
- From:
- Mathijs Kwik
- Date:
- 2011-08-26 @ 17:24
Hi all,
My current setup is 1 mongrel2 machine and a few backend handler processes.
This will probably suffice for some time, but I understood from the
documentation that mongrel2 is be very flexible to support multiple
instances.
Currently, my backends store a user/connId mapping in redis, to know
who's online.
Broadcasting to all users is easy, I just send to the sender uuid and
the connId's of all online users (chunked per 100).
Will this change if I add more mongrel2s in the future?
Do I need to use the same send_ident for the handler config on all
instances, and have them figure out which connIds are theirs?
That would be super easy to setup, just have my handler connect both
sockets (pull, pub) to all of them, no other changes needed.
Or do I have them all use a different send_ident?
In that case I need to store the send_ident in the db as well and
partition response per server myself.
(are the uuid's just a convention? or is there more to it? I'd rather
use something small like a 4 character string if I need to store
these)
Since connIds appear to just be increasing integers, I guess it's
probably the latter.
But sending 10 messages to 10 mongrel2's, who will all drop the 9 that
weren't for them doesn't sound useful.
So my handler lib should probably just setup 1 sending socket per
server, and internally manage what to send where.
In other words, connect the 1 pull socket to all servers, but have 10
pub sockets each connecting to 1 server.
But in that case, why use pub sockets at all? (or did I misunderstand
that subscribing is purely handled SUB-sided?)
Thanks and have a nice weekend,
Mathijs