[zeromq-dev] Greetings & questions about inproc PUB/SUB inside Twisted.

[Justin Karneges]

0mq makes some things practical or more efficient:

- Messaging as a general form of development. Consider inproc workers.
- A semi-standard way of interfacing between apps. Mongrel2 would be a lot 
less interesting if it required a broker, IMO.
- MxN or mesh routings are relatively painless to set up and make for better 
sleep at night.

The other messaging solutions have their advantages, too. Nothing wrong with 
many tools.

On Saturday, January 26, 2013 09:57:39 PM Matthew Kaufman wrote:
> 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 <mkfmncom at gmail.com> wrote:
> > Ugh Zed Shaw is annoying lol.
> > 
> > Hi Zed
> > 
> > 
> > On Sat, Jan 26, 2013 at 2:56 PM, David J W <
> > 
> > zeromq-dev-subscribe at ominian.net> 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
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev