Architecture of system using zerogw

[Jiří Sedláček]

What's the intended architecture for zerogw?

I was planning to use zerogw to replace http server. That would mean more workers (think more echo.py clients). The problem I have is that zerogw communicates via PUB/SUB. For the http workers replacement one would need either PUSH/SUB (subscription to unique request id) or PUSH/PULL. The reason being that only one worker would get the message as opposed to PUB/SUB where all workers would get and process the message.

Thanks

Jiri

PS: my main motive is cache invalidation in http workers or in other words how to send a message to all http workers at once

[Jiří Sedláček]

RTFM - my mistake. The /echo URL in example is exactly what I need.

[Paul Colomiets]

Hi Jiří,

It seems you have found solution. But to make it clear for other users...

On Wed, Mar 13, 2013 at 2:54 PM, Jiří Sedláček
<yirie.se...@gmail.com> wrote:
> What's the intended architecture for zerogw?
>
> I was planning to use zerogw to replace http server. That would mean more
> workers (think more echo.py clients). The problem I have is that zerogw
> communicates via PUB/SUB. For the http workers replacement one would need
> either PUSH/SUB (subscription to unique request id) or PUSH/PULL. The reason
> being that only one worker would get the message as opposed to PUB/SUB where
> all workers would get and process the message.
>

HTTP workers always work with request-reply, as HTTP is inherently
request-reply protocol. Only websocket messages may be sent with
either pub-sub or push-pull. (There is an exception when HTTP is used
for websocket emulation, but it's websocket emulation anyway). And for
websockets both pub-sub and push-pull supported. Both are useful in
some situations.

Here is a tiny illustration of how to scale using pub-sub:

http://www.slideshare.net/PaulColomiets/zeromq-and-web/50

and this one for push-pull:

http://www.slideshare.net/PaulColomiets/zeromq-and-web/51

(Yeah, I know that mere illustrations are not very useful, but that
may inspire somebody to ask more :) )

> PS: my main motive is cache invalidation in http workers or in other words
> how to send a message to all http workers at once
>

Ah. You need to do it with a backend. Make a tiny script which accepts
a request and sends message with pub/sub to other workers (using just
zeromq, zerogw is of no help there). In 99% use cases you need to
authorize cache invalidation request anyway (or you are open to DoS
attacks).


--
Paul

[Jiří Sedláček]

Thank you for clarification. I completely missed the PUSH/SUB websocket combination. That's great to know such advanced functionality is built-in. Those illustrations were really helpful.

Jiří

[Jiří Sedláček]

> PS: my main motive is cache invalidation in http workers or in other words
> how to send a message to all http workers at once
>

Ah. You need to do it with a backend. Make a tiny script which accepts
a request and sends message with pub/sub to other workers (using just
zeromq, zerogw is of no help there). In 99% use cases you need to
authorize cache invalidation request anyway (or you are open to DoS
attacks).

So it is possible to use PUB for forwarding websockets but not for regular HTTP requests?

This works (message is forwarded to all backends at once):

            "/socket*":

              websocket:

                enabled: yes

                forward:

                - !zmq.Bind "tcp://127.0.0.1:7002"

                subscribe:

                - !zmq.Bind "tcp://127.0.0.1:7003"

This does not (message is forwarded only to one receiver which is good old PUSH/PULL):

            "/admin":

              zmq-forward: !zmq.Pub

                enabled: yes

                socket:

                - !zmq.Bind "tcp://127.0.0.1:8002"

                contents:

                - !Method ~

I guess you are suggesting to do this:

            "/admin":

              zmq-forward:

                enabled: yes

                socket:

                - !zmq.Bind "tcp://127.0.0.1:8002"

                contents:

                - !Method ~

And run a small backend that listens (REP) on 8002 and sends PUB messages to HTTP workers. I thought I could get away without it but I guess I cannot.

Jiri

[Paul Colomiets]

Hi Jiří,

Yes, exactly. The reason is that you need a reply for HTTP. And it's
not clear what reply might be if you send message to multiple workers.
It's easy to made up the solution for your specific use case, but it's
not clear what a generic one suitable for zerogw might be. It's easy
enough to write 10 lines of backend code, so not worth the hassle
anyway

BTW, Mongrel2 supports sending requests using PUB sockets. However,
you need some coordination from backends to send a reply. So you
complicate workers a bit, comparing to creation of simple 10-lines
script to send pub messages.


--
Paul

[Jiří Sedláček]

Thank you, that makes sense. I will do that.