[zeromq-dev] [pyzmq]: Asynchronous client api design

[Kenneth Adam Miller]

Replied inline

On Sun, Mar 8, 2015 at 7:55 PM, Yassine Lamgarchal <bouceka78 at gmail.com>
wrote:

> Hello all o/,
>
> I'm currently designing a distributed application which is composed of
> clients
> and a remote server.
>
> I struggle with the asynchronous client api... I want it to be the most
> simple
> to use and to implement.
>
> Here is some background: the clients can send commands, when the server
> receive the
> command it does some work and response back to the client. For that, i use
> a DEALER
> socket in the client side and a ROUTER socket in the server side because i
> want the
> client and the server to be asynchronous. In addition, the client can
> receive some
> unexpected event messages.
>
>
Why not a request socket in the client?


> An UUID is associated to each command.
>
>
> What i want to do, from a user point of view, is something like that:
>
>     - async_result = client.command("some_data") # send the command to the
> server
>     - ... do other stufs ...
>     - result = async_result.get() # block until the response is available
>
>
Sounds a lot like a future/promise relationship.


> Here is a schema of what i imagined so far:
> http://postimg.org/image/qxyazo2st
>

Nice schema. Have you thought about adding the possibility of this
asynchronous command being made into a library? Possibly even it's own
process and therefore daemon? Would be interesting to do so, with python's
first class modules, you could easily implement the same send and receive
API, so any consumer could just as easily take advantage of the library
features by simply importing a different module.


>
>
> In this design, there is a thread which run an event loop, this event loop
> will listen
> to a PAIR socket which make the client able to interact with it
> and tells it to send commands.
>

Req socket would do this, but ok.


>
> When the server send the response, the event loop handler will put the
> response on
> a data structure with the command UUID. The client can retrieve the
> response thanks
> to the command UUID.
>
> So there is a synchronization to do between the main application thread
> and the
> "framework thread".
>
> My questions are the following:
>
>     1. Do you think its a simple design for this purpose ?
>

Well, have you thought about the possibility of adding additional servers?
This would easily get hard in that each client would never every server's
address/config info... you could easily put a load balancing broker in here
for easy scalability. It could do nothing but facilitate connection
information exchange for direct direct communication. In this way, you
preserve the entire communication model you've already designed, but also
get more scalability.


>     2. Is it possible to avoid the use of a "framework thread"(and then
> avoid threads synchronization) ?
>
>
Thread synchronization shouldn't be so hard with message passing semantics
under the hood, if you just have the API hide this complexity.

By the way, while I'm writing everything, I'm wondering if it's actually
already been done... *hint :)


>
> Thank you for your help in advance :) !
>
> --
> Yassine
>
>
> _______________________________________________
> 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/20150308/f61f8ca0/attachment.htm>