Hello! 07.01.2018, 02:52, "Chris Double" <chris.dou...@double.co.nz>: > On Sun, Jan 7, 2018 at 10:20 AM, Doug Coleman <doug.cole...@gmail.com> wrote: >> You are right. You would have to use the zeromq nonblocking api, if it >> exists. > > There's zmq_poll which you could spawn in a factor thread and run with > a low timeout to check if any zmq events are occurring: > > http://api.zeromq.org/2-1:zmq-poll
Thank you! I guess that should do it, I'll try to implement a zeromq node and make it work similar to `concurrency.distributed` to exchange serialized Factor messages between instances. Does anyone have experience with ZeroMQ? I'm completely new to it, and there is a ton of documentation, so I would really appreciate a little guidance specific to my use case. There are many patterns like PUB/SUB and such. Let me describe what I need to achieve, and if you know what ZeroMQ pattern I should use, please let me know! 1. A Server process starts a Worker process, passing some parameters on the command line (including TCP port and WorkerID). 2. Worker connects to the localhost:TCP and sends some data to the Server, each message somehow tagged with the WorkerID. 3. When the work is over, a special end-message is sent, and the Worker process exits. There are no receipt confirmations from the Server to Worker, because ZeroMQ guarantees delivery of all messages. From the Server's point of view the stream of data is all-or-nothing: it writes data to a DB, and until the end-message is received, the DB transaction is not committed. If the Worker dies mid-work, it would be nice to know about the lost connection to roll back the transaction and restart the Worker. The communication should be asynchronous. I'm perfectly fine with the entire Worker dataset sitting in TCP buffer somewhere until the Server has time to process it. But that means that early termination of the Worker process should not lead to data loss due to destroyed buffers. Finally, a Server may start multiple workers in parallel, but each worker has only one Server to talk to, and only one stream of data to transfer to the Server (no need for multiple channels of communication per Worker). This means that Workers must be identifiable. Could you help me find the correct topology/ZeroMQ socket types for this task? PS: this task was perfectly solvable with `concurrency.distributed` and `concurrency.messaging`, but it had that weird problem I described earlier on this list, which is possibly specific to Windows sockets or the way Factor handles them. Unfortunately, I'm not the man to fix that. When I have a working `zeromq.node` vocab I plan to contribute it to the Factor repository. ---=====--- Александр ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
