[zeromq-dev] blocking send when no peer
Hi, As I understand it, calls to zmq_send are supposed to be non-blocking. The data to send is queued in the background, and zmq takes care of sending the data when it can. Thus zmq_send should return immediately (unless the internal queue is full, I'd imagine?). However, does this rule hold true when the underlying transport, for example TCP, is not yet connected? I'm observing the behavior that when I send to a PUSH socket I've set to bind (as opposed to connect), without any peer existing yet, that the send call blocks instead of backgrounding. I'm using the python bindings if it makes any difference. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] blocking send when no peer
On Tuesday, January 31, 2012 02:42:48 PM Justin Karneges wrote: I'm observing the behavior that when I send to a PUSH socket I've set to bind (as opposed to connect), without any peer existing yet, that the send call blocks instead of backgrounding. It seems to be bind-specific. This code hangs, after only printing the first message: context = zmq.Context(1) socket = context.socket(zmq.PUSH) socket.bind(tcp://127.0.0.1:9100) print about to call send socket.send(hello) print done calling send socket.linger = 0 socket.close() context.term() However, if I call socket.connect instead of socket.bind, then the code does not hang. Is this behavior intentional and/or documented anywhere? Thanks, Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] blocking send when no peer
On Wednesday, February 01, 2012 04:40:13 AM Ian Barber wrote: On Tue, Jan 31, 2012 at 10:58 PM, Justin Karneges jus...@affinix.comwrote: On Tuesday, January 31, 2012 02:42:48 PM Justin Karneges wrote: I'm observing the behavior that when I send to a PUSH socket I've set to bind (as opposed to connect), without any peer existing yet, that the send call blocks instead of backgrounding. It seems to be bind-specific. This code hangs, after only printing the first message: It's because zeromq creates the internal queue on the first connection, so there's nothing there at bind time to push to. Hmm, are outbound queues per-connection only then? Or is there a socket-level queue that is just being lazy created? Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] python, calls not unblocking on signal
Hi, I'm running workers in different threads of a python app, while the main thread sleeps. I want to be able to cleanly shutdown the app when ctrl-c is pressed. As it is now, when ctrl-c is pressed, the main thread receives KeyboardException. However, blocking zmq calls in the worker threads do not return with EINTR and so all the threads remain stuck. Is this a python peculiarity regarding signal handling? How are people doing clean shutdowns on ctrl-c with python? Thanks, Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] python, calls not unblocking on signal
On Wednesday, February 01, 2012 10:15:10 AM MinRK wrote: Is this a python peculiarity regarding signal handling? How are people doing clean shutdowns on ctrl-c with python? It's a general Python issue. Python + Threads + Signals = mess. From the signal doc http://docs.python.org/library/signal.html: only the main thread can set a new signal handler, and the main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads) Bummer. Poller and non-blocking writes it is, I guess... Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] POLLOUT not eventing on bind with no peer
If I create a socket with bind, but nobody has connected yet, then I do not receive POLLOUT events. How can I determine when the socket becomes writable in an event-driven fashion? Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] POLLOUT not eventing on bind with no peer
On Wednesday, February 01, 2012 12:00:22 PM Justin Karneges wrote: If I create a socket with bind, but nobody has connected yet, then I do not receive POLLOUT events. How can I determine when the socket becomes writable in an event-driven fashion? Sorry, I apologize for the stupid question. The answer is the same as my earlier one blocking send. The socket becomes writable once a peer has connected. I must admit I still find it confusing that a socket with bind does not immediately have a background write queue. Was this an intentional design decision, or just something that hasn't been implemented yet? Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] POLLOUT not eventing on bind with no peer
On Wednesday, February 01, 2012 12:38:48 PM Chuck Remes wrote: On Feb 1, 2012, at 2:11 PM, Justin Karneges wrote: On Wednesday, February 01, 2012 12:00:22 PM Justin Karneges wrote: If I create a socket with bind, but nobody has connected yet, then I do not receive POLLOUT events. How can I determine when the socket becomes writable in an event-driven fashion? Sorry, I apologize for the stupid question. The answer is the same as my earlier one blocking send. The socket becomes writable once a peer has connected. I must admit I still find it confusing that a socket with bind does not immediately have a background write queue. Was this an intentional design decision, or just something that hasn't been implemented yet? It's intentional. The mailing list archives have the answer... I know sustrik has answered this a few times. Search for the subject bind/connect assimetry (yes, use that misspelling). Thanks, found here: http://thread.gmane.org/gmane.network.zeromq.devel/6810/focus=6813 I'll add this to the FAQ. Excellent. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] python, calls not unblocking on signal
On Wednesday, February 01, 2012 04:31:35 PM MinRK wrote: If you are just looking for clean shutdown, you can terminate the Context from the main thread when it is interrupted, and then blocking calls in other threads will raise ZMQError(ETERM). For example: https://gist.github.com/1720387 Thanks! I see ETERM is actually a standard feature of libzmq, very nice. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Thread-safe sockets (cont.)
I apologize for jumping in mid-conversation, but I see two thread-safety goals: 1) 0MQ has no built-in locks on sockets. Applications may use a socket in different threads provided the application itself uses its own locks around the socket accesses. 2) 0MQ has its own locks built-in, so you can use a socket in different threads and the application does not need its own locking. As I understand it, the current stable 0MQ does not even allow #1. At least, I have read documentation stating that a socket should not be used except in the thread it was created in, meaning sockets have thread-affinity. Is this true? I personally would like to see #1 solved if it has not been already. I think it should just work, but offering a function to change thread affinity of a socket would be acceptable. Otherwise, 0MQ is thread impossible, which to me is much worse than not thread safe. :) I have no need for #2 and I think it's overkill. The only justification I can see for it is if 0MQ is trying to emulate posix/kernel behavior and this is a necessity in its long term goals. On Thursday, February 16, 2012 10:53:19 PM Marten Feldtmann wrote: I am by far no expert in 0MQ, but actually the question of thread-safe socket is no question any more for me. It has been written in the documentation in a clear way, that one should not use sockets from different threads. Over the last weeks - and due to a question from me - it was in a more detailed way explained, what is allowed to do and what not. These informations should be added to the documentation. I've no problem to follow this guideline in my Smalltalk language binding. Its ok and I can work with it and I offer a thread safe interface to the 0MQ library. When people starts working around my official language binding - ok, then its their fault. I can not and would not like to forbid this - I assume, that others also might know how to use the 0MQ library. Therefore: leave the decision to the end user and give them enough information so that it can make their own decisions based o this free available information. I like 0MQ because it has such a small C-level API and it is easy to use. The examples guides are well done and show how to use it. Perhaps thread-safe sockets are a nice marketing idea. Some people might think, that this is an absolute must to have - and without that a library is not a reliable piece of software. It is perhaps the same as thinking, that dynamic typed languages are a regressive step in CS. At least this last idea is simply wrong and has been shown over the last 50 years in CS. There is an analogue in Posix: optional locking. It's fairly useless. Because anyone can write into a locked region of a file by ignoring the locks. This optional locking is quite a good design pattern: Perhaps the base system contains an error and the strict locking prevents you from doing the last emergency execution step. Its then always good to have the choice (thats the keyword in building libraries) of turning of this locking ... Marten Am 17.02.2012 02:56, schrieb john skaller: It's not entirely useless but in todays world software is so complex people want rigid guarantees of correctness for some things, because there are always a heap of other things where there are no assurances: [casts in C .. dynamic typing in web applications OMG what a regressive step in CS] ___ 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
[zeromq-dev] random connect ports causing problems
Hi folks, Today I ran into issues where socket connects were stealing ports that my socket binds needed. I also witnessed what is probably quite rare: a socket connecting to itself. At least netstat was showing the source and dest ports for a single localhost connection as the same. Probably there should be a way to specify a range of ports to stay within when connecting as a client, that does not overlap with any ports expected to be used by binds. Any suggestions? I suppose this isn't even really a 0mq question, but it does seem like something more likely to happen in a 0mq environment. I didn't see anything in the FAQ. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] REQ/REP for possibly async comm?
I wondered about this as well. I want to make a worker that does remote method calls, and it would expose a REQ/REP interface that other workers would use whenever they want to make a remote call. Since the work bottleneck is time (waiting for remote server responses), I'd prefer the worker use asynchronous sockets rather than waste many threads on synchronous sockets that spend the majority of their time idle. However, I also want to be able to respond to requests out of sequence (e.g. receive requests A, B, but then respond to B before A), and I think this breaks the REQ/REP pattern. On Monday, March 26, 2012 03:21:08 PM Andrei Zmievski wrote: I have two processes that need to exchange data. Process A has to perform time-critical work, but also needs to obtain some configuration data from process B. Initially, I considered using REQ/REP sockets since it's a roundtrip query, doing something like on A: initialize work unit if (previously sent request) check response from B if (still no response after 30 seconds) send config request else send config request finish work unit The problem I see with REQ/REP is that they work in lockstep and that B may not reply in a reliable fashion. Thus, I wouldn't be able to send a new config request until I heard back from B. Is it better to switch to PUB/SUB or DEALER/REP scheme here? -Andrei ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] BSON as high performance serialisation
ASN.1/BER/DER? *ducks* On Saturday, March 31, 2012 04:42:58 PM Pieter Hintjens wrote: On Sat, Mar 31, 2012 at 6:35 PM, Wolfgang Richter w...@cs.cmu.edu wrote: I think the documentation references ProtoBufs (FAQ does: http://www.zeromq.org/area:faq), maybe we should add a list of alternatives for people to look at (this is at least interesting to some in the community)? Yes, it's a common question, good to collect useful answers. -Pieter ___ 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
Re: [zeromq-dev] missing events ZMQ_FD / ZMQ_EVENTS
On Wednesday, May 02, 2012 03:27:42 AM Paul Colomiets wrote: Ok. Behind the scenes ZMQ_FD, is basically a counter, which wakes up poll when is non-zero. The counter is reset on each getsockopt ZMQ_EVENTS, zmq_send and zmq_recv. The following diagram shows race condition with two sockets A and B, in a scenario similar to yours: https://docs.google.com/drawings/d/1F97jpdbYMjjb6-2VzRtiL2LpHy638-AEOyrUX84 HL78/edit Note: the last poll is entered with both counters set to zero, so it will not wake up, despite the fact that there is pending message. Was there ever a resolution on this? I am using ZMQ_FD now to integrate into an event loop, and I am seeing some odd behavior when testing a hello world REQ/REP on the REP side. The REP server binds and waits for data. The fd is indicated as readable twice. First, the events are 0 (maybe this happens when the client connects?), then the events are 1 (ZMQ_POLLIN). The server considers the REP socket readable and so it reads a message without blocking. Now it wants to reply, but it considers the socket not yet writable. I was expecting that after reading from the socket, the fd would be indicated as readable and the events would be 2 (ZMQ_POLLOUT). However, this event never comes and so the server just idles. Now here's where it gets weird: if I kill the client (which was also waiting around, as it never got a reply), then the server gets new events with ZMQ_POLLOUT set. This causes the server to finally write its reply to the REP socket, without blocking. Of course there is no client, so this write goes into a black hole. My guess is that the events change with ZMQ_POLLOUT is somehow being backlogged, and the client disconnect helps push the queue another step forward. I found that if, immediately after reading from the REP socket, I query ZMQ_EVENTS, then I can see the ZMQ_POLLOUT being flagged even though I never got a read indication on the fd. Does this mean that maybe I need to check ZMQ_EVENTS not only after read indications on the fd, but also after anytime I call zmq_recv() ? Thanks for any help. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] missing events ZMQ_FD / ZMQ_EVENTS
On Wednesday, June 27, 2012 12:44:45 PM Paul Colomiets wrote: On Tue, Jun 26, 2012 at 2:16 AM, Justin Karneges jus...@affinix.com wrote: Does this mean that maybe I need to check ZMQ_EVENTS not only after read indications on the fd, but also after anytime I call zmq_recv() ? I've not tried REP sockets with asynchronous event loop (XREP usually needed). But I'm pretty sure, you're right. You need to recheck ZMQ_EVENTS after doing zmq_recv(), as the state of the socket changes at that time (it's not writable before not because of network issues but because of state machine). Yeah I understand the ability to write is part of the state change that occurs by reading. I just wonder why the ZMQ_FD isn't triggered internally by zmq_recv(). That would have been more intuitive I think. However, checking ZMQ_EVENTS after each zmq_recv and zmq_send is needed anyway, as described in current documentation and in this ML thread. In which document is this described? I do not see this in the ZMQ_EVENTS section of the zmq_getsockopt man page in 2.2.0. In any case, thanks for clarifying. I'd actually gone ahead and changed my code to check ZMQ_EVENTS after all three scenarios (post zmq_recv, post zmq_send, and upon read indication of the ZMQ_FD), and that managed to get things to work properly. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] HWM behaviour blocking
On Thursday, May 10, 2012 01:53:48 PM Pieter Hintjens wrote: On Thu, May 10, 2012 at 3:44 PM, Paul Colomiets p...@colomiets.name wrote: Can you be more specific, why setting HWM to 1 is a bad thing? Do you mean, that it smells bad to set HWM to 1 for reliability? Or do you think that setting it will have other consequences? (low performance?) it's bad because you're trying to force a synchronous model on an asynchronous system, and doing it at the wrong level. If you really want synchronization you MUST get some upstream data from the receiver. Just throttling the sender cannot work reliably. I'm about to set HWM to 1 and I recalled a thread about this so I've looked it up. Totally agree about what's been said so far. The reason I want to do this is because I need a way for an event-driven application to determine if data has been written to the underlying kernel. This is useful in case the application wants to close the socket immediately after writing data. In a traditional blocking application, this is easy: just call zmq_close() and it'll unblock when done. However, in an event-driven application, the only way I can think of imitating this functionality is by setting HWM to 1 and waiting until ZMQ_EVENTS indicates writability, then calling zmq_close(). Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] qzmq
I've written a Qt-based wrapper to zmq here: https://github.com/jkarneges/qzmq There are some similar projects already (zeromqt, nzmqt), but I wanted to do things a little differently. Maybe people will find it useful. Today I discovered there is another project already called qzmq, that provides bindings to the Q language. Well, don't confuse it with that. :) Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] HWM behaviour blocking
On Thursday, June 28, 2012 03:50:57 AM Paul Colomiets wrote: Hi Justin, On Thu, Jun 28, 2012 at 8:50 AM, Justin Karneges jus...@affinix.com wrote: On Thursday, May 10, 2012 01:53:48 PM Pieter Hintjens wrote: On Thu, May 10, 2012 at 3:44 PM, Paul Colomiets p...@colomiets.name wrote: Can you be more specific, why setting HWM to 1 is a bad thing? Do you mean, that it smells bad to set HWM to 1 for reliability? Or do you think that setting it will have other consequences? (low performance?) it's bad because you're trying to force a synchronous model on an asynchronous system, and doing it at the wrong level. If you really want synchronization you MUST get some upstream data from the receiver. Just throttling the sender cannot work reliably. I'm about to set HWM to 1 and I recalled a thread about this so I've looked it up. Totally agree about what's been said so far. The reason I want to do this is because I need a way for an event-driven application to determine if data has been written to the underlying kernel. This is useful in case the application wants to close the socket immediately after writing data. In a traditional blocking application, this is easy: just call zmq_close() and it'll unblock when done. However, in an event-driven application, the only way I can think of imitating this functionality is by setting HWM to 1 and waiting until ZMQ_EVENTS indicates writability, then calling zmq_close(). Why you need zmq_close in the asynchronous application in the first place? Is your application very connection hungry? We never close zeromq sockets even on fairly low traffic connections, and it works nice. It's really just for functional completeness of my event-driven wrapper. The only time I can see this coming up in practice is an application that pushes a message just before exiting. For now, I set ZMQ_LINGER to 0 when a socket object is destroyed, making the above application impossible to create. What I'm thinking of doing now is offering an alternate, blocking-based shutdown method. This would violate the spirit of my wrapper, but may work well enough for apps that finish with a single socket doing a write-and-exit. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] HWM behaviour blocking
On Friday, June 29, 2012 06:13:53 AM Paul Colomiets wrote: On Thu, Jun 28, 2012 at 9:06 PM, Justin Karneges jus...@affinix.com wrote: It's really just for functional completeness of my event-driven wrapper. The only time I can see this coming up in practice is an application that pushes a message just before exiting. For now, I set ZMQ_LINGER to 0 when a socket object is destroyed, making the above application impossible to create. What I'm thinking of doing now is offering an alternate, blocking-based shutdown method. This would violate the spirit of my wrapper, but may work well enough for apps that finish with a single socket doing a write-and-exit. I think you should just set linger and use it. zmq_close() doesn't block. The zmq_term() blocks. Wow, silly me working around a non-problem. I was assuming zmq_close() blocked. Thanks for clarifying. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] blocking zmq_close?
On Wednesday, July 04, 2012 05:57:36 PM Whitney Jackson wrote: Hi, I'm using the ZMQ_FD getsockopt feature to integrate ZeroMQ into an event loop that I don't control and don't have the source code for. This works quite well except when I want to close a ZeroMQ socket. Since zmq_close is non-blocking, control gets returned to the event loop before the socket is fully shutdown causing this error: Bad file descriptor (epoll.cpp:69) gdb on the core file shows #0 0xf77bf430 in __kernel_vsyscall () #1 0x45d7395f in raise () from /lib/libc.so.6 #2 0x45d752b3 in abort () from /lib/libc.so.6 #3 0xf36f719c in zmq::zmq_abort (errmsg_=0x45eaf393 Bad file descriptor) at err.cpp:76 #4 0xf36f5f0a in zmq::epoll_t::add_fd (this=0x9029a10, fd_=14, events_=0x902a2b0) at epoll.cpp:69 #5 0xf370c3d7 in zmq::socket_base_t::start_reaping (this=0x902a210, poller_=0x9029a10) at socket_base.cpp:717 #6 0xf3705a87 in zmq::reaper_t::process_reap (this=0x90287e0, socket_=0x902a210) at reaper.cpp:101 #7 0xf36fbfd4 in zmq::object_t::process_command (this=0x90287e0, cmd_=...) at object.cpp:120 #8 0xf370591f in zmq::reaper_t::in_event (this=0x90287e0) at reaper.cpp:72 #9 0xf36f64f7 in zmq::epoll_t::loop (this=0x9029a10) at epoll.cpp:161 #10 0xf36f65c5 in zmq::epoll_t::worker_routine (arg_=0x9029a10) at epoll.cpp:174 #11 0xf3710792 in thread_routine (arg_=0x9029a54) at thread.cpp:75 #12 0xf7749adf in start_thread () from /lib/libpthread.so.0 #13 0x45e3655e in clone () from /lib/libc.so.6 I can prevent the error by doing a zmq_term on the context or just sleeping before returning control to the event loop but obviously these solutions aren't optimal. Is there some way to block until zmq_close is really done? How about removing the socket's fd from the eventloop's monitoring at the time of close? It would be surprising if you can add an fd but not remove it... Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] question about integrating zmq socket fd in external select() loop
Stuff I ran into when implementing: 1) Be aware that ZMQ_FD only generates read events. You then check ZMQ_EVENTS to see what actually happened. 2) You need to check ZMQ_EVENTS in three situations: after ZMQ_FD read event, after calling zmq_send, and after calling zmq_recv. It was only recently documented that you need to check in the latter two situations, so this is easy to miss. For example, if you have a REP socket that triggers a ZMQ_FD read, and then ZMQ_EVENTS reports that it is readable, and then you call zmq_recv() to obtain a message from the socket, you might NOT get another read event on ZMQ_FD to tell you to check ZMQ_EVENTS to see that the socket is now writable. Instead, you should check ZMQ_EVENTS immediately after zmq_recv() to learn if the socket has become writable. On Monday, August 06, 2012 09:18:18 AM diffuser78 wrote: Can someone plz share their experiences around this problem ? On Fri, Aug 3, 2012 at 3:38 PM, diffuser78 diffuse...@gmail.com wrote: Hi, I am writing a lib that uses zmq. This lib is going to be used in an app that already has an external select() loop. Can I use fd's retrieved from ZMQ_FD from zmq_getsockopt() in that select loop successfully ? Are there examples already that tell you how to do it ? Are there any things that I should know ? I read FAQ section related zmq_poll and also saw man zmq_getsocketopt for ZMQ_FD. I wanted to know the persoanl experience of some developer around this. I greatly appreciate your response. Thanks. DJ ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] zmq_send blocks after zmq_bind and before other side connects
On Wednesday, August 22, 2012 10:30:55 PM Dmitrijs Palcikovs wrote: It seems like zmq_send blocks after zmq_bind and before the other side connects to the endpoint. For example, the following code: void *sock = zmq_socket(ctx, ZMQ_PAIR); zmq_bind(sock, tcp://*:9090); zmq_msg_t msg; zmq_msg_init_size(msg, 5); memcpy(zmq_msg_data(msg), hello, 5); zmq_send(sock, msg); // Blocks until someone connects zmq_msg_close(msg) If zmq_bind is replaced with zmq_connect then it doesn't block. I would expect zmq_send to buffer outgoing messages in both scenarios (bind and connect). This behavior doesn't seem to be documented anywhere (i.e. most of the docs seem to give the impression that bind and connect are similar in this sense), yet this is a significant difference between the two. Can anyone comment on why this is the behavior for bind? This is a non-obvious behavior of zeromq that I ran into as well. It was added to the FAQ: http://www.zeromq.org/area:faq Why do I see different behavior when I bind a socket versus connect a socket? Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] ipc sockets and multiple connections
If the ipc transport is used on unix, can I have one bind and multiple connects, similar to how I would with the tcp transport? For some reason I have this idea that unix shared pipes can only be 1 to 1, but I am not totally sure on that. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] about using ZMQ_FD in an external select loop
The ZMQ_FD is a special fd you use to get notified of events on a zmq socket. It is not the actual underlying network socket that receives messages. Remember a zmq socket is virtual, and under the hood it may be managing many network sockets (or none at all, if you consider the ipc type). I don't believe ZMQ_FD will indicate readability if a partial message is received over the network. At least I don't see a reason why zmq would want to bother the app about this. That said, even if ZMQ_FD gets indicated as readable more often than necessary, you should simply get the resulting ZMQ_EVENTS and act on them. On Thursday, September 06, 2012 04:24:43 PM diffuser78 wrote: I did not frame my question correctly and subject was misleading too. Let me put that correctly. I am using a ZMQ FD in an external select() loop, i,.e, a ZMQ FD is added to the set of fds (regular unix fds) in an external select() loop. Consider a situation, for a given message (in a router dealer pattern), only a few bytes are received at the receiver end and not the complete message, so the external select() loop would wake up the ZMQ FD since it can read atleast few bytes, but when we call zmq_getsockopt() API with an option of ZMQ_EVENTS to get the list of events on the socket, ZMQ doesn't return any FD since no complete message is recvd (only a few bytes have been recvd). My question is: During the next select() iteration, would external select() wake up ZMQ FD again because we did not read the few bytes that were ready to be read on that fd OR will it NOT wake up ZMQ FD until new bytes are available for reading on this fd? What is ZMQ behavior in this case. Any help is greatly appreciated. Thanks. On Wed, Sep 5, 2012 at 5:41 PM, diffuser78 diffuse...@gmail.com wrote: Hi, I am using a ZMQ FD in an external select() loop, that is, a ZMQ FD is added to the set of fds (regular unix fds) in an external select loop. Consider a situation, for a given message (in a router dealer pattern), only a few bytes are received at the receiver end and not the complete message, so the external select() loop would wake up the ZMQ FD since it can read atleast few bytes, but when we do a ZMQ_POLL, ZMQ doesn't return any FD since no complete message is recvd (only a few bytes have been recvd). My question is: Next time, would external select() wake up ZMQ FD again because it is level triggered or does ZMQ internally reads those bytes so that external select loop won't wake up ZMQ FD until new set of bytes are received ? Please let me know your thoughts. DJ ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] High water mark notification for publisher
Another behavior that may be acceptable is blocking the sender if all outgoing queues are full. I believe the only reason it doesn't block today is because you wouldn't want one slow subscriber causing all other subscribers to stop receiving messages. But there may be apps that rely on writes to pub never blocking (it is true that it never blocks today, correct?) On Friday, September 21, 2012 05:57:29 PM Edwin Amsler wrote: Hey folks, I brought up this problem a few months back, but had to move onto more pressing things at the time. It was mentioned that under the hood, the PUB-SUB system had individual outgoing queues, each with their own water mark counters. What happens to a message when all queues are full? It would be ideal to know if the message I pass in will be dropped by all queues due to the high water mark. I don't think it was implemented then, but it would certainly solve my particular problem of over-tasking the publishing side. I have example code here: http://pastebin.com/gjfuNdNF The idea would be that if that ZeroMQ's publisher has no room in the internal buffers, that I would be notified the message wasn't sent. In the test application, I would then be able to wait before trying again. This way the application code which publishes messages isn't creating needless work which is secretly thrown away. Thoughts? ___ 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
[zeromq-dev] ROUTER and blocking
Hi, When does a write to ROUTER block? Is it if the identified connection has a full queue? Does this mean it would be possible to write to the socket in non- blocking mode with one connection id and get EAGAIN, but then write to the same socket using a different connection id and succeed, even though nothing had changed about the underlying socket queues between these write attempts? Also, if the identified connection does not exist, I assume the socket drops the message rather than blocking until that connection appears? Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] High water mark notification for publisher
Right. I see this really as a flow control problem. Here's another angle to look at it: what if your pub socket has no subscribers? In that case you probably wouldn't want to be writing to the socket at max speed either. Maybe that's an edge case not worth covering, but I wonder if it helps you arrive to a generalized solution. In my previous message I suggested that writes to a pub socket should block if all subscribers' queues were full. Now I want to say that writes to a pub socket should block if there are no subscribers at all. Maybe I have not fully thought of all the implications, but this really could just be made standard behavior and it would solve your problem. The other idea is to not use PUB/SUB but emulate most of it using other types. I just emailed separately about the behavior of ROUTER and blocking, which could be used as part of the solution. I have a similar flow control problem of my own to solve, though it's not quite the same as yours. On Friday, September 21, 2012 06:41:47 PM Edwin Amsler wrote: I should also be specific and point out that in my case it's fine that some subscribers don't receive everything. When I say the data is thrown out, not a single subscriber ever receives it. It's also problematic because my application code has no idea that the secret ZeroMQ internals are still churning away. If we're bound by the fastest subscriber, at least we know %100 of the information provided gets to a destination. Even if the destination(s) is across multiple computers (say if one subscriber slows down and another takes the lead). On 21/09/2012 6:28 PM, Edwin Amsler wrote: As far as I know, it doesn't block. I also think that we should make sure that slow subscribers not cause trouble for others. If we notify when all queues are full, then the application code would be bound by the fastest subscriber, not the slowest. In my example code I put a sleep(), but it could just as easily be a spin lock. My application pulls data from a number of other sources, so it's costly to generate traffic and its a shame that 90% of it gets thrown out. On 21/09/2012 6:22 PM, Justin Karneges wrote: Another behavior that may be acceptable is blocking the sender if all outgoing queues are full. I believe the only reason it doesn't block today is because you wouldn't want one slow subscriber causing all other subscribers to stop receiving messages. But there may be apps that rely on writes to pub never blocking (it is true that it never blocks today, correct?) On Friday, September 21, 2012 05:57:29 PM Edwin Amsler wrote: Hey folks, I brought up this problem a few months back, but had to move onto more pressing things at the time. It was mentioned that under the hood, the PUB-SUB system had individual outgoing queues, each with their own water mark counters. What happens to a message when all queues are full? It would be ideal to know if the message I pass in will be dropped by all queues due to the high water mark. I don't think it was implemented then, but it would certainly solve my particular problem of over-tasking the publishing side. I have example code here: http://pastebin.com/gjfuNdNF The idea would be that if that ZeroMQ's publisher has no room in the internal buffers, that I would be notified the message wasn't sent. In the test application, I would then be able to wait before trying again. This way the application code which publishes messages isn't creating needless work which is secretly thrown away. Thoughts? ___ 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 ___ 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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] High water mark notification for publisher
I am also dealing with a file-sending case and want to avoid sending at read speed for the same reasons. I've decided to use the credits-based flow control approach Pieter suggested. For pub/sub, you really only need one subscriber sending credits, but the nice thing about the approach is that it can be used for either fastest subscriber or slowest subscriber flows depending on how you organize sending the credits. On Saturday, September 22, 2012 10:23:16 PM Edwin Amsler wrote: Heh. Not quite. In my particular case, I'm creating data at about 500MB/s (a file read in this case that's limited by in-memory kernel file cache), and I'm capping the outbound bandwidth at around 40Mb (~4MB/s) for OpenPGM. Not setting a high water mark, I quickly eat all available memory and my system swaps heavily (and indefinitely depending on the file I'm sending). Setting it to 128 messages (~1MB/message which is big, I'll admit), means that the first 128 megabytes go out just fine, then chunks here and there make it out when the queues begin to empty. I also have some control data here and there in band, but I need to hope I have room in the send queue so they don't just get silently thrown out. I have a mechanism out of band over TCP that re-requests pieces once the transfer is done, but I'm never actually sure when it's done sending so I just wait 1 minute before re-requesting. If I had some indicator of whether or not the message goes missing, I could re-transmit or throttle back the 500MB/s to what the network is actually able to provide. On 22/09/2012 10:04 PM, Bennie Kloosteman wrote: ADSL upload ??? On Sun, Sep 23, 2012 at 10:48 AM, Edwin Amsler edwinams...@thinkboxsoftware.com mailto:edwinams...@thinkboxsoftware.com wrote: It's unlikely that an application can produce more data per second than the network hardware is able to handle? On 22/09/2012 12:57 AM, Pieter Hintjens wrote: On Sat, Sep 22, 2012 at 12:57 AM, Edwin Amsler edwinams...@thinkboxsoftware.com mailto:edwinams...@thinkboxsoftware.com wrote: It was mentioned that under the hood, the PUB-SUB system had individual outgoing queues, each with their own water mark counters. What happens to a message when all queues are full? This is such an unlikely case... almost contrived. The real issue with high-speed pub/sub is a small number of clients disconnecting or getting swamped by other work, and their queues building up, and causing memory exhaustion. The best strategy to keep data flowing but also ensure reliability is then some kind of out-of-band recovery for clients that need it. There's some ideas in the Clone pattern in the Guide (request snapshot at startup, then apply changes as they arrive to the snapshot). -Pieter ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto: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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] obtain generated identity of socket
Hi, I'm using ROUTER-ROUTER connections for one-way communication. How can the sending peers identify the destination peers? Currently I'm generating peer ids and telling the senders out of band (using a different socket), but the destination ROUTER sockets are not yet aware of these ids, so messages don't get delivered. I think I could use ZMQ_IDENTITY to set my generated ids on the destination ROUTER sockets, yes? The sending peers use the envelope format, where the first part of each message is the destination peer id. I recall reading somewhere that setting ZMQ_IDENTITY was being discouraged, but maybe that was only in the context of durability? Is there a way for me to create a ROUTER socket and then ask it for its generated id, instead of me making one? The docs seem to indicate that by default the socket would have no identity, so I'm not sure if reading the default ZMQ_IDENTITY value is what I want. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] obtain generated identity of socket
On Monday, September 24, 2012 04:24:06 PM Pieter Hintjens wrote: On Mon, Sep 24, 2012 at 2:42 PM, Justin Karneges jus...@affinix.com wrote: I'm using ROUTER-ROUTER connections for one-way communication. How can the sending peers identify the destination peers? The only sane way I found was to use the server endpoints as agreed identities, i.e. if you're binding to 192.168.55.131:, then use that as your identity when connecting. This lets the other router talk to you. Makes sense. I've currently made it work by generating a UUID (in my app code) and using that as the identity. This identity is sent using a separate socket to the client. But mostly router-to-router seems like a bad pattern. I'd rather do two connections, one dealer-router in each direction, so each peer plays server and client cleanly. Just simpler to understand. Here's my use-case; maybe you can critique it: I want to send a stream of data to a server instance (of which there may be multiple), and I want to ensure all the messages for a given stream go to the same server. The server uses 3 sockets: in: PULL socket, for retrieving start requests out: PUB socket, for sending notifications (ignore why this is PUB, for now) in_stream: ROUTER socket, for retrieving append messages. this socket is given an explicit identity. Protocol flow goes like this: 1) client pushes a start request that gets picked up by one of the server instances 2) server pubs a clear to send response that includes a reply address field, containing the value of the in_stream identity 3) client sends a series of messages to in_stream, addressed using the reply address In other words, PUSH deals to an arbitrary server, but once the server acks the request, the client locks on to that server and sends the remainder of the stream specifically to that server. For flow control, the server regularly grants credits to the client via the pub socket. The client writing to in_stream should use a ROUTER socket for itself, since it is using the enveloped addressing that requires routing. The server, on the other hand, could be DEALER or ROUTER, I suppose. Both terms seem misleading for a socket that never gets written to, but ROUTER seemed slightly less so as it is the most raw. Maybe it should be possible to connect ROUTER to PULL? :) Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] obtain generated identity of socket
On Tuesday, September 25, 2012 08:18:03 AM Paul Colomiets wrote: Hi Justin, On Tue, Sep 25, 2012 at 1:08 AM, Justin Karneges jus...@affinix.com wrote: Protocol flow goes like this: 1) client pushes a start request that gets picked up by one of the server instances 2) server pubs a clear to send response that includes a reply address field, containing the value of the in_stream identity 3) client sends a series of messages to in_stream, addressed using the reply address As your transfers seems big, I think it's ok to open separate (push) socket for each transfer. (Or just have a separate socket connected to each server). I.e. in the clear to send message server gives and address where to connect to for sending message. Creating sockets for each transfer is antipattern if you are doing it hundred times per second, but for your use case it may be cleaner than router to router connection. I do need this to support hundreds-of-times-per-second capacity, and the stream sizes may vary wildly (could be one message, could be 200MB of messages). Your idea of the client having separate PUSH sockets to each server could work as a substitute for the single ROUTER socket. But I do think ROUTER is logical, at least on the client side. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] announcing Zurl
Hi folks, I want to share a project I've been working on called Zurl. It's a server with a ZeroMQ interface that makes outbound HTTP requests. Think of it like the inverse of Mongrel2 or Zerogw. This is the project I was discussing earlier on the list that needed two input sockets. I've made it open source: https://github.com/fanout/zurl Introduction article here: http://blog.fanout.io/2012/09/26/make-http-requests-over-zeromq-with-zurl/ Not much in the way of docs at the moment, but sample scripts in the tools subdir give you an idea of what's possible. Feedback welcome. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] announcing Zurl
On Wednesday, September 26, 2012 10:16:15 PM Paul Colomiets wrote: Hi Justin, On Wed, Sep 26, 2012 at 8:04 AM, Justin Karneges jus...@affinix.com wrote: Hi folks, I want to share a project I've been working on called Zurl. It's a server with a ZeroMQ interface that makes outbound HTTP requests. Think of it like the inverse of Mongrel2 or Zerogw. This is the project I was discussing earlier on the list that needed two input sockets. I've made it open source: https://github.com/fanout/zurl Introduction article here: http://blog.fanout.io/2012/09/26/make-http-requests-over-zeromq-with-zur l/ Not much in the way of docs at the moment, but sample scripts in the tools subdir give you an idea of what's possible. Feedback welcome. Nice thing. I'm seeking for something similar to do benchmarks for my web applications. However, most our applications are websocket-driven. Any chance websockets will be supported? Yes, I'd like to eventually support this. One nice thing is the ZeroMQ interface is already built to stream in both directions, so it shouldn't be too strange to handle ws/wss URL schemes. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] ROUTER/PULL
Inspired by the PUSH/ROUTER question a moment ago, I wonder if it ought to be possible to match ROUTER and PULL, for one-way directed communication? Currently I am using ROUTER-ROUTER for this, and the receiver just ignores the envelope. Being able to make the receiver PULL seems like it would be more natural. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER/PULL
Why not make it allowed in a future version? It doesn't seem any more unusual than other mixings. On Tuesday, November 13, 2012 12:32:33 PM Chuck Remes wrote: No, do not do this. If it works at all right now, it will break in a future library release when the wire protocol enforces peer socket type checking. ROUTER - ROUTER is fine as is ROUTER - DEALER. Alternately, do PUB - SUB. As of libzmq 3.2, the publisher filters out the outgoing messages so only those SUBs that have subscribed to the message will receive it. This will require you to add a subscription string as the first message part for all outgoing messages so the socket can filter it. Please read the guide if this doesn't make sense to you yet. There are lots of great examples with code. cr On Nov 13, 2012, at 12:00 PM, Justin Karneges jus...@affinix.com wrote: Inspired by the PUSH/ROUTER question a moment ago, I wonder if it ought to be possible to match ROUTER and PULL, for one-way directed communication? Currently I am using ROUTER-ROUTER for this, and the receiver just ignores the envelope. Being able to make the receiver PULL seems like it would be more natural. Justin ___ 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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER/PULL
Then how do you justify, for example, the ability to mix REQ and ROUTER? Is that just an exception to the rule? In my opinion, from a design point of view, zmq should either have very strict patterns (e.g. no more REQ+ROUTER), or it should allow mixing where it makes sense (e.g. ROUTER+PULL). Doesn't this seem reasonable? Right now the allowed mixing seems kind of arbitrary to me. On Wednesday, November 14, 2012 07:28:47 AM Pieter Hintjens wrote: There are reasons to not mix ROUTER and PULL, mainly that they are from different patterns, so if we decide to improve PUSH/PULL as a package, we would be unable, if people were mixing them with other patterns. As an example, see how we improved PUB/SUB to do pub-side filtering. DEALER does just the same as PUSH + PULL, so ROUTER/DEALER gives you what you want, and is better too, since you can do things like send heartbeats in both directions. -Pieter On Wed, Nov 14, 2012 at 4:02 AM, Justin Karneges jus...@affinix.com wrote: Why not make it allowed in a future version? It doesn't seem any more unusual than other mixings. On Tuesday, November 13, 2012 12:32:33 PM Chuck Remes wrote: No, do not do this. If it works at all right now, it will break in a future library release when the wire protocol enforces peer socket type checking. ROUTER - ROUTER is fine as is ROUTER - DEALER. Alternately, do PUB - SUB. As of libzmq 3.2, the publisher filters out the outgoing messages so only those SUBs that have subscribed to the message will receive it. This will require you to add a subscription string as the first message part for all outgoing messages so the socket can filter it. Please read the guide if this doesn't make sense to you yet. There are lots of great examples with code. cr On Nov 13, 2012, at 12:00 PM, Justin Karneges jus...@affinix.com wrote: Inspired by the PUSH/ROUTER question a moment ago, I wonder if it ought to be possible to match ROUTER and PULL, for one-way directed communication? Currently I am using ROUTER-ROUTER for this, and the receiver just ignores the envelope. Being able to make the receiver PULL seems like it would be more natural. Justin ___ 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 ___ 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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER/PULL
Thanks for the explanation. The original grouping by pattern makes it more clear why things work they way they do. On Wednesday, November 14, 2012 09:57:54 AM Pieter Hintjens wrote: Justin, The combinations are not arbitrary. There's an explanation here: http://zguide.zeromq.org/page:all#Request-Reply-Combinations. Firstly, you can replace REQ with DEALER, and REP with ROUTER, to turn a synchronous REQ-REP into a partially or fully asynchronous flow. Secondly, you can combine DEALER to DEALER and ROUTER to ROUTER to get two new patterns. The legal combinations are formally defined in the zmq_socket man page. The original design ideology, which was accurate IMO, was that each low-level pattern was a separate package. Thus, PUB+SUB, PUSH+PULL (pipeline), PAIR, REQ+REP+DEALER+ROUTER. We've been extending the protocol to announce each peer's socket type, to let us catch invalid combinations. The public spec in zmq_socket[3] defines what kind of future compatibility we promise. Since it states that ROUTER+REQ is valid, this will always work. But since it does not allow ROUTER+PUSH, we're free to break that in the future. Hope this helps to understand the reasoning here. -Pieter On Wed, Nov 14, 2012 at 7:54 AM, Justin Karneges jus...@affinix.com wrote: Then how do you justify, for example, the ability to mix REQ and ROUTER? Is that just an exception to the rule? In my opinion, from a design point of view, zmq should either have very strict patterns (e.g. no more REQ+ROUTER), or it should allow mixing where it makes sense (e.g. ROUTER+PULL). Doesn't this seem reasonable? Right now the allowed mixing seems kind of arbitrary to me. On Wednesday, November 14, 2012 07:28:47 AM Pieter Hintjens wrote: There are reasons to not mix ROUTER and PULL, mainly that they are from different patterns, so if we decide to improve PUSH/PULL as a package, we would be unable, if people were mixing them with other patterns. As an example, see how we improved PUB/SUB to do pub-side filtering. DEALER does just the same as PUSH + PULL, so ROUTER/DEALER gives you what you want, and is better too, since you can do things like send heartbeats in both directions. -Pieter On Wed, Nov 14, 2012 at 4:02 AM, Justin Karneges jus...@affinix.com wrote: Why not make it allowed in a future version? It doesn't seem any more unusual than other mixings. On Tuesday, November 13, 2012 12:32:33 PM Chuck Remes wrote: No, do not do this. If it works at all right now, it will break in a future library release when the wire protocol enforces peer socket type checking. ROUTER - ROUTER is fine as is ROUTER - DEALER. Alternately, do PUB - SUB. As of libzmq 3.2, the publisher filters out the outgoing messages so only those SUBs that have subscribed to the message will receive it. This will require you to add a subscription string as the first message part for all outgoing messages so the socket can filter it. Please read the guide if this doesn't make sense to you yet. There are lots of great examples with code. cr On Nov 13, 2012, at 12:00 PM, Justin Karneges jus...@affinix.com wrote: Inspired by the PUSH/ROUTER question a moment ago, I wonder if it ought to be possible to match ROUTER and PULL, for one-way directed communication? Currently I am using ROUTER-ROUTER for this, and the receiver just ignores the envelope. Being able to make the receiver PULL seems like it would be more natural. Justin ___ 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 ___ 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 ___ 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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER/PULL
On Wednesday, November 14, 2012 10:08:31 AM Pieter Hintjens wrote: On Wed, Nov 14, 2012 at 8:47 AM, Charles Remes ch...@chuckremes.com wrote: The names imply the proper pairings. In what world does ROUTER / PULL make sense from a semantic standpoint? How does a PULL socket even send a message to a ROUTER socket? How can a ROUTER talk to a PULL socket that hasn't sent it a message? You'd have to cheat with hard-coded identities. Well, or use a separate socket for inbound communication. My application receives from one socket and sends to another. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER/PULL
On Wednesday, November 14, 2012 11:15:09 AM Pieter Hintjens wrote: You've not identified any problem with using DEALER except it's not PULL, which seems arbitrary. You can literally replace ZMQ_PULL with ZMQ_DEALER in your code and it will work the same. Ah, okay, I did not think of this. Currently my receiving socket uses ROUTER and ignores the header, but I like the idea of using DEALER instead as that aligns slightly closer to the intended usage (read: of not really caring about envelopes or return addresses). Note that I never was using PULL in this context, I only wanted to start a discussion about the possibility. Anyway, the only real difference between DEALER and PULL then is that, at a glance, the PULL socket has a more obvious contract. This may help when familiarizing oneself to a zmq-based project, or for a network administrator that is configuring socket connections. But this is just a nitpick. How do you know the identity of the PULL socket you're sending to? The ROUTER socket does not work well with purely outbound communications. There are several aspects: * You need to invent and manage your own identities * You have no way of knowing when the connection is actually live * When sending, and connection is not live, messages are silently dropped * You have no way to heartbeat the connection, so cannot detect failures Of course there is some extra work when doing this. In my case, the use of credits-based flow control and timeouts (in both directions, but on separate sockets) ensures that failures are noticed. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] general strategy for sending data over epgm
On Monday, December 03, 2012 09:59:12 PM Ian Barber wrote: On Mon, Dec 3, 2012 at 8:50 PM, mlist user mlist.user8...@gmail.com wrote: Hi Andrew, On 4 December 2012 07:47, Andrew Hume and...@research.att.com wrote: i'm not sure what the issue is. if the rate is small and the messages are large, then yes, you need to sleep large amounts. How would you figure out you need to sleep X second? Are you setting the RATE sockopt yourself and then trying to manage the pace at which you send on top of that? Slightly OT, but I wonder if RATE might be a useful feature to allow for all PUB sockets (and maybe just all sockets), rather than restricted to pgm only. It seems to me that you want to use RATE when you need to slow down sending but can't depend on receiver feedback. This is a problem at the pattern level, not the transport level. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Question about Strange Socket Pairing
Writes to PUB never block. If a subscriber's queue is full, then the message is dropped for that subscriber. If there are no subscribers, the message is dropped entirely. Connect vs bind is a matter of which entity should be considered to have stable availability. For example, if a single publisher serves data to an arbitrary number of subscribers (maybe some notifications system), then you'd bind with PUB and connect with SUB. On the other hand, if an arbitrary number of publishers send data to a single subscriber (maybe some stats collection system), then you'd bind with SUB and connect with PUB. On Tuesday, December 04, 2012 04:35:54 PM Matt Goodman wrote: Mmkay. That is what I was feeling. So a followup question would then be what it the correct way to go about this? The push/pull socket thing works well, I am just concerned about the HWM semantics of blocking. I would much rather use a Pub/Sub connection model, but I would need multiple publishers with a single subscriber? This seems a bit backward. I think the XPub/XSub model has what I need, but I am unclear on the semantics of which calls bind and which connects . . . --Matthew Goodman = Check Out My Website: http://craneium.net Find me on LinkedIn: http://tinyurl.com/d6wlch On Tue, Dec 4, 2012 at 3:41 PM, Michel Pelletier pelletier.mic...@gmail.com wrote: The guide says: Any other combination will produce undocumented and unreliable results and future versions of ØMQ will probably return errors if you try them. So, looks like you got lucky. You can't rely on that however and in the future it likely will break as the underlying protocol evolves to guard against these cases. -Michel On Tue, Dec 4, 2012 at 3:36 PM, Matt Goodman meawo...@gmail.com wrote: I am writing an application that uses ZMQ for a couple of different things, one of which is error logging. For reasons that somewhat complicated, the logging server is written in Node, and the clients are Python and C++. I had no trouble getting everything to commuicate, and send messages with relative ease, however I wanted to ask a question about a strange socket pairing that I found to work, when I didn't expect it to. Initially, my logging was done with a node PULL socket, and several other PUSH clients. I wanted to eliminate the blocking behavior. I started the transition to the PUB/SUB model, but when I had retooled 1/2 of my code, the tests I had passed. Specifically, I had a PUB socket talking to a PULL socket . . . successfully. . . Is this pairing allowed, and are there unintentional oddities I will run into with it? Oh. Great project/product, and good work! Thanks! --Matthew Goodman = Check Out My Website: http://craneium.net Find me on LinkedIn: http://tinyurl.com/d6wlch ___ 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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Libev integration problem: Stop receiving ZMQ_EVENTS events
I'm not sure if this is the issue you're having, but be aware that you have to check ZMQ_EVENTS in *three* scenarios: after zmq_send, after zmq_recv, and when ZMQ_FD triggers a read event. On Monday, December 10, 2012 04:39:22 PM CheYi Lin wrote: I'm using the low level API zmq.h in C, integrating zmq with libev event-loop. My program is complicated but the zmq libev integration part is simple. (http://pastebin.com/6JiSh46N) Sorry I'm new to the community. Best Regards, Cheyi Lin On Mon, Dec 10, 2012 at 4:13 PM, Pieter Hintjens piet...@gmail.com wrote: Can you make a raw test case (ideally in c using the low level API or czmq)? On Dec 10, 2012 8:37 AM, CheYi Lin cheyi@gmail.com wrote: Hi, I'm doing some zmq ROUTER-to-ROUTER experiments in my distributed system prototype. (single threaded, libev event loop based application) Below is my test steps: 1. ROUTER A and B start, set unique identity, bind the address. (handshake) 2. A connect to B. 3. A send HELLO to B continuously. 4. B recv HELLO then send HELLO_ACK back to A. 5. A recv HELLO_ACK and stop sending HELLO, handshake finished. (start communication) 6. A and B send HEARTBEAT to each other every 0.5 seconds. 7. When HEARTBEAT received, A and B print recv HEARTBEAT. After about 30 seconds, A stop printing recv HEARTBEAT but B continue printing recv HEARTBEAT. And few seconds later I terminate B, suddenly A print lots of recv HEARTBEAT. I notice that A stop being signaled from the ZMQ_FD (in gdb), so all HEARTBEAT from B was queued after A stop printing recv HEARTBEAT. My zmq-event handler: http://pastebin.com/6JiSh46N Don't know why the handler stop receiving ZMQ_EVENTS events. Could someone please review my code and give me some suggestions? Sorry for my bad english. Regards, Cheyi ___ 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 ___ 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
Re: [zeromq-dev] Titanic SP with encrypted data transfer
On Friday, December 14, 2012 12:23:19 AM Pieter Hintjens wrote: On Thu, Dec 13, 2012 at 11:42 PM, Jovan Kostovski chomb...@gmail.com wrote: I know that ZeroMQ supports TLS shared keys encryption... It doesn't, yet, unfortunately. If you need encryption, you will need to either do it at a lower layer (VPN), which is usually quite nasty, or else modify the TSP protocol to do encryption using something like SASL, which is also nasty. You can also encrypt per message, using pre-shared keys, which is the least nasty option IMO. Another idea is to gateway through a secure protocol such as HTTPS or XMPP when crossing hostile networks. This isn't really a ZeroMQ solution, but if the majority of your sockets aren't at risk and you're just trying to protect a couple of them that go over the internet, it's probably the best choice in terms of secureness vs nastiness. :) It is, however, quite some extra coding. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] socket writability and events
Hi, Is it possible that a socket could be determined to be writable but then actually isn't writable at the time of write? For example, say a connection exists on a bind socket and ZMQ_POLLOUT is indicated. But then just before calling zmq_send(), the connection is destroyed. A socket that was using bind should have no queue anymore, and therefore I would expect the send to actually block (or report EAGAIN). I just want to confirm this is indeed possible. Secondly, assuming the above is true, if you're doing an event loop integration and checking ZMQ_EVENTS after every call to zmq_send, do you still need to check the events even if zmq_send fails? My guess is that if it fails with EAGAIN, that you probably should check the events (especially if the reason you attempted a write in the first place is because ZMQ_POLLOUT was indicated prior). What I'm doing in my code now is checking events after success or EAGAIN, but not checking in any other case. Looking for confirmation on this as well. Thanks, Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] socket writability and events
Ok some quick testing within my app confirms that EAGAIN will be returned if a socket turns out to be unwritable, even after indicating writability. For example, if a tcp connection is established, POLLOUT is indicated, the tcp connection is broken, and then a write is attempted. Personally I think this is fine. I'd rather know that the socket is unwritable rather than the alternative which would be to eat the message. It is a bit of a gotcha though, for anyone used to internet sockets (or pipes in general), where if a socket is said to be writable then this condition cannot be revoked (well, I suppose that's not quite true, we have the lovely EPIPE there instead). Also, this I think this can only ever happen with bind sockets. So the behavior could go away someday if bind sockets ever get their own outbound queues that live independent of peer connections. As for part 2: it seems the unavailablity of writes is actually notified via ZMQ_FD through the lack of POLLOUT being set in the events. I'd never considered taking action by the absense of this flag until now. This means my app learns about unwritability immediately and the window of opportunity to write to a socket that is no longer unwritable becomes very very small. I also believe this means it is unnecessary to poll the events after a failed zmq_send. On Friday, December 14, 2012 11:46:09 PM Pieter Hintjens wrote: Part 1. the behaviour isn't documented but what you suggest makes sense. You should be able to reproduce it. Part 2. not documented, again, would need to test to be sure. Once we have reproducible cases we can see whether these are bugs to fix, or expected effects to document. -Pieter On Fri, Dec 14, 2012 at 9:40 PM, Justin Karneges jus...@affinix.com wrote: Hi, Is it possible that a socket could be determined to be writable but then actually isn't writable at the time of write? For example, say a connection exists on a bind socket and ZMQ_POLLOUT is indicated. But then just before calling zmq_send(), the connection is destroyed. A socket that was using bind should have no queue anymore, and therefore I would expect the send to actually block (or report EAGAIN). I just want to confirm this is indeed possible. Secondly, assuming the above is true, if you're doing an event loop integration and checking ZMQ_EVENTS after every call to zmq_send, do you still need to check the events even if zmq_send fails? My guess is that if it fails with EAGAIN, that you probably should check the events (especially if the reason you attempted a write in the first place is because ZMQ_POLLOUT was indicated prior). What I'm doing in my code now is checking events after success or EAGAIN, but not checking in any other case. Looking for confirmation on this as well. Thanks, Justin ___ 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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ZeroMQ for a Real Time API
On Sunday, December 30, 2012 01:50:10 PM Marinho Brandao wrote: well, I'm new using ZeroMQ, in fact I have followed the news since the first release but never used it in real cases (only testing). In the project I work, we have a few APIs, using OAuth2.0 and REST/JSON standards, and now we are gonna create a new API for real time purposes. After some research on Storm, XMPP, AMQP, WebSockets, SSE, etc. I'm feeling pretty confident ZeroMQ is the best way to make it, but I haven't seen anybody talking about it anywhere I searched for. So, the question is: is there any trap I can't see? Why nobody is talking about it? I know it's still a bit complicated to supply an HTTP/browser compatible API over ZeroMQ, but in this my case there's no need for HTTP/browser at all. ZeroMQ is not designed for access by third parties. Authentication, encryption, firewalls, and maliciously crafted packets are all problems you may face with having ZeroMQ as your point of entrance. If you want to use ZeroMQ internally (because it's awesome), you're best off gatewaying to the outside world through a standard protocol such as HTTP. The Mongrel2 and Zerogw web servers can be helpful in this case. Or you could do webhooks using Zurl. Disclaimer and self-promotion: I run fanout.io, a service that saves you the trouble of setting up this kind of thing. You might check it out. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] How do I send 0MQ messages via a WebSocket?
Look at zerogw or mongrel2. On Wednesday, January 23, 2013 02:06:45 PM crocket wrote: It turned out that people wouldn't control water plant facility from outside. So I won't need an encryption. But I still want to know if it's possible to connect or bind to a WebSocket. On Wed, Jan 23, 2013 at 1:58 PM, crocket crockabisc...@gmail.com wrote: It's possible that one of our customers might want to control precious machines(responsible for supplying clean water to many people) over the internet. In that case, I need some sort of a strong encryption mechanism. Since I don't know SSL/TLS handshake encryption and don't want to implement them in my app, an SSL WebSocket is desirable. Is it possible to send 0MQ messages via a WebSocket? ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Greetings questions about inproc PUB/SUB inside Twisted.
0mq makes some things practical or more efficient: - Messaging as a general form of development. Consider inproc workers. - A semi-standard way of interfacing between apps. Mongrel2 would be a lot less interesting if it required a broker, IMO. - MxN or mesh routings are relatively painless to set up and make for better sleep at night. The other messaging solutions have their advantages, too. Nothing wrong with many tools. On Saturday, January 26, 2013 09:57:39 PM Matthew Kaufman wrote: Regarding 0mq why can't developers just use standard messaging solutions like rabbit or apache mq what is so cool about 0mq? and yes i am being fully serious? On Sat, Jan 26, 2013 at 9:57 PM, Matthew Kaufman mkfmn...@gmail.com wrote: Ugh Zed Shaw is annoying lol. Hi Zed On Sat, Jan 26, 2013 at 2:56 PM, David J W zeromq-dev-subscr...@ominian.net wrote: Hello, My name is David W, I am a professional code monkey that was first introduced to 0MQ via Zed Shaw's talk at PyCon ( believe it was 2010 ) but only now have gotten the chance to sit down and start learning the library. I am on a sabbatical until ideal after PyCon since I got laid off and taking the time out to hit a bucket list ( including learning 0MQ ). On that note, a few years back as a re-invent the wheel project to learn Twisted and COMET I started writing a web MUD engine and centered the architecture around two message pipelines: User action's were locked stepped ( User A moved left, tell server, wait for it to say yes/no), broadcast to other User's that User A moved left, broadcast to all of User A's group they moved left. NPC's were just headless User's driven by a behavior time/tick subprocess that hooked upto the same pipelines.I set that project aside because I realized I needed a message queue of some sort and really didn't want to setup Rabbit or anything super industrial. Now along arrives 0MQ and since this is a personal project the priority is more about understanding how 0MQ works then accomplishing the actual project. In the above example I can imagine using 0mq's inproc socket's where client's are SUB types ( subscribe to map/domain, subscribe to group chat ) and their is a master process that has a router socket for incoming work and a pub socket for products [ User A in map 1 moved left] ). So here's my questions: For PUB/SUB the impression is that the actual queue sit's on the client socket. PUB pushes a message to all client's [ regardless of setsockopt(zmq.SUBSCRIBE ) ] and the act of reading the socket filter's/clears the queue down to what the client is subscribed to. Is this correct or is the subscription more intelligent ( PUB keep's a subscription roster, see's no one is subscribed, drop's the message OR client receives a message, isn't subscribed so it drops the message ). Has anyone had any experience running multiple SUB based client's inside of one process and are their any severe consequences. I imagine a SUB socket is going to instantiate the needed structures to hold a queue, the actual socket, and other house keeping structures but so far small tests (1-10 sockets) hasn't show much memory use. Additionally, if I do get past digging through 0MQ's mechanics, I was thinking it would be best to spin off the PUB side to it's only process. Which leads me to wonder if 0MQ inproc PUB/SUB actually relies on some clever memory mapping. eg Push a message on an inproc PUB socket which goes to a shared/mutex locked list and client's just read from this one list. Apologies if some of these questions seem naive, I haven't gotten the chance to read 0mq's C source code yet. Thanks, Dave ___ 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
Re: [zeromq-dev] Many to many
Bind vs connect is independent of socket type. You can bind a SUB socket and connect many PUB sockets to it. So, you could have each service bind a PUB socket and a SUB socket, and then connect each to all other services' SUB sockets and PUB sockets respectively. On Sunday, February 17, 2013 07:22:27 AM Lee Sylvester wrote: Thank you for your reply, Witney, but I need it the other way. I need a sub socket to be connected to multiple pub endpoints... This is because every instance will have a single publisher, telling all who is interested about events, but that same service will want to list to an arbitrary number of other services for their events. Essentially, I'd be forming a type of mesh, where each service has two endpoint (pub and sub) and all connect to all. I knew pub could connect to many, as it binds, but I'm guessing the subs cannot connect to many? Thanks loads, Lee Sent from my iPhone On 17 Feb 2013, at 05:18, Whitney Jackson whjack...@gmail.com wrote: Is it possible for a sub socket to bind to multiple pub sockets? Yes. You can call bind and/or connect on a socket as many times at you like. If so, where is there an example of this? Here's an example from the guide where a pub socket is bound to multiple endpoints: http://zguide.zeromq.org/page:all#Getting-the-Message-Out If you connect a sub socket to multiple endpoints then it gets a message whenever any of the publishers to which it's connected send. On Sat, Feb 16, 2013 at 4:18 PM, Lee Sylvester lee.sylves...@gmail.com wrote: Hey guys, So, I want to do a many to many pubsub. I already have a discovery mechanism and logging, but what I need is for a service to bind to a pub socket and subscribe to a set list of instances of itself on the server and other servers. The Zyre framework, although awesome, seems a little large for my needs as I already have a number of the features it supplies built in to my framework. Is it possible for a sub socket to bind to multiple pub sockets? If so, where is there an example of this? Can I also add a pub socket to listen to when all is already running? Thanks, Lee ___ 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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] do I need to create a context more then once?
On Monday, March 04, 2013 12:19:55 AM Peter Kleiweg wrote: I am writing a bindings library for ZeroMQ. I am thinking of hiding the creation and destroying of the context from the user. It would just create one context at start up of the program, use it for all sockets, and never destroy the context. What would be a reason to destroy the context? What would be a reason to open a second context? The reason contexts exist in libzmq is so that multiple libraries using libzmq within the same app don't step on each other's initialization. If you've ever tried to use a library with global state across libraries you know how annoying this would be otherwise. As a user of libzmq, though, you should not create multiple contexts. The facility exists only so that the code of many single-context users can coexist. Now, if you are designing a library of your own, it is probably a good idea to follow libzmq's model of not having a global state and instead require each user of your library to instantiate some kind of state/context/handle/etc in order to use it. In that case, each instantiation of your library could have its own libzmq context. How you decide this encapsulation is up to you, but in any case your library wouldn't be intentionally making multiple contexts of its own. For my qzmq binding, zmq contexts are directly exposed as an object. As a convenience, socket objects may be created without specifying a parent context, and in this case a global shared context is used. The global context is reference counted, and destroyed when the last socket is destroyed. This convenience is acceptable for applications, but libraries using qzmq should always create their own contexts. Justin___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Why socket.send will block without consumer
On Wednesday, March 20, 2013 12:14:09 PM He Jie Xu wrote: Hi, all I try zeromq with following code: import zmq import random import time context = zmq.Context() socket = context.socket(zmq.PUSH) socket.bind(ipc://test.sock) socket.setsockopt(zmq.HWM, 1000) while True: zipcode = random.randrange(1, 10) temperature = random.randrange(1, 215) message = %d %d % (zipcode, temperature) socket.send(message) print 'send', message time.sleep(1) When I am running the code without any consumer. it will block at 'socket.send' But after I read the document, I think when I set HWM, the message will send to memory buffer, it shouldn't block. Is there any wrong? How can I make the 'socket.send' won't block? my zmq version was 2.1.11 I will appreciate any help from you! This is one of the non-obvious aspects of zmq. Queues only exist when there are known connections (whether potential or established). For sockets that connect, the connections are known as you specify them. For sockets that bind, the connections are known only when they are received. Therefore, a bind socket that has no peers (no known connections) will block when you try to send. It's a little confusing because a connect socket that no peers will not block, meaning that the choice to bind or connect produces different behaviors. But it makes sense once you understand how the queues work. Justin___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] pushpin
Hi people, My Pushpin project seems to be getting a lot of attention on HackerNews: https://news.ycombinator.com/item?id=5516568 I just wanted to mention that under the hood it's a multiprocess ZeroMQ architecture. Thanks again for the nice lib. :) Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ZMTP 3.0 Status: Sharing Single TCP connection (Example code ?)
On 06/07/2013 02:02 PM, Pieter Hintjens wrote: On Fri, Jun 7, 2013 at 8:22 PM, Yannick Koehler yann...@koehler.name wrote: ZMTP doesn't allow multiplexing PUB/SUB and REQ/REP over the same single TCP connection simulteanously? I thought the Resource concept was about that. Yes, it will allow this. Libzmq doesn't implement that yet. However it doesn't change the fact you need a full ZMTP stack at both sides. If one side is libzmq and the other is a web server, you have a slight problem. Hmm, wouldn't multiplexing defeat the handy queuing back-pressure behavior provided by TCP? Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] http over zeromq spec
Hey people, I'm using zeromq to pipe streams of HTTP around, and recently I figured I ought to document what I'm doing: https://github.com/fanout/pushpin/blob/master/doc/zmq-http.md Maybe this spec could be used by other projects. Or not. I just figured I'd share it. FWIW, my Zurl project uses a protocol very similar to this and I'll be adjusting it to match soon. Also, I'm writing an adapter for Mongrel2. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] using REQ in a real application
Hi, I have a couple of concerns about using REQ. 1) In order to implement timeouts (which I'd think nearly every application should need), I use the following strategy: a) If I cannot write to the socket after enough time has passed, then I consider the request to have failed and I leave the socket in its current state. b) If I cannot read the response from the socket after enough time has passed, then I consider the request to have failed and I close and recreate the socket. I believe this socket resetting to be necessary so that the REQ state machine is willing to take writes again. Does this seem like the right way to go about timeouts? 2) What does the REQ socket do if it receives a message when it is not in a requesting state? My hope is that it would read messages and throw them away. If there's only exactly one read for every write, then I can envision a situation where the alignment is off and every request gets a wrongly matched response. Putting an id field on each request/response will help detect this, but it wouldn't get you unstuck. What can you say about this? Thanks. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] using REQ in a real application
On 07/18/2013 04:09 PM, Steven McCoy wrote: On 18 July 2013 16:43, Matt Connolly matt.conno...@me.com mailto:matt.conno...@me.com wrote: What is the correct way to handle the timeout? If the REQ socket is in the receive state, the only way it seems to me is to close the socket and make a new socket with a new connection. Is that right? Yes, REQ and REP are pretty much L-plate http://en.wikipedia.org/wiki/L-plate sockets but also incredibly useful for rapid prototyping of environments. Heading towards production you want to replace with DEALER and ROUTER to remove the fatal blocking states. If that's true, it's not something I recall being at all clear from the guide. It sounds like there are some fixes in the right direction on zmq master at least. Maybe having the state reset itself on every write would be enough for REQ to be used in production without any hacks. Also, I don't think there's any issue with REP is there? One could use REP for a server and DEALER for a client without any gotchas. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Router socket messages lost when too quick after connection and how to know if ready to send
On 07/25/2013 12:28 PM, Yannick Hold-Geoffroy wrote: Hello everyone, I've got two questions about router sockets. First, it seems I must wait for a while after connecting a router socket before sending data to its newly connected destination using pyzmq. This simple use case http://pastebin.com/kPK2ZAc5 shows the problem on my system using pyzmq 13.0.0 with zeromq 3.2.2 (Arch Linux, kernel 3.9.9, GCC 4.8.1): Most of the time it runs correctly and terminates, but sometimes it prints up to around 900 and stall there. Note that adding a sleep before sending (I tried with ~50ms) always make the code works. The router socket always exhibits its POLLOUT flag even if the connection isn't ready to send to a newly connected peer. Is there a way to ask the zeromq socket when it's ready to accept messages to a given host without dropping them, aside from manually specifying a sleep? My second question is about sending. Still using a router socket, you could set as destination anything you'd like (even if the socket isn't currently connected to a peer with this identity). Is there a way to know if a connection is currently available for sending (ie. the message will be sent immediately, like POLLOUT for a given peer)? I've tried setting the socket's ZMQ_SNDTIMEO to zero and try sending using the ZMQ_NOBLOCK to see if it would raise (in pyzmq) an ZMQ_EAGAIN error, but it always seems to pass without problem even when there is nobody listening. A minimal code exhibiting my comprehension of how it should work can be found here http://pastebin.com/zQE2Awt4. Is there something I haven't understood about how it's supposed to work? Hi Yannick, The simple answer is that ROUTER has a drop policy, not a blocking one. And there is not a way to know with pure 0mq whether or not there is a recipient available. That is something you would need to build on top. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] http over zeromq spec
On 06/17/2013 06:50 AM, Pieter Hintjens wrote: Hi Justin, This is pretty neat. If you want to make this a public document you should fix a few things. First, I'd recommend using the RFC 2119 language (SHOULD, MAY, MUST,...) Second, you need to license it in some way. I'd recommend a share-alike license that lets people extend your text but lets you reuse their changes. GPLv3 is what I prefer and would fit into your overall project license. Lastly, we have a website (rfc.zeromq.org) and process (developed by Digistan.org some time ago for microstandards) that is meant to make it easy for microstandards developers and users. This wiki site actually uses a GitHub project (https://github.com/zeromq/rfc) for its content. I think zmq-http is one of the first real protocols built on ZeroMQ (past the ones I churn out), which is awesome. Okay finally got around to submitting a pull request to the rfc repo. Spec isn't perfect and I didn't test the formatting (just blind converted from markdown to your wiki format). Any recommendation for how I can preview changes? In a follow up pass I can improve the actual text and use normative language, but for now I figured getting this live at all would be good. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ZMQ_WEBSOCKET - any work in progress?
On 08/09/2013 10:50 AM, Michael Haberler wrote: Am 27.06.2013 um 20:58 schrieb Pieter Hintjens p...@imatix.com: So ZMQ_STREAM is now a usable socket type for TCP clients and servers, and I've made a test case that shows simple a HTTP ping-pong, in tests/test_stream.cpp. I think it's a great idea! Is anybody planning/working on a similar idea for websockets (maybe using the libwebsockets.org code)? You could just use ZMQ_STREAM to talk to a websocket client/server. IMO, anything beyond what is supported by 0MQ should be the job of a gateway worker. Websockets would be in the realm of Mongrel2, ZeroGW, Zurl, etc. Even ZMQ_STREAM smells like feature creep (send and receive from a non-0MQ peer - what the what?). But everyone loves a good raw mode. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] wrong version number on website
Stable release 2.2.2 but the latest in that series is actually 2.2.0. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Client-side web applications with ZeroMQ
There's NullMQ, although I'm not sure of its status: https://github.com/progrium/nullmq In my opinion, all a web application really needs is request/response and pubsub, and you already have request/response in the form of HTTP. So, the only thing missing is a one-way (server-client) publish mechanism, and there are a number of ways to do that (Socket.io rooms, Faye, Pushpin, etc). Chaining socket.io's rooms stuff to a zeromq XSUB socket might be a nice afternoon project for you. :) On 11/20/2013 09:28 PM, Cosmo Harrigan wrote: Hello, Has there been much use of ZeroMQ with client-side web applications? For example, do you have any recommendations on a good implementation of a simple server that acts as a forwarder between ZeroMQ sockets and socket.io http://socket.io? (Kind of like https://github.com/sockjs/sockjs-client, but using socket.io http://socket.io) I see some such implementations on the web, but they seem old and not very active. Do you think this type of architecture is a good idea? Best regards, Cosmo Harrigan ___ 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
[zeromq-dev] thread affinity
Hi folks, What's the latest on the thread-safety of sockets? I know that normal 0MQ practice suggests not using a socket from multiple threads, but I wonder if this is nonetheless possible, for example by wrapping a mutex around access. The reason I ask is I'm exploring the possibility of using 0MQ in a hybrid event-driven threaded C++ environment (imagine something like Goroutines or .NET tasks). A socket would never be used by two threads simultaneously, but the thread on which a socket is utilized could change depending on how the eventing system dispatches work. For example, a task executing in one thread could go to sleep while it waits for a message and then wake up in a different thread when a message becomes available. I just want to confirm that this is a valid usage of 0MQ, before I do something that might not be possible or might get broken in a future release. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] thread affinity
On 11/30/2013 10:02 AM, Min RK wrote: On Nov 30, 2013, at 9:30, Justin Karneges jus...@affinix.com wrote: Great, it sounds like the answer to my question is that it is possible to use the same socket from different threads provided I do my own locking. That's perfectly workable. I mainly wanted to be sure there wasn't something in libzmq explicitly preventing this kind of usage. For example, I believe it is impossible to share a socket across threads with pyzmq, but this must be a limitation imposed in the binding rather than in libzmq. Pyzmq imposes no restrictions on how you use sockets, so it is perfectly possible to share them across threads using locks (or not, and just risk segfault). Good to hear. I could have sworn I hit some attempt to use socket from thread it wasn't created in exception when I tried to do it (even with locking) but it's been awhile so I could be mistaking things. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] pubsub subscription acknowledgement
Hi folks, Many realtime applications have a need to display past content as well as future changes to that content. For example, a news feed application might subscribe for news updates and then separately query for the most recent 20 news items for initial display. The order of operations is important. The subscription is established first so that there isn't a chance of losing data. In the worst case, data might be received twice (via the subscription and the history query), but the receiver can de-dup as necessary. The 0MQ guide has some strong opinions about how pubsub should be used: http://zguide.zeromq.org/page:all#Pros-and-Cons-of-Pub-Sub , and I'm not sure how to implement the pattern I described above while at the same time following the guide in its purest form. Naively, one could first set up a SUB and then do a REQ to query for past data, but the problem is that the application needs a way of knowing when the SUB socket is ready before performing the query. This problem is further complicated if the pubsub layer is tiered. The subscription shouldn't be considered ready until has gone all the way upstream. Here are a few ideas I've been thinking about: 1) If the transport allows bidirectional communication (e.g. TCP, but not PGM), then XPUB could be used on the publisher side to send down an ack whenever a subscription request arrives. If there are tiers, wait for upstream acks before sending acks downstream. 2) If PGM is used, the publisher should send heartbeats regularly. Receipt of any message means the subscription is functional. For this to work in a tiered architecture, the topmost publisher would need to send the heartbeats. However, this only works if the number of different subscriptions is minimal otherwise that's a lot of heartbeats. 3) Just sleep. Yeah, the guide considers this a hack but perhaps it is the most practical approach if you have tiers, pgm, and an unbounded number of subscription types. Regularly calculate network travel time between subscriber and topmost publisher, then sleep for however long that value is and call it done. Maybe there are other ideas? Thanks for any tips. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] What exact networking problems ZMQ does solve?
On 12/11/2013 11:07 AM, artemv zmq wrote: If the server goes down, and their is an established session, there is no way to know that without further communication, or no response where response is expected. If there is, I would love to know about it. I found a solution. There's a lib in java called netty. So they do next: in separate thread they poll existing channels on read operation (among others) and during this poll __they can__ detect that socket was focibly closed by remote peer. Ok? So they just poll for read and when things are connected polling on read returns an info akin to 0 bytes was read, so essentially, appl. treat this like nothing was read but channel is alive!. And that's it. What it gives? Before write operation we may know the status of channel. 0 bytes read is an indicator that it's alive. If got exception -- channel is closed, and all future operations on channel are cancelled. I'm wondering why ZMQ can't do something similar or even better? o_O If you establish a TCP connection to a remote system with netty, and then do ifdown on the remote system, you will not receive any indication of this and any messages you send to the remote system will be lost. If the connection stays down long enough, maybe around 20 minutes, then the local TCP stack will timeout the connection and netty will finally report an error to your application. TCP, and therefore any framework based upon it, does not instantly report delivery failure, and in general it is hard to figure out what was not delivered when you finally do receive an error. About the best you can do is use ioctl() with SIOCOUTQ to investigate your TCP queue. Your goal of knowing instantly if a message was not delivered is not possible without a very fast heartbeat system. One thing you can do is consider delivery to have failed if you don't have a TCP connection active (or if an attempt to establish a connection resulted in a connection refused error), but just be aware that this won't cover a case of the network dropping out, as in the case of ifdown, or if someone accidentally unplugs a network cable. The short answer is that 0MQ does not solve your exact problem. It does solve a bunch of other problems though. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Does ZMQ handle tcp-RST?
On 12/13/2013 04:12 AM, artemv zmq wrote: Is there a way to tell ZMQ to handle tcp-RST? If remote peer abruptly goes down OS kernel sends RST to client. Right? So, can ZMQ handle that, and stop collecting messages inside in-mem queue for the remote peer which is down. If a TCP connection is disconnected (due to RST or otherwise), then a ZeroMQ bind socket will destroy its queue with that connection and stop queueing, and a connect socket will retain its queue but stop sending until the connection is restored. If you want to prevent queuing in all cases, set HWM to 0. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] will receive fail if TCP goes down in REQ socket
ZeroMQ does not resend messages, so while the reconnect/queuing logic
will protect you to some degree, you still need to account for message loss.
If you're using REQ then you'll need to timeout the request, otherwise
if a request or response message is lost then you'll never be able to
make a request on the socket ever again. So don't just indefinitely
block on a send or receive. Further, ZeroMQ historically hasn't had a
way to get a REQ socket out of the waiting for response state in the
event of a timeout other than by closing the socket and starting over.
This means the REQ type is not really usable in production. Better to
use DEALER and format a REQ-compatible message yourself. REP does not
suffer from these problems, so you can keep on using that and have
DEALER talk to REP.
Note: it is possible that very recent versions of ZeroMQ allow REQ
sockets to revert state on error but I haven't been following this closely.
On 12/13/2013 04:17 PM, Sean Robertson wrote:
I believe the REQ will simply wait for the REP to come back up,
re-bind and send something.
On Fri, Dec 13, 2013 at 2:53 PM, Mohit Jaggi mohitja...@gmail.com wrote:
Hi,
In most ZMQ sockets, the underlying TCP socket can change transparently.
Does that apply to REQ-REP sockets as well? Or will the receive call to ZMQ
socket fail?
sock = new REQ socket;
connect(sock);
while(1) {
request = receive(...);
...
send(response);
}
For example in the above code, let us say that the server with REP socket on
the other side crashed and restarted. What will happen?
Thanks,
Mohit.
___
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
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] will receive fail if TCP goes down in REQ socket
Cool. Is there a reason the relaxed behavior is to close and reconnect
in order to reset the state? I'd think all you'd need to do here is
change a local state variable in the client and just reuse the same
connection. As it stands, I'd still want to roll my own REQ over a
DEALER socket unless I'm missing something.
On 12/13/2013 10:24 PM, Pieter Hintjens wrote:
The ZMQ_REQ_RELAXED option on ZeroMQ v4, lets you resend requests.
On Sat, Dec 14, 2013 at 3:46 AM, Justin Karneges jus...@affinix.com wrote:
ZeroMQ does not resend messages, so while the reconnect/queuing logic
will protect you to some degree, you still need to account for message loss.
If you're using REQ then you'll need to timeout the request, otherwise
if a request or response message is lost then you'll never be able to
make a request on the socket ever again. So don't just indefinitely
block on a send or receive. Further, ZeroMQ historically hasn't had a
way to get a REQ socket out of the waiting for response state in the
event of a timeout other than by closing the socket and starting over.
This means the REQ type is not really usable in production. Better to
use DEALER and format a REQ-compatible message yourself. REP does not
suffer from these problems, so you can keep on using that and have
DEALER talk to REP.
Note: it is possible that very recent versions of ZeroMQ allow REQ
sockets to revert state on error but I haven't been following this closely.
On 12/13/2013 04:17 PM, Sean Robertson wrote:
I believe the REQ will simply wait for the REP to come back up,
re-bind and send something.
On Fri, Dec 13, 2013 at 2:53 PM, Mohit Jaggi mohitja...@gmail.com wrote:
Hi,
In most ZMQ sockets, the underlying TCP socket can change transparently.
Does that apply to REQ-REP sockets as well? Or will the receive call to ZMQ
socket fail?
sock = new REQ socket;
connect(sock);
while(1) {
request = receive(...);
...
send(response);
}
For example in the above code, let us say that the server with REP socket
on
the other side crashed and restarted. What will happen?
Thanks,
Mohit.
___
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
___
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
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Can we customize a behaviour for in-mem queued messages after reconnect?
Yup. It's kind of ironic that TCP is viewed as a reliable protocol when in practice it barely provides it at all. What it does provide is automatic redelivery attempts which is quite handy, along with in-order delivery and flow control. These are great things, but an application desiring reliability will need to know about data receipt as well. HTTP, SMTP, SIP, XMPP, etc, all provide their own ways of indicating successful data receipt, independent of TCP. It's redundant, but it's the way of the world. On 12/20/2013 01:18 PM, Lindley French wrote: Yes and no. In general, yes, you're absolutely right. On the other hand, if you don't mind opening a new TCP connection for each transaction (not always ideal, but not always bad; it depends), then a successful TCP close is equivalent to a transaction ack. I'm starting to think a *lot* of reliability protocols built on top of TCP could be done more efficiently if TCP could expose some read-only information about its internal ACKing On Fri, Dec 20, 2013 at 4:13 PM, Stephen Hemminger step...@networkplumber.org mailto:step...@networkplumber.org wrote: On Fri, 20 Dec 2013 15:01:04 -0500 Lindley French lindl...@gmail.com mailto:lindl...@gmail.com wrote: The problem, in my view, is that normally you can trust TCP to get your packets through intact. Applications only know it made it to the socket queue, not that TCP ever sent it and got an acknowledgment or that the remote application got the message. To do reliable communication you need an end-to-end acknowledgment. This doesn't have to be on a per-packet basis but on a per-transaction basis. Think of what SCP/FTP do for file transfer. ___ 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
Re: [zeromq-dev] Send HTTP request and get response using ZeroMQ
On 01/05/2014 10:12 PM, Ravir Pandey wrote: Is there any way to send http request and get response from server. For Ex. - i want to send request to my http server http://341.23.43.21, after processing request i need a reply from same server. How can i achieve this? You can try using Zurl. It gateways REQ/REP to HTTP, using libcurl. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Send HTTP request and get response using ZeroMQ
Hi Ravir, You shouldn't need a PHP version of Zurl. Just run the daemon and then speak with it via ZeroMQ from any language. For reference, you can see tools/get.py which performs a GET request from Python. Fanout.io uses Zurl on its servers for various tasks, and we decided to open source the code in case others might find it useful. On 01/07/2014 11:33 PM, Ravir Pandey wrote: and one thing i want to know is what's the role of Fanout.io service in this? On Wed, Jan 8, 2014 at 12:45 PM, Ravir Pandey ravir.pan...@commusoft.co.uk mailto:ravir.pan...@commusoft.co.uk wrote: Hi Justin, I have gone through https://github.com/fanout/zurl. Sounds interesting. Is there any PHP version available? On Mon, Jan 6, 2014 at 11:33 PM, Justin Karneges jus...@affinix.com mailto:jus...@affinix.com wrote: On 01/05/2014 10:12 PM, Ravir Pandey wrote: Is there any way to send http request and get response from server. For Ex. - i want to send request to my http server http://341.23.43.21, after processing request i need a reply from same server. How can i achieve this? You can try using Zurl. It gateways REQ/REP to HTTP, using libcurl. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto: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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Send HTTP request and get response using ZeroMQ
Just connect to Zurl's REQ-handling endpoint (by default, tcp port 5553) and send a tnetstring-formatted message. You can find a tnetstring PHP library here: https://github.com/phuedx/tnetstring (note, I've not tried this, as I'm not a PHP developer). To make an HTTP request, send a message over the ZeroMQ socket with the following fields: id: a unique id for the request. could be a random number. method: the request method (e.g. GET) uri: the URL to request All of the above fields are string types. Zurl will then respond with a message containing the HTTP response. On 01/08/2014 10:41 PM, Ravir Pandey wrote: I am not familiar with python :( Can you please explain a little bit? On Thu, Jan 9, 2014 at 2:02 AM, Justin Karneges jus...@affinix.com mailto:jus...@affinix.com wrote: Hi Ravir, You shouldn't need a PHP version of Zurl. Just run the daemon and then speak with it via ZeroMQ from any language. For reference, you can see tools/get.py which performs a GET request from Python. Fanout.io uses Zurl on its servers for various tasks, and we decided to open source the code in case others might find it useful. On 01/07/2014 11:33 PM, Ravir Pandey wrote: and one thing i want to know is what's the role of Fanout.io service in this? On Wed, Jan 8, 2014 at 12:45 PM, Ravir Pandey ravir.pan...@commusoft.co.uk mailto:ravir.pan...@commusoft.co.uk mailto:ravir.pan...@commusoft.co.uk mailto:ravir.pan...@commusoft.co.uk wrote: Hi Justin, I have gone through https://github.com/fanout/zurl. Sounds interesting. Is there any PHP version available? On Mon, Jan 6, 2014 at 11:33 PM, Justin Karneges jus...@affinix.com mailto:jus...@affinix.com mailto:jus...@affinix.com mailto:jus...@affinix.com wrote: On 01/05/2014 10:12 PM, Ravir Pandey wrote: Is there any way to send http request and get response from server. For Ex. - i want to send request to my http server http://341.23.43.21, after processing request i need a reply from same server. How can i achieve this? You can try using Zurl. It gateways REQ/REP to HTTP, using libcurl. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto: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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Send HTTP request and get response using ZeroMQ
Oh, and the message you send must be prefixed with a capital 'T' character. Byte 0 is a T, and byte 1 is the start of the tnetstring-formatted payload. On 01/09/2014 01:26 AM, Justin Karneges wrote: Just connect to Zurl's REQ-handling endpoint (by default, tcp port 5553) and send a tnetstring-formatted message. You can find a tnetstring PHP library here: https://github.com/phuedx/tnetstring (note, I've not tried this, as I'm not a PHP developer). To make an HTTP request, send a message over the ZeroMQ socket with the following fields: id: a unique id for the request. could be a random number. method: the request method (e.g. GET) uri: the URL to request All of the above fields are string types. Zurl will then respond with a message containing the HTTP response. On 01/08/2014 10:41 PM, Ravir Pandey wrote: I am not familiar with python :( Can you please explain a little bit? On Thu, Jan 9, 2014 at 2:02 AM, Justin Karneges jus...@affinix.com mailto:jus...@affinix.com wrote: Hi Ravir, You shouldn't need a PHP version of Zurl. Just run the daemon and then speak with it via ZeroMQ from any language. For reference, you can see tools/get.py which performs a GET request from Python. Fanout.io uses Zurl on its servers for various tasks, and we decided to open source the code in case others might find it useful. On 01/07/2014 11:33 PM, Ravir Pandey wrote: and one thing i want to know is what's the role of Fanout.io service in this? On Wed, Jan 8, 2014 at 12:45 PM, Ravir Pandey ravir.pan...@commusoft.co.uk mailto:ravir.pan...@commusoft.co.uk mailto:ravir.pan...@commusoft.co.uk mailto:ravir.pan...@commusoft.co.uk wrote: Hi Justin, I have gone through https://github.com/fanout/zurl. Sounds interesting. Is there any PHP version available? On Mon, Jan 6, 2014 at 11:33 PM, Justin Karneges jus...@affinix.com mailto:jus...@affinix.com mailto:jus...@affinix.com mailto:jus...@affinix.com wrote: On 01/05/2014 10:12 PM, Ravir Pandey wrote: Is there any way to send http request and get response from server. For Ex. - i want to send request to my http server http://341.23.43.21, after processing request i need a reply from same server. How can i achieve this? You can try using Zurl. It gateways REQ/REP to HTTP, using libcurl. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto: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 ___ 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
Re: [zeromq-dev] Linux: Qt support with ZeroMQ..
There are a few options: https://github.com/wttw/zeromqt https://github.com/jonnydee/nzmqt https://github.com/jkarneges/qzmq It sounds like you've downloaded zeromqt. The project should contain README.markdown. I am the author of QZmq and can help with it if you'd like. On 01/26/2014 11:11 PM, Rahul Mathur wrote: I am newbie and looking for Qt support with ZeroMQ on Linux for desktop application. Can I have some links to perform below - 1. Qt bindings support to ZeroMQ 2. Installation 3. Executing ZeroMQ PUB-SUB with Qt enabled user inputs on it's GUI. I do have zermqt-master.zip file but it has missing README or INSTALLATION steps to execute Qt enabled zeromq. Thanks ___ 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
Re: [zeromq-dev] Linux: Qt support with ZeroMQ..
Hi Goswin, On 01/27/2014 03:46 AM, Goswin von Brederlow wrote: On Sun, Jan 26, 2014 at 11:34:13PM -0800, Justin Karneges wrote: There are a few options: https://github.com/wttw/zeromqt https://github.com/jonnydee/nzmqt https://github.com/jkarneges/qzmq It sounds like you've downloaded zeromqt. The project should contain README.markdown. I am the author of QZmq and can help with it if you'd like. Can you give a few words of what makes each of them good or bad please? Why did you start your own project instead of using on of the other two? It's been a year and a half since I created QZmq, so I cannot remember the exact reason, but I believe it was because neither Zeromqt nor Nzmqt supported fully event-driven reads and writes (at least at the time), and I didn't agree with the headers-only style of development used by Nzmqt so I thought I'd try my own rather than contribute. So the advantage of QZmq is it supports write notifications, and it also includes a Valve class which makes it easy to implement backpressure. Probably one should choose between Nzmqt or QZmq. I believe Zeromqt has gone unmaintained, and its own documentation suggests uses Nzmqt instead. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Linux: Qt support with ZeroMQ..
Mapping ZeroMQ sockets to Qt signals/slots would be wild. :) None of the existing libs attempt anything like this. I'd have to think more about the use cases. On 01/27/2014 01:39 PM, Lindley French wrote: Question: One of the drawbacks of QT's signals and slots mechanism (which is otherwise great) is that it supports many-to-one (like ZMQ pull or sub) and one-to-many (like ZMQ pub), but it does't support one-to-any (like ZMQ push). Is there anything in any of these projects that addresses this in any way by merging the QT and ZMQ functionality somehow? On Mon, Jan 27, 2014 at 2:00 PM, Justin Karneges jus...@affinix.com mailto:jus...@affinix.com wrote: Hi Goswin, On 01/27/2014 03:46 AM, Goswin von Brederlow wrote: On Sun, Jan 26, 2014 at 11:34:13PM -0800, Justin Karneges wrote: There are a few options: https://github.com/wttw/zeromqt https://github.com/jonnydee/nzmqt https://github.com/jkarneges/qzmq It sounds like you've downloaded zeromqt. The project should contain README.markdown. I am the author of QZmq and can help with it if you'd like. Can you give a few words of what makes each of them good or bad please? Why did you start your own project instead of using on of the other two? It's been a year and a half since I created QZmq, so I cannot remember the exact reason, but I believe it was because neither Zeromqt nor Nzmqt supported fully event-driven reads and writes (at least at the time), and I didn't agree with the headers-only style of development used by Nzmqt so I thought I'd try my own rather than contribute. So the advantage of QZmq is it supports write notifications, and it also includes a Valve class which makes it easy to implement backpressure. Probably one should choose between Nzmqt or QZmq. I believe Zeromqt has gone unmaintained, and its own documentation suggests uses Nzmqt instead. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto: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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] ROUTER not routing?
Hi, 1) ROUTER in program A is set to connect to a bind socket in program B. 2) Both programs are started, and the connection is established. 3) A determines B's socket identity out-of-band, and is able to send messages to B. 3) B is terminated and the connection is lost. 4) B is started again, and the connection is re-established. 5) A determines B's socket identity out-of-band, and is no longer able to send messages to B. It seems this problem does not happen if B retains the same socket identity across reconnects. However, if it uses a random identity (to be discovered out-of-band by A), then routing will never work again after the first restart of B. The A program must be restarted in order to make things right again. My guess is that each connect queue on a ROUTER socket is somehow bound for life against the first identity it sees. Is this intentional behavior? Thanks, Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER not routing?
Yes, when B is run again, it creates a new bind socket. A's connect socket will then reconnect to it. B does not care what the identity is of A's socket, so I think this is not a problem. For example, I can restart A repeatedly and all is fine. On 02/07/2014 01:06 PM, Ahmet Kakıcı wrote: I think you are creating new socket at step 4, then Router will assign new socket identites to incoming peers. https://github.com/zeromq/libzmq/blob/9c6aa1e9e00ab11a1c716e1fd2f1c56030972e30/src/router.cpp#L437 That's why you cannot send replies to a client with same identity. On Fri, Feb 7, 2014 at 10:51 PM, Justin Karneges jus...@affinix.com mailto:jus...@affinix.com wrote: Hi, 1) ROUTER in program A is set to connect to a bind socket in program B. 2) Both programs are started, and the connection is established. 3) A determines B's socket identity out-of-band, and is able to send messages to B. 3) B is terminated and the connection is lost. 4) B is started again, and the connection is re-established. 5) A determines B's socket identity out-of-band, and is no longer able to send messages to B. It seems this problem does not happen if B retains the same socket identity across reconnects. However, if it uses a random identity (to be discovered out-of-band by A), then routing will never work again after the first restart of B. The A program must be restarted in order to make things right again. My guess is that each connect queue on a ROUTER socket is somehow bound for life against the first identity it sees. Is this intentional behavior? ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER not routing?
It is my understanding that being able to route requires the socket to have an identity mapping in its routing table for the peer. For peers that do not explicitly specify their own identity, then I believe you are correct that routing is not possible until at least one message has been received from the peer. It is at this point that the ROUTER socket will make up an identity for this peer and store it in its routing table. However, for peers that *do* explicitly specify their own identity (as I am doing), then this identity information is delivered immediately after the connection is established, allowing routing to the peer even if the peer has not sent a message yet. I should have been more clear in my original message. The B program is explicitly specifying a random UUID as the identity of its socket before binding. On 02/07/2014 02:06 PM, Panu Wetterstrand wrote: I did not quite get the problem but could this be because (I think) router is not able to route messages to socket from which it has not reveived data first... 7.2.2014 22.51 kirjoitti Justin Karneges jus...@affinix.com mailto:jus...@affinix.com: Hi, 1) ROUTER in program A is set to connect to a bind socket in program B. 2) Both programs are started, and the connection is established. 3) A determines B's socket identity out-of-band, and is able to send messages to B. 3) B is terminated and the connection is lost. 4) B is started again, and the connection is re-established. 5) A determines B's socket identity out-of-band, and is no longer able to send messages to B. It seems this problem does not happen if B retains the same socket identity across reconnects. However, if it uses a random identity (to be discovered out-of-band by A), then routing will never work again after the first restart of B. The A program must be restarted in order to make things right again. My guess is that each connect queue on a ROUTER socket is somehow bound for life against the first identity it sees. Is this intentional behavior? Thanks, Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto: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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER not routing?
Here's some small sample code to reproduce the issue: https://gist.github.com/jkarneges/ab2b1abea1ee4cfc1332 A (ztest1.py) creates REQ and ROUTER sockets. B (ztest2.py) creates REP and ROUTER sockets. B binds and provides a random identity to its ROUTER socket. A connects its sockets to B. A queries for B's id using the REQ socket, and then attempts to send a message via the ROUTER socket right after that. This is repeated every 2 seconds. A and B can be started in any order. A can be restarted and things will still work. If B is restarted, then A's ROUTER socket will never work again until A is restarted also. A uses ZMQ_ROUTER_MANDATORY to show that the failures are on A's side. On 02/07/2014 02:16 PM, Justin Karneges wrote: It is my understanding that being able to route requires the socket to have an identity mapping in its routing table for the peer. For peers that do not explicitly specify their own identity, then I believe you are correct that routing is not possible until at least one message has been received from the peer. It is at this point that the ROUTER socket will make up an identity for this peer and store it in its routing table. However, for peers that *do* explicitly specify their own identity (as I am doing), then this identity information is delivered immediately after the connection is established, allowing routing to the peer even if the peer has not sent a message yet. I should have been more clear in my original message. The B program is explicitly specifying a random UUID as the identity of its socket before binding. On 02/07/2014 02:06 PM, Panu Wetterstrand wrote: I did not quite get the problem but could this be because (I think) router is not able to route messages to socket from which it has not reveived data first... 7.2.2014 22.51 kirjoitti Justin Karneges jus...@affinix.com mailto:jus...@affinix.com: Hi, 1) ROUTER in program A is set to connect to a bind socket in program B. 2) Both programs are started, and the connection is established. 3) A determines B's socket identity out-of-band, and is able to send messages to B. 3) B is terminated and the connection is lost. 4) B is started again, and the connection is re-established. 5) A determines B's socket identity out-of-band, and is no longer able to send messages to B. It seems this problem does not happen if B retains the same socket identity across reconnects. However, if it uses a random identity (to be discovered out-of-band by A), then routing will never work again after the first restart of B. The A program must be restarted in order to make things right again. My guess is that each connect queue on a ROUTER socket is somehow bound for life against the first identity it sees. Is this intentional behavior? Thanks, Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto: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 ___ 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
Re: [zeromq-dev] ROUTER not routing?
Here's an even simpler example using REQ/ROUTER: https://gist.github.com/jkarneges/1fa64e9763561f53daef It doesn't demonstrate the routing problem but it does demonstrate the identity binding oddity. You can see the ROUTER side that the envelope id is always the first id it has ever seen, even if the id printed by the REQ side is different every time. On 02/07/2014 02:33 PM, Justin Karneges wrote: Here's some small sample code to reproduce the issue: https://gist.github.com/jkarneges/ab2b1abea1ee4cfc1332 A (ztest1.py) creates REQ and ROUTER sockets. B (ztest2.py) creates REP and ROUTER sockets. B binds and provides a random identity to its ROUTER socket. A connects its sockets to B. A queries for B's id using the REQ socket, and then attempts to send a message via the ROUTER socket right after that. This is repeated every 2 seconds. A and B can be started in any order. A can be restarted and things will still work. If B is restarted, then A's ROUTER socket will never work again until A is restarted also. A uses ZMQ_ROUTER_MANDATORY to show that the failures are on A's side. On 02/07/2014 02:16 PM, Justin Karneges wrote: It is my understanding that being able to route requires the socket to have an identity mapping in its routing table for the peer. For peers that do not explicitly specify their own identity, then I believe you are correct that routing is not possible until at least one message has been received from the peer. It is at this point that the ROUTER socket will make up an identity for this peer and store it in its routing table. However, for peers that *do* explicitly specify their own identity (as I am doing), then this identity information is delivered immediately after the connection is established, allowing routing to the peer even if the peer has not sent a message yet. I should have been more clear in my original message. The B program is explicitly specifying a random UUID as the identity of its socket before binding. On 02/07/2014 02:06 PM, Panu Wetterstrand wrote: I did not quite get the problem but could this be because (I think) router is not able to route messages to socket from which it has not reveived data first... 7.2.2014 22.51 kirjoitti Justin Karneges jus...@affinix.com mailto:jus...@affinix.com: Hi, 1) ROUTER in program A is set to connect to a bind socket in program B. 2) Both programs are started, and the connection is established. 3) A determines B's socket identity out-of-band, and is able to send messages to B. 3) B is terminated and the connection is lost. 4) B is started again, and the connection is re-established. 5) A determines B's socket identity out-of-band, and is no longer able to send messages to B. It seems this problem does not happen if B retains the same socket identity across reconnects. However, if it uses a random identity (to be discovered out-of-band by A), then routing will never work again after the first restart of B. The A program must be restarted in order to make things right again. My guess is that each connect queue on a ROUTER socket is somehow bound for life against the first identity it sees. Is this intentional behavior? Thanks, Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto: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 ___ 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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER not routing?
I'd like to move forward with fixing this. Can I get a confirmation that I should proceed? Basically I want to make it so if a connection reconnects, and an explicit identity is received from the peer, then it should overwrite any previously set identity for that peer. Also I tried to log an item in the Jira but I'm not sure how. Maybe I need special access rights? I created an account at least. Also, I see issues in github too. Which is the right place to log things? Thanks. On 02/08/2014 11:53 AM, Justin Karneges wrote: Here's an even simpler example using REQ/ROUTER: https://gist.github.com/jkarneges/1fa64e9763561f53daef It doesn't demonstrate the routing problem but it does demonstrate the identity binding oddity. You can see the ROUTER side that the envelope id is always the first id it has ever seen, even if the id printed by the REQ side is different every time. On 02/07/2014 02:33 PM, Justin Karneges wrote: Here's some small sample code to reproduce the issue: https://gist.github.com/jkarneges/ab2b1abea1ee4cfc1332 A (ztest1.py) creates REQ and ROUTER sockets. B (ztest2.py) creates REP and ROUTER sockets. B binds and provides a random identity to its ROUTER socket. A connects its sockets to B. A queries for B's id using the REQ socket, and then attempts to send a message via the ROUTER socket right after that. This is repeated every 2 seconds. A and B can be started in any order. A can be restarted and things will still work. If B is restarted, then A's ROUTER socket will never work again until A is restarted also. A uses ZMQ_ROUTER_MANDATORY to show that the failures are on A's side. On 02/07/2014 02:16 PM, Justin Karneges wrote: It is my understanding that being able to route requires the socket to have an identity mapping in its routing table for the peer. For peers that do not explicitly specify their own identity, then I believe you are correct that routing is not possible until at least one message has been received from the peer. It is at this point that the ROUTER socket will make up an identity for this peer and store it in its routing table. However, for peers that *do* explicitly specify their own identity (as I am doing), then this identity information is delivered immediately after the connection is established, allowing routing to the peer even if the peer has not sent a message yet. I should have been more clear in my original message. The B program is explicitly specifying a random UUID as the identity of its socket before binding. On 02/07/2014 02:06 PM, Panu Wetterstrand wrote: I did not quite get the problem but could this be because (I think) router is not able to route messages to socket from which it has not reveived data first... 7.2.2014 22.51 kirjoitti Justin Karneges jus...@affinix.com mailto:jus...@affinix.com: Hi, 1) ROUTER in program A is set to connect to a bind socket in program B. 2) Both programs are started, and the connection is established. 3) A determines B's socket identity out-of-band, and is able to send messages to B. 3) B is terminated and the connection is lost. 4) B is started again, and the connection is re-established. 5) A determines B's socket identity out-of-band, and is no longer able to send messages to B. It seems this problem does not happen if B retains the same socket identity across reconnects. However, if it uses a random identity (to be discovered out-of-band by A), then routing will never work again after the first restart of B. The A program must be restarted in order to make things right again. My guess is that each connect queue on a ROUTER socket is somehow bound for life against the first identity it sees. Is this intentional behavior? Thanks, Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org mailto: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 ___ 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 ___ 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
Re: [zeromq-dev] ROUTER not routing?
The new peer asserts its own identity. There is not a question about whether the new peer is the same as before. The peer very clearly is or is not the same, based on the identity it provides. The problem is that remote identities are only honored for the first peer. On 02/13/2014 03:00 PM, Ahmet Kakıcı wrote: It's not about zmq, just imagine someone comes to you and you say him you are x, after he left someone came too, so without his identity how will you decide if he is the same person or not? On Fri, Feb 14, 2014 at 12:51 AM, Justin Karneges jus...@affinix.com mailto:jus...@affinix.com wrote: I'd like to move forward with fixing this. Can I get a confirmation that I should proceed? Basically I want to make it so if a connection reconnects, and an explicit identity is received from the peer, then it should overwrite any previously set identity for that peer. Also I tried to log an item in the Jira but I'm not sure how. Maybe I need special access rights? I created an account at least. Also, I see issues in github too. Which is the right place to log things? Thanks. On 02/08/2014 11:53 AM, Justin Karneges wrote: Here's an even simpler example using REQ/ROUTER: https://gist.github.com/jkarneges/1fa64e9763561f53daef It doesn't demonstrate the routing problem but it does demonstrate the identity binding oddity. You can see the ROUTER side that the envelope id is always the first id it has ever seen, even if the id printed by the REQ side is different every time. On 02/07/2014 02:33 PM, Justin Karneges wrote: Here's some small sample code to reproduce the issue: https://gist.github.com/jkarneges/ab2b1abea1ee4cfc1332 A (ztest1.py) creates REQ and ROUTER sockets. B (ztest2.py) creates REP and ROUTER sockets. B binds and provides a random identity to its ROUTER socket. A connects its sockets to B. A queries for B's id using the REQ socket, and then attempts to send a message via the ROUTER socket right after that. This is repeated every 2 seconds. A and B can be started in any order. A can be restarted and things will still work. If B is restarted, then A's ROUTER socket will never work again until A is restarted also. A uses ZMQ_ROUTER_MANDATORY to show that the failures are on A's side. On 02/07/2014 02:16 PM, Justin Karneges wrote: It is my understanding that being able to route requires the socket to have an identity mapping in its routing table for the peer. For peers that do not explicitly specify their own identity, then I believe you are correct that routing is not possible until at least one message has been received from the peer. It is at this point that the ROUTER socket will make up an identity for this peer and store it in its routing table. However, for peers that *do* explicitly specify their own identity (as I am doing), then this identity information is delivered immediately after the connection is established, allowing routing to the peer even if the peer has not sent a message yet. I should have been more clear in my original message. The B program is explicitly specifying a random UUID as the identity of its socket before binding. On 02/07/2014 02:06 PM, Panu Wetterstrand wrote: I did not quite get the problem but could this be because (I think) router is not able to route messages to socket from which it has not reveived data first... 7.2.2014 22.51 kirjoitti Justin Karneges jus...@affinix.com mailto:jus...@affinix.com mailto:jus...@affinix.com mailto:jus...@affinix.com: Hi, 1) ROUTER in program A is set to connect to a bind socket in program B. 2) Both programs are started, and the connection is established. 3) A determines B's socket identity out-of-band, and is able to send messages to B. 3) B is terminated and the connection is lost. 4) B is started again, and the connection is re-established. 5) A determines B's socket identity out-of-band, and is no longer able to send messages to B. It seems this problem does not happen if B retains the same socket identity across reconnects. However, if it uses a random identity (to be discovered out-of-band by A), then routing will never work again after the first restart of B. The A program must be restarted in order to make things right again. My guess
Re: [zeromq-dev] ROUTER not routing?
Having the local socket tell the remote peer about the mapping it has
created seems very roundabout. How about just allowing the mapping in
the local socket to be replaced anytime identity information is received
from the remote peer?
I don't know how this works at the ZMTP level, but I assume that
explicit identities are traded (if set on either side) at every
connect/reconnect. I also assume that if the local socket receives
identity information from a remote peer for which it already has a
mapping, then it ignores the data. If these assumptions are true, then
the solution is for the local socket to not ignore subsequent identity
data and instead modify its mapping.
Am I wrong in my assumptions?
On 02/14/2014 12:50 AM, Laurent Alebarde wrote:
The existing IDENTITY socket option is useless for your purpose because
it is transmitted at the end of the handcheck in the metadata. When a
ROUTER receives a new connection, it assigns to it a own forged identity
(random for the first peer and then incremented for the next ones). It
is a 5 bytes blob, the first one is always zero, the 4 others are mapped
to a int.
So, when the peer reconnects, it is seen as a new peer and the handcheck
is reprocessed, whatever you do with the IDENTITY option. IMHO, I don't
see any use case for this option.
So, the only way I foresee is to have the ROUTER transmit to its peer
the identity it has assigned to it. The best place I think is in the
greeting's feeler: 31 bytes available not used (cf ZMTP). On the peer
side, before it reconnects, it shall set a new identity option you shall
add to libzmq, with the value previously retrieved.
So, you should have one option used by the ROUTER, both to transmit the
assign 5 bytes identity to the peer in the greeting's filler, and to get
the one transmitted by the peer To have it work, use 6 bytes in the
filler, one would be a validity flag, because it wouldn't be a good idea
that the peer transmit an identity of its own, to avoid collisions. So
first time it connects, the blob is {0, 0, 0, 0, 0, 0}. ROUTER will send
say {1, 0, 5, 240, 72, 13}. Peer will have to send {2, 0, 5, 240, 72,
13}when it reconnects. It is better to differentiate how the blob has to
be interpreted. 0: not valid, do nothing, 1: here is how I have
identified you, 2: I reconnect, please use this to identify me. This
would be necessary in the case of ROUTER-ROUTER, and ease greatly the
use of this architecture.
And you should have one option to be used by the peer to retrieve and
resend the identity at the next connexion.
Hope it helps,
Laurent.
Le 13/02/2014 23:51, Justin Karneges a écrit :
I'd like to move forward with fixing this. Can I get a confirmation that
I should proceed? Basically I want to make it so if a connection
reconnects, and an explicit identity is received from the peer, then it
should overwrite any previously set identity for that peer.
Also I tried to log an item in the Jira but I'm not sure how. Maybe I
need special access rights? I created an account at least. Also, I see
issues in github too. Which is the right place to log things?
Thanks.
On 02/08/2014 11:53 AM, Justin Karneges wrote:
Here's an even simpler example using REQ/ROUTER:
https://gist.github.com/jkarneges/1fa64e9763561f53daef
It doesn't demonstrate the routing problem but it does demonstrate the
identity binding oddity. You can see the ROUTER side that the envelope
id is always the first id it has ever seen, even if the id printed by
the REQ side is different every time.
On 02/07/2014 02:33 PM, Justin Karneges wrote:
Here's some small sample code to reproduce the issue:
https://gist.github.com/jkarneges/ab2b1abea1ee4cfc1332
A (ztest1.py) creates REQ and ROUTER sockets. B (ztest2.py) creates REP
and ROUTER sockets. B binds and provides a random identity to its ROUTER
socket. A connects its sockets to B. A queries for B's id using the REQ
socket, and then attempts to send a message via the ROUTER socket right
after that. This is repeated every 2 seconds.
A and B can be started in any order. A can be restarted and things will
still work. If B is restarted, then A's ROUTER socket will never work
again until A is restarted also.
A uses ZMQ_ROUTER_MANDATORY to show that the failures are on A's side.
On 02/07/2014 02:16 PM, Justin Karneges wrote:
It is my understanding that being able to route requires the socket to
have an identity mapping in its routing table for the peer.
For peers that do not explicitly specify their own identity, then I
believe you are correct that routing is not possible until at least one
message has been received from the peer. It is at this point that the
ROUTER socket will make up an identity for this peer and store it in its
routing table.
However, for peers that *do* explicitly specify their own identity (as I
am doing), then this identity information is delivered immediately after
the connection is established
Re: [zeromq-dev] ROUTER not routing?
On 02/13/2014 02:51 PM, Justin Karneges wrote: Also I tried to log an item in the Jira but I'm not sure how. Maybe I need special access rights? I created an account at least. Also, I see issues in github too. Which is the right place to log things? Still hoping to get clarification on this. FWIW I was looking here: http://zeromq.org/docs:contributing Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] How to file an issue? (was: ROUTER not routing?)
On 02/19/2014 11:26 PM, Justin Karneges wrote: On 02/13/2014 02:51 PM, Justin Karneges wrote: Also I tried to log an item in the Jira but I'm not sure how. Maybe I need special access rights? I created an account at least. Also, I see issues in github too. Which is the right place to log things? Still hoping to get clarification on this. FWIW I was looking here: http://zeromq.org/docs:contributing New subject and bump. ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] How to file an issue?
Great. Btw, the page still links to Jira in step #1. On 02/25/2014 01:15 PM, Pieter Hintjens wrote: Justin, Thanks for the bump. That page was out of date, I've fixed it. We do all issue tracking on GitHub now (the number of pull requests finally exceeded the number of old issues so we didn't have numbering problems.) -Pieter On Tue, Feb 25, 2014 at 9:28 PM, Justin Karneges jus...@affinix.com wrote: On 02/19/2014 11:26 PM, Justin Karneges wrote: On 02/13/2014 02:51 PM, Justin Karneges wrote: Also I tried to log an item in the Jira but I'm not sure how. Maybe I need special access rights? I created an account at least. Also, I see issues in github too. Which is the right place to log things? Still hoping to get clarification on this. FWIW I was looking here: http://zeromq.org/docs:contributing New subject and bump. ___ 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 ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Task queues using ZeroMQ and inproc
If you're using C++, you should be able to get away with using smart pointer approaches. I'm personally using Qt which has the best smart pointer approach I've ever seen (QSharedData). I use inproc sockets to send/recv pointers, but the application only has to deal with value objects. It's some wild C++ voodoo. On 03/11/2014 03:25 PM, Cosmo Harrigan wrote: Hi, If an application is using ZeroMQ exclusively as a concurrency framework, and only using inproc sockets, and the goal is to implement a task parallelism abstraction like the ventilator/sink pattern, is there any way to avoid the overhead involved in object serialization and deserialization that is involved since the approach is no longer using a shared memory model with pointers to the objects? I see there was a similar discussion previously: http://comments.gmane.org/gmane.network.zeromq.devel/7300 which suggested passing object pointers as messages over inproc. However, I am also concerned that if you do that, you're giving up one of the main benefits of using message passing, since once again you have the potential for multiple threads to share state. I also understand that you're restricting yourself from scaling to additional machines. Also, Pieter had commented don't pass pointers around here: http://osdir.com/ml/zermq-development/2013-05/msg00104.html What are common approaches to address this scenario? Thanks, Cosmo ___ 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
Re: [zeromq-dev] Router-Router Reconnection Issue
On 06/03/2014 02:13 PM, Jeremy Im wrote: We're using 0mq to great success, but we've run into a problem in using router-router connections; we are using explicit socket identities so that we can perform addressing from a single 0mq socket (e.g. on the client, we will connect to multiple servers by calling zmq_connect multiple times, and put the socket identity of the desired target server). The issue we are running into is when the server is taken offline, then brought back online, the client can no longer communicate with it. Possibly the same bug I reported back in Feb: http://lists.zeromq.org/pipermail/zeromq-dev/2014-February/025202.html I haven't had time lately to look into a solution though. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] PUB/SUB unreliabiliity
Pubsub is by definition unreliable since messages are dropped if there are no subscribers. An argument could be made that ZeroMQ ought to support a reliable reconnection for known subscribers, so that temporary disconnects between publisher and subscriber don't result in any lost messages. However, the key here is temporary. If a subscriber remains disconnected for a very long time, then the question becomes how long should the publisher queue messages for a lost subscriber. And unless the answer is for all time, then, well... you still have unreliability. So, because subscribers may or may not exist at the time of publish, and because you'll never have an infinite queue, it's best to just assume that pubsub isn't reliable. Build reliability around it. Some philosophy: http://zguide.zeromq.org/page:all#Pros-and-Cons-of-Pub-Sub On 06/15/2014 04:43 AM, Gerry Steele wrote: Thanks Charles, that's pretty much my understanding too. Meaning this is a bug in my implementation or in zeromq. I understand the implications of the slow consumer problem but the fundamental issue here is to establish trust in PUB/SUB. On 14 June 2014 21:09, Charles Remes li...@chuckremes.com mailto:li...@chuckremes.com wrote: Let’s back up for a second. Take a look at the man page for zmq_setsockopt and read the section on ZMQ_SNDHWM. It clearly states that zero means “no limit.” Second, it also states that when the socket reaches its exceptional state then it will either block or drop messages depending on socket type. Next, look at the man page for zmq_socket and check the ZMQ_PUB section. The socket will reach its mute state (its exceptional state) when it reaches it high water mark. When it’s mute, it will drop messages. So, taking the two together then a socket with a ZMQ_SNDHWM of 0 should never drop messages because it will never reach its mute state. The one exception to this is when there are no SUB sockets connected to the PUB socket. When there are no connections, all messages are dropped (because no one is listening and there are no queues created). However, I highly recommend *against* setting HWM to 0 for a PUB socket. Here’s why: 1. It gives you a false sense of security that all messages will be delivered. If the publishing process dies, any messages in queue go with it so they’ll never get delivered. 2. Your subscribers might be too slow. If your subscribers can’t keep up with the message flow and the publisher starts queueing, it *will* run out of memory. You’ll either exhaust the amount of memory allowed by your process, or your OS will start paging swapping and you’ll wish the process had just died. cr On Jun 13, 2014, at 5:34 PM, Gerry Steele gerry.ste...@gmail.com mailto:gerry.ste...@gmail.com wrote: Hi Brian I noticed your comment on another thread about this and I think you got it a bit wrong: The high water mark is a hard limit on the maximum number of outstanding messages ØMQ shall queue in memory for any single peer that the specified/socket/is communicating with.*A value of zero means no limit.* * * and from your link: Since v3.x, ØMQ forces default limits on its internal buffers (the so-called high-water mark or HWM), so publisher crashes are rarer *unless you deliberately set the HWM to infinite.* Nothing I read indicates anything other than the fact that no messages post connections being made should be dropped. Thanks G On 13 June 2014 23:17, Brian Knox bk...@digitalocean.com mailto:bk...@digitalocean.com wrote: From what i've read, PUB SUB should be reliable when the _HWM are set to zero (don't drop). By reliable I mean no messages should fail to be delivered to an already connected consumer. Your understanding of pub-sub behavior and how it interacts with the HWM is incorrect. Please see: http://zguide.zeromq.org/php:chapter5 Brian On Fri, Jun 13, 2014 at 2:33 PM, Gerry Steele gerry.ste...@gmail.com mailto:gerry.ste...@gmail.com wrote: I've read everything I can find including the Printed book, but I am at a loss as to the definitive definition as to how PUB/SUB should behave in zmq. A production system I'm using is experiencing message loss between several nodes using PUB/SUB. From what i've read, PUB SUB should be reliable when the _HWM are set to zero (don't drop). By reliable I mean no messages should fail to be delivered to an already connected consumer. I implemented some utilities to reproduce the message loss in my system : zmq_sub:
[zeromq-dev] queue overhead
I have a stable (in the addressing sense) worker that I want to take advantage of multiple cores. So, I run N instances of this worker, where N is the number of cores on the host machine, and each worker binds to its own socket. Components that wish to make use of this worker service connect to all N worker instances. Unfortunately this is a little awkward. The connecting components must be configured with the N socket specs. And it's hard to automate this, since even if the connecting components could generate socket specs programmatically, this still requires knowing the number of cores of the remote machine. What I'd like to do is put an adapter component in front of the N worker instances (on the same machine as the worker instances) that binds to a single socket. It would route to the N workers, and this is easily done since the adapter lives on the same machine and knows the number of cores. Connecting components could then simply connect to this adapter, and not need to care about the number of remote cores. The question I have is what kind of overhead this introduces. An MxN set of connections between M remote components and the N workers seems like it would be far more efficient than M-1-N, which looks like a bottleneck. But maybe in practice, if the routing is very simple, then it becomes negligible? Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] restful access
On 08/05/2014 03:58 AM, bino oetomo wrote: I need kind of http-to-0MQ bridge After some google search .. I still have no luck. Mongrel2 or Zerogw? ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] 0MQ-based proxy worker crashes with Assertion failed: pipe (bundled/zeromq/src/session_base.cpp:441)
Hi Tomas, This does not answer your question at all, but you might be interested in the Zurl project. It is a 0MQ daemon that does HTTP requests. You can speak to it with REQ/REP. https://github.com/fanout/zurl On 09/08/2014 06:44 PM, Tomas Krajca wrote: Hi, I've got a 0MQ-based proxy, clients talk 0MQ to the proxy, the proxy then talks HTTP to do either a GET on a specific url endpoint or a POST on a specific endpoint (it always goes to one of these two url endpoints). I've got a master process that has a zmq.ROUTER towards its clients (zmq.REQ) and a zmq.DEALER towards its workers (zmq.REP). The master is a single process, no threading, normal 0MQ, it spawns a worker processes via multiprocessing, this worker process uses gevent and zmq.green to spawn the actual (green) workers (those use grequests to talk HTTP). The master uses 0MQ auth to authenticate its clients. It should all be pretty standard but note that this is my first gevent/zmq.green based project. So this proxy runs pretty well untill the worker process (I run only 1 worker process) crashes with 'Assertion failed: pipe (bundled/zeromq/src/session_base.cpp:441)' on its stderr. There is nothing else in the logs or on stdout that would give me any more idea of what is going on. I can see the master running and netcat to its zmq.ROUTER so its definitely the worker that dies. Sorry, I have no idea how to reproduce this, once it crashed after 5 hours of working nicely, second time it crashed after about a day. Here is a snippet of the worker code (the relevant bits): http://pastebin.com/usi0FXDL The STSDBResponder uses grequests to do the HTTP, there should be nothing special about that. This happens on CentOS 6.5, the proxy is running in virtualenv (pip install pyzmq): Python 2.7.6 (default, Jul 10 2014, 04:59:13) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2 Type help, copyright, credits or license for more information. import zmq zmq.zmq_version() '4.0.4' zmq.__version__ '14.3.1' I have no idea whether this is a libzmq bug or pyzmq bug or a bug in my code or a system misconfiguration (do I need to increase ulimit or something?), I run 64 gevent threads. I tried to see session_base.cpp but it didn't help me understand why this could happen either. If anybody could please point me to a direction as to why the worker crashes, it would be much appreciated. Thanks, Tomas ___ 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
Re: [zeromq-dev] It looks like socket id's can't change with a router-router topology. Is that correct?
On 09/18/2014 02:23 AM, Goswin von Brederlow wrote: On Wed, Sep 17, 2014 at 03:55:09PM -0400, Mark Wright wrote: I have a router-router setup (destination IDs are acquired via a broadcast/response, similar to the Freelance pattern in the ZMQ book). I've noticed that if my destinations go down and come back up with a new ID, clients can't route to that ID. I'm using 4.0.3. Are you sure they have a new ID? I'm guessing not. You have to allow reused IDs to take over the ID. Otherwise the messages keeps getting send to the old connection. See socket options. Which socket option controls this? By the way, there's a thread from back in Feb when I reported the same issue as Mark: http://lists.zeromq.org/pipermail/zeromq-dev/2014-February/025202.html Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] simple publish subscribe not working with zeromq
Hi Karthik,
You need to subscribe to a topic, not merely connect. You can
subscribe to an empty string to receive all messages. E.g.:
sub_socket.setsockopt(zmq.SUBSCRIBE, '')
On Sat, Oct 11, 2014, at 04:16 PM, Karthik Sharma wrote:
I want to establish publish subscribe communication between to
machines.The two machines that I have are
`ryu-primary` and `ryu-secondary`
The steps I follow in each of the machines are as follows.In
the initializer for `ryu-primary` (IP address is
192.168.241.131)
self.context = zmq.Context()
self.sub_socket = self.context.socket(zmq.SUB)
self.pub_socket = self.context.socket(zmq.PUB)
self.pub_port = 5566
self.sub_port = 5566
def establish_zmq_connection(self):
# Socket to talk to server
print Connection to ryu-secondary...
self.sub_socket.connect (tcp://192.168.241.132:%s %
self.sub_port)
def listen_zmq_connection(self):
print('Listen to zmq connection')
self.pub_socket.bind(tcp://*:%s % self.pub_port)
def recieve_messages(self):
while True:
try:
string =
self.sub_socket.recv(flags=zmq.NOBLOCK)
print('flow mod messages recieved
{}'.format(string))
return string
except zmq.ZMQError:
break
def push_messages(self,msg):
self.pub_socket.send(%s % (msg))
From ryu-secondary (IP address - 192.168.241.132)
In the initializer
self.context = zmq.Context()
self.sub_socket = self.context.socket(zmq.SUB)
self.pub_socket = self.context.socket(zmq.PUB)
self.pub_port = 5566
self.sub_port = 5566
def establish_zmq_connection(self):
# Socket to talk to server
print Connection to ryu-secondary...
self.sub_socket.connect (tcp://192.168.241.131:%s %
self.sub_port)
def listen_zmq_connection(self):
print('Listen to zmq connection')
self.pub_socket.bind(tcp://*:%s % self.pub_port)
def recieve_messages(self):
while True:
try:
string =
self.sub_socket.recv(flags=zmq.NOBLOCK)
print('flow mod messages recieved
{}'.format(string))
return string
except zmq.ZMQError:
break
def push_messages(self,msg):
print('pushing message to publish socket')
self.pub_socket.send(%s % (msg))
These are the functions that I have.
I am calling
establish_zmq_connections()
push_messages()
from `ryu-secondary`,
But I am not recieving those messages when I am calling
listen_zmq_connection()
recieve_messages()
from `ryu-primary`.
Can someone point out to me what I am doing wrong?
___
zeromq-dev mailing list
[1]zeromq-dev@lists.zeromq.org
[2]http://lists.zeromq.org/mailman/listinfo/zeromq-dev
References
1. mailto:zeromq-dev@lists.zeromq.org
2. 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
Re: [zeromq-dev] simple publish subscribe not working with zeromq
Maybe you mean flow_mod['in_port'] ?
On Sat, Oct 11, 2014, at 08:23 PM, Karthik Sharma wrote:
Hi Justin,
Thanks for the reply.That did work!
I have a follow on question.
I am tying to send the following structure.
msg = {'in_port':in_port,'dst':dst,'actions':actions}
self.push_messages(msg)
However on the recieving side,I can decode the msg using
format(msg) but I can acess the members in the dictionary.
print('flow_mod recieved from ryu-primary
{}'.format(flow_mod[in_port]))
- flow_mod recieved from ryu-primary {'dst':
u'00:00:00:00:00:04', 'actions':
[OFPActionOutput(max_len=65509,port=2)], 'in_port': 1}
self.add_flow(datapath, flow_mod[in_port], flow_mod[dst],
flow_mod[actions])
--- doesn't work? -- gives error NameError: global
name 'in_port' is not defined
Regards,
Karthik.
On 12 October 2014 12:31, Justin Karneges
[1]jus...@affinix.com wrote:
Hi Karthik,
You need to subscribe to a topic, not merely connect. You can
subscribe to an empty string to receive all messages. E.g.:
sub_socket.setsockopt(zmq.SUBSCRIBE, '')
On Sat, Oct 11, 2014, at 04:16 PM, Karthik Sharma wrote:
I want to establish publish subscribe communication between to
machines.The two machines that I have are
`ryu-primary` and `ryu-secondary`
The steps I follow in each of the machines are as follows.In
the initializer for `ryu-primary` (IP address is
192.168.241.131)
self.context = zmq.Context()
self.sub_socket = self.context.socket(zmq.SUB)
self.pub_socket = self.context.socket(zmq.PUB)
self.pub_port = 5566
self.sub_port = 5566
def establish_zmq_connection(self):
# Socket to talk to server
print Connection to ryu-secondary...
self.sub_socket.connect (tcp://192.168.241.132:%s %
self.sub_port)
def listen_zmq_connection(self):
print('Listen to zmq connection')
self.pub_socket.bind(tcp://*:%s % self.pub_port)
def recieve_messages(self):
while True:
try:
string =
self.sub_socket.recv(flags=zmq.NOBLOCK)
print('flow mod messages recieved
{}'.format(string))
return string
except zmq.ZMQError:
break
def push_messages(self,msg):
self.pub_socket.send(%s % (msg))
From ryu-secondary (IP address - 192.168.241.132)
In the initializer
self.context = zmq.Context()
self.sub_socket = self.context.socket(zmq.SUB)
self.pub_socket = self.context.socket(zmq.PUB)
self.pub_port = 5566
self.sub_port = 5566
def establish_zmq_connection(self):
# Socket to talk to server
print Connection to ryu-secondary...
self.sub_socket.connect (tcp://192.168.241.131:%s %
self.sub_port)
def listen_zmq_connection(self):
print('Listen to zmq connection')
self.pub_socket.bind(tcp://*:%s % self.pub_port)
def recieve_messages(self):
while True:
try:
string =
self.sub_socket.recv(flags=zmq.NOBLOCK)
print('flow mod messages recieved
{}'.format(string))
return string
except zmq.ZMQError:
break
def push_messages(self,msg):
print('pushing message to publish socket')
self.pub_socket.send(%s % (msg))
These are the functions that I have.
I am calling
establish_zmq_connections()
push_messages()
from `ryu-secondary`,
But I am not recieving those messages when I am calling
listen_zmq_connection()
recieve_messages()
from `ryu-primary`.
Can someone point out to me what I am doing wrong?
___
zeromq-dev mailing list
[2]zeromq-dev@lists.zeromq.org
[3]http://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
[4]zeromq-dev@lists.zeromq.org
[5]http://lists.zeromq.org/mailman/listinfo/zeromq-dev
References
1. mailto:jus...@affinix.com
2. mailto:zeromq-dev@lists.zeromq.org
3. http://lists.zeromq.org/mailman/listinfo/zeromq-dev
4. mailto:zeromq-dev@lists.zeromq.org
5. 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
Re: [zeromq-dev] thoughts on pub-sub messaging and reliability
Hi Holger, You've got a good list here. If you're looking for opinions, I'll say that I'm fond of the first approach (0), which is to treat pubsub as a best-effort transport. This is also in spirit with what is discussed in the ZeroMQ guide: http://zguide.zeromq.org/page:all#Pros-and-Cons-of-Pub-Sub I mostly work on client/server web applications, and I want reliability just like anyone else. However, 100% guaranteed delivery in the pubsub layer is not necessary to achieve this. Not only that, guaranteed delivery is quite difficult to get right and comes with all sorts of implications. Instead, I create a reliable request/response mechanism for synchronization (of application data, not messages) and combine it with best-effort pubsub messaging. On Fri, Oct 17, 2014, at 02:38 AM, Holger Joukl wrote: Hi, I realize I'm sometimes confused by terms used by myself and others. So, in an attempt to clarify my thoughts, first and foremost to myself, by writing them down here's how I tend to think about pub-sub messaging: (0) Publish-subscribe (pub-sub) messaging: - one or many sender(s) publish data on one or more channels - one or many listener(s) subscribe to one or more channels - communication is asynchronous - listeners might not receive all messages even if up-and-running when the messages are being sent (due to network glitches or whatever) (1) Reliable pub-sub messaging: - one or many sender(s) publish data on one or more channels - one or many listener(s) subscribe to one or more channels - communication is asynchronous - as long as a listener is up-and-running when the messages are being sent it will receive all messages from all senders publishing on the channels they've subscribed to, in order (order per sender) (2) Guaranteed/Certified pub-sub messaging: - one or many sender(s) publish data on one or more channels - one or many listener(s) subscribe to one or more channels - communication is asynchronous - as long as a listener is up-and-running when the messages are being sent it will receive all messages from all senders publishing on the channels they've subscribed to, in order (order per sender) - even if a listener is *not* up-and-running when messages are being sent a listener will still get all the messages, i.e. the missed messages will get re-delivered, in order (order per sender); the listener will not receive new messages until it has received all missed message - as a consequence, messages need to get persisted: - either each listeners' subscriptions need to get registered when opening a subscription, or by predefined configuration, so persisted messages can be safely deleted from persistent storage when all registered listeners have received them an explicitly acknowledged that fact - or all sent messages need to get persisted for a period of time so a listener can request missed messages for retransmission Sometimes the reliability distinction is called different qualities of service (QoS). Note that I've deliberately ignored any problems that might arise in pub-sub communications, e.g. slow consumers in (unreliable) high frequency scenarios or the like. Pub-sub messaging can be implemented over a variety of transports and protocols: (UDP) broadcast, multicast, TCP, ... The transport + protocol used determines the properties of pub-sub-messaging, e.g.: - plain UDP broadcast is unreliable - PGM or NORM multicast is reliable - a protocol on top of TCP/UDP/reliable multicast is ususally necessary for guaranteed/certified messaging Design approaches you encounter in the wild: - central broker with queues, optionally persistent (e.g. AMQP brokers, JMS providers, IBM MQ, ...) - senders do not know anything about listeners - listeners do not know anything about senders - the broker is the rendezvous point for communication, often called message bus - senders connect to the broker (usually TCP) - listeners connect to the broker (usually TCP) - channels are usually called topics (basically a special case of queue that allows for many listeners to receive the topic messages) - broker knows registered guaranteed/certified listeners: When all known listeners have retrieved and acknowledged a certain message on a topic this message will get deleted from the queue - queue persistence to make queued messages survive broker failure - broker might be distributed, i.e. multiple broker working in cooperation, e.g. for reasons of throughput scaling, partitioning of data channels, replication - broker is a single point of failure so will normally get clustered and replicated for some notion of cold/hot standby for mission critical communication - central broker with a persistent commit log or journal (e.g. Apache Kafka, ZPER, ...) - senders do not know anything about listeners - listeners do not know anything about senders -
Re: [zeromq-dev] Router socket reconnection failure
Hi Andre, On Tue, Dec 16, 2014, at 07:14 AM, Andre Caron wrote: The issue I'm having is with this sequence: - P1 and P2 discover each other through D; - P1 connects to P2 and P2 waits for a connection from P1 (direction is determined by lexicographical ordering of identities, which both peers have prior to connecting); - Peers exchange heartbeats for a while; - I forcibly crash P2; - P1 eventually detects that P2 is unresponsive and explicitly disconnects; - after this happens, I restart P2; - P1 and P2 discover each other through D again; - P1 tries to connect to P2 and P2 expects a connection from P1; - both peers send heartbeats, but neither peer receives the other's messages and it appears the connection is never established. Also note that after this has happened, context termination hangs despite closing the (only) socket and setting the linger to 1 second. If I crash P1 instead of P2, the reconnection is successful. Also, if after the error sequence above I crash P1, peers reconnect successfully. This is a known issue, and I reported it earlier this year: http://lists.zeromq.org/pipermail/zeromq-dev/2014-February/025202.html I believe the problem is that once a connector queue learns the ID of a remote address, this binding sticks for life. The reason that you can restart P1 and things work is because connectors maintain queues even if there are no connections, but binders don't. Unfortunately I haven't had time yet to look at a fix. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ZMQ_FD clarification
On Tue, Dec 23, 2014, at 12:24 PM, Maurice Barnum wrote: In the 4.0 api documentation for getsockopt, I see this: As the descriptor is edge triggered, applications must update the state of ZMQ_EVENTS after each invocation of zmq_send or zmq_recv. I don't understand what it means to update the state of ZMQ_EVENTS as it is not documented as with zmq_setsockopt().. Do I need to call zmq_getsockopt(..ZMQ_EVENTS..) after I am done with a zmq_send or zmq_recv to see if the socket is now readable and act accordingly? Correct, you call zmq_getsockopt with ZMQ_EVENTS whenever the fd obtained via ZMQ_FD becomes readable, as well as after any call to zmq_send or zmq_recv for that socket. I believe the update the state wording here means updating the application's own state by retrieving the current ZMQ_EVENTS. Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] create a new job per HTTP request
The Mongrel2 web server works this way. It converts HTTP requests into ZeroMQ messages that handlers can process asynchronously. I'd say it's a legitimate approach. :) On Tue, Dec 30, 2014, at 12:24 PM, sam pendleton wrote: if it's a request for a page, maybe that page should be cached by the web server and served but what if it's something like a POST request does it make sense for an app to create a new job for each http POST request on a certain endpoint or should the endpoint process the request immediately? by immediately, i mean use a few function calls to validate the data, insert the data, and on success or failure of updating the db, return this status to the user i can do this with 3-4 lines, but i can't decide if i should just throw the request into a job scheduler ___ 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
