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

Yassine Lamgarchal bouceka78 at gmail.com
Tue Mar 10 15:18:37 CET 2015


Hi,  inline :).


2015-03-09 19:25 GMT+01:00 Kenneth Adam Miller <kennethadammiller at gmail.com>
:

> Inline.
>
> On Mon, Mar 9, 2015 at 7:12 AM, Yassine Lamgarchal <bouceka78 at gmail.com>
> wrote:
>
>> Hi Kenneth,
>>
>> Thank you for your quick response !
>>
>> * I use a DEALER socket because the client must be able to send multiple
>> commands without
>> receiving the response:
>>
>>     - async_result1 = client.command("data1")
>>     - async_result2 = client.command("data2")
>>     - .... do other stufs ....
>>     - result1 = async_result1.get()
>>     - result2 = async_result2.get()
>>
>> * Indeed, it looks like a future object :) !
>>
>> * Yea, in the schema it's a thread which run the event loop and listen
>> for commands to send to the server, i
>> think i can easily spawn a process instead of a thread. The consumer
>> simply connect to the socket, on
>> which the thread listen on, and send commands.
>>
>> * Thanks, i realize that a REQ socket is better in this case because a
>> PAIR will restrict to only one client
>> connected to the "framework thread".
>>
>> Q1. Well, for now there is a fixed number of servers known by each
>> client. When the cluster start it elects a server as
>> a leader, the command are only sent to that particular server. So for
>> now, there is no need to load balance the requests.
>>
>
> So, if you wrapped the connection initialization portion along with the
> service loop in an additional endpoint selection loop in the api, you could
> easily abstract over the use of a broker. If you haven't seen the new
> malamute broker that's being developed, if the test in the loop you did
> actually return or set some kind of targeted server address then you could,
> in the connect call to the server, pass a string that's set depending on
> the model that you select.
>

I got the idea ! Yes, i can proceed like that. I will take a look at the
Malamute broker project :) !


>
>> Q2. Yea, the thing is as a user i don't like when a library create
>> threads in the background, this could lead to bugs hard
>> to troubleshoot. But yea with message passing this could be acceptable.
>>
>
> Well, ideally libraries should not do this, but in fact even ZeroMQ does
> this. If you didn't know it, when you create a context it is in fact a
> runtime as well, creating threads in the background that do things such as
> make sure that your data gets sent reliably and is received and placed into
> the proper framing and some such. It's interesting because the only way
> that it imposes any change on the user is it forces that, on shutdown the
> user not have any remaining sockets that haven't been properly
> deallocated/collected. But that's good practice anyway. So generally, if
> you design your library so that it doesn't expose any dependency to
> consumer code, then you should be in good shape.
>

Yea, you are right. I have to not expose this part to the user and it will
be fine. Thanks for the explanation :) !


>
>> Actually, i thought if i can have the same behavior (then having a single
>> threaded client application) and letting the user
>> create the event loop.  If i do so, the client application must be fully
>> event driven (the client event loop receive events
>> and send commands) but i don't want this. In my use case i think that
>> "framework thread" is mandatory, does my reasoning
>> make sense ? :)
>>
>
> No, I don't know exactly what you're referencing, because my questions
> ended at your above response. This seems to be a newer, different topic.
> Please explain what you mean more.
>

I just wanted to be sure that, in the client side, i really need to have a
"framework thread" (which is unavoidable) in order to have a simple and
proper implementation.

--
Yassine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150310/c9c69b9b/attachment.htm>


More information about the zeromq-dev mailing list