Regarding "0mq" why can't developers just use standard messaging solutions like rabbit or apache mq
what is so cool about 0mq? and yes i am being fully serious....? On Sat, Jan 26, 2013 at 9:57 PM, Matthew Kaufman <[email protected]> wrote: > Ugh Zed Shaw is annoying lol. > > Hi Zed > > > On Sat, Jan 26, 2013 at 2:56 PM, David J W < > [email protected]> wrote: > >> Hello, >> My name is David W, I am a professional code monkey that was first >> introduced to 0MQ via Zed Shaw's talk at PyCon ( believe it was 2010 ) >> but only now have gotten the chance to sit down and start learning the >> library. I am on a sabbatical until ideal after PyCon since I got >> laid off and taking the time out to hit a bucket list ( including >> learning 0MQ ). >> >> On that note, a few years back as a re-invent the wheel project to >> learn Twisted and COMET I started writing a web MUD engine and >> centered the architecture around two message pipelines: User action's >> were locked stepped ( User A moved left, tell server, wait for it to >> say yes/no), broadcast to other User's that User A moved left, >> broadcast to all of User A's group they moved left. NPC's were just >> headless User's driven by a behavior time/tick subprocess that hooked >> upto the same pipelines. I set that project aside because I >> realized I needed a message queue of some sort and really didn't want >> to setup Rabbit or anything super industrial. >> >> Now along arrives 0MQ and since this is a personal project the >> priority is more about understanding how 0MQ works then accomplishing >> the actual project. In the above example I can imagine using 0mq's >> inproc socket's where client's are SUB types ( subscribe to >> map/domain, subscribe to group chat ) and their is a master process >> that has a router socket for incoming work and a pub socket for >> products [ User A in map 1 moved left] ). >> >> So here's my questions: >> For PUB/SUB the impression is that the actual queue sit's on the >> client socket. PUB pushes a message to all client's [ regardless of >> setsockopt(zmq.SUBSCRIBE ) ] and the act of reading the socket >> filter's/clears the queue down to what the client is subscribed to. >> Is this correct or is the subscription more intelligent ( PUB keep's a >> subscription roster, see's no one is subscribed, drop's the message OR >> client receives a message, isn't subscribed so it drops the message ). >> >> Has anyone had any experience running multiple SUB based client's >> inside of one process and are their any severe consequences. I >> imagine a SUB socket is going to instantiate the needed structures to >> hold a queue, the actual socket, and other house keeping structures >> but so far small tests (1-10 sockets) hasn't show much memory use. >> >> Additionally, if I do get past digging through 0MQ's mechanics, I >> was thinking it would be best to spin off the PUB side to it's only >> process. Which leads me to wonder if 0MQ inproc PUB/SUB actually >> relies on some clever memory mapping. eg Push a message on an inproc >> PUB socket which goes to a shared/mutex locked list and client's just >> read from this one list. >> >> Apologies if some of these questions seem naive, I haven't gotten >> the chance to read 0mq's C source code yet. >> >> Thanks, >> Dave >> _______________________________________________ >> 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
