Even C++ needs wrappers (libs, STL, Boost, etc.) :-) What's interesting about ØMQ is how quickly you can implement a stable solution at the endpoints using REQ-REP, PUB-SUB, etc., then do plumbing transparently in the middle without changing the endpoint API or semantics.
Also, I haven't focused on patterns for the endpoints yet, there are some evolving in my work. Best, Matt On Aug 11, 2010, at 4:30 AM, Ilja Golshtein wrote: > Matt, > thank you. > > Learning zmq_reactor and your suggestions. > > It is slightly disappointing elegant and crystal 0mq interface is > unusable in > production and requires wrappers and complications ... not a low > hanging fruit. > > 10.08.2010, 21:35, "Matt Weinstein" <matt_weinst...@yahoo.com>: >> Basically -- reverse the normal "server" paradigm, and use an XREP >> socket on the device side, then have each server send a single >> message >> when it wakes up on its REQ socket. This message identifies the >> server to the device side by UUID. The server will be back to >> alternative recv-send cycles (just offset by one). >> >> [[ clients ]] -- [REQ] = [XREP] --- DEVICE --- [XREP] = [REQ] -- >> [[ servers ]] >> >> The server UUIDs go into a "server free list", which can then be used >> to schedule clients. >> >> When you read the client packet stream (UUID,NULLPACKET,data) to >> service a client, you need to keep the <serverUUID, clientUUID> pair >> in a(n unordered) map, so when the server finishes the client >> response >> can be transmitted, and the server pushed back to the freelist. >> >> If there is no server when you receive a client request >> ( server_free_list.empty() ) you can then respond back immediately >> with a failure message. >> >> Alternatively, if you don't want to dequeue requests until a server >> is >> free, just poll ONLY the server list while server_free_list.empty(). >> >> If you need to handle a timeout scenario, either pull the client >> requests out of the XREP, put them into unrolled lists of zmq_msg_t >> or >> equivalent, and build a small timer chain to return an error and kill >> a set (or unordered_map) with the requests. >> >> (The zmq_reactor library should help a bit here, that's what I'm >> using >> for all this...) >> >> Best, >> >> Matt > > -- > Best regards > Ilja Golshtein > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
