Please read any of the examples in the Guide that use a ROUTER. They all take much the same approach:
- use client identity as key into a hash table - for each message, lookup or create client instance - then process message using client instance as context Unless you intend to take some time processing messages you can do this in one thread. -Pieter On Tue, Jun 11, 2013 at 1:25 PM, Michael Haberler <[email protected]> wrote: > > Am 10.06.2013 um 11:05 schrieb Pieter Hintjens <[email protected]>: > >> On Mon, Jun 10, 2013 at 9:33 AM, Michael Haberler <[email protected]> wrote: >> >>> I am about to implement a protocol between peers; the phases and >>> interactions being roughly: >>> >>> - an negotiation phase (peers exchange options and reach agreement or dont) >>> - an 'open' phase entered on agreement, where state updates flow either >>> direction as needed, not necessarily requiring confirmation >>> - a shutdown phase initiated by either side >>> >>> Potentially there might be more than two peers. Message flows and encoding >>> are done (protobuf). >> >> It's a fairly common use case and I'd tend to recommend an asymmetric >> protocol with ROUTER at the "server" and DEALER at the "client"; there >> are examples of this in the Guide, especially Chapter 7. If you want a >> symmetric network you can try the Harmony pattern from Chapter 8. > > I need another smack on the head,) > > ROUTE/DEALER worked fine (I dont need symmetric) for a single thread > > extending to multiple clients I'd think one worker thread per client seems > the way to go, since that worker thread will also be the natural place to > manage per-client protocol state > > That would suggest a binding of worker thread to a client at initial exchange > based on client socket identity, not distribution based on load > > the first step could look like so: > > - once a client identity is seen first time, start a worker thread and create > an associated per-worker inproc socket (?) > > The remaining plumbing is unclear to me: > - the main thread could push messages based on identity down that per-worker > socket, and pull replies back from same (then probably REQ/REP would be the > right mode) > - a worker could subscribe to a certain identity and either reply directly > (?) or by passing a reply back to the DEALER (?) > - I'm unclear if a device is appropriate here > > grateful for a suggestion, > > Michael > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
