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

[Matthew Kaufman]

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130126/b8f2dc71/attachment.htm>