[zeromq-dev] Questions to better understand zproto and FileMQ

Mario Steinhoff steinhoff.mario at gmail.com
Thu Jan 28 18:30:44 CET 2016

Hi List,

I am building a zproto server, client and protocol in Java, inspired by

Everything works like a charm without any major problems bewtween a server
and a single client so far. (which feels really awesome btw!)

I try to understand the original C implementation for the zproto server,
and I found it might be a
good idea to have a set of statements which describe how I think the server

- The server engine is a single-threaded, event-driven reactor.
- The server engine is a zactor, controlled via a pipe.
- The server engine uses a router socket, so an arbitrary number of clients
can connect.
- The server engine uses zloop to check at least the pipe and router socket
for acitvity.
- The server engine uses zloop timers to regular execute monitoring
- The server engine uses zloop tickets to provide client connection expiry
using heartbeats.
- The server engine maintains a state machine per client-connection.
    - The actual states and transitions are specified in the XML model.
    - GSL is used to generate the concrete server_engine implementation for
a given model.
- The server engine registers a protocol handler on zloop for incoming
router messages.
- The protocol handler
    - determines the client that sent the message using the router address
    - creates a new client reference if the router address is unknown
    - maps the message to a state machine event
    - sends the event to the client's state machine
- The state machine takes the event, performs arbitrary actions based on
the current state.
- An action can set a event that is immediately executed by the engine
without giving control back to zloop.

It would be great if someone could confirm them, or if statements do not
hold true, clarify the inner zproto workings.

With a single client, my implementation works just fine. But when there are
multiple clients connected, and a large file is sent to one of the clients,
other clients timeout.

It looks like when there is credit available, the protocol handler uses
internal events to send CHEEZBURGER messages to a single client until there
is no credit left for that client, effectively blocking all other clients
(e.g. heartbeats wont be answered) and those clients then might timeout the
server connection, depending on their timeout value.

Does this problem also exists in the original C implementation or did I
miss something?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160128/9c712a59/attachment.htm>

More information about the zeromq-dev mailing list