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

[Joegen Baclor]

// why can't developers just use standard messaging solutions
like rabbit or apache mq //

You CAN.




On 01/27/2013 11:40 AM, Justin Karneges wrote:
> 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
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>