Re: [zeromq-dev] http requests

[Justin Karneges]

Hi,

For bridging between ZeroMQ and HTTP you could consider tools like Condure, 
Zurl, or Mongrel2, depending on which direction you're trying to go.

Justin

On Fri, Dec 11, 2020, at 4:43 AM, doa379 wrote:
> I was looking for a new library to service messaging requests. I also 
> want to make requests from the web. Does zeromq not support http??
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] max PUB/SUB topics

[Justin Karneges]

Works for me with 4.2.5 on Ubuntu 18.04.

https://gist.github.com/jkarneges/0b8f6e6d70c23807de0ad02c8ed72fcb

On Tue, May 14, 2019, at 12:59 AM, Bekritsky, Benjamin via zeromq-dev wrote:
> Justin,

> 

> Thanks for the guidance, but I set the HWMs to 0 and neither application 
> crashed. I also played with changing the HWMs to 2048 and am still 
> encountering the same issue.

> 

> I then subscribed to “all” and received the messages from all the topics 
> (0-1024);

> 

> It seems as though it is limiting the number of subscriptions to 1000. If I 
> subscribed from 20 -1024, I get topics 20 – 1019.

> 

> I am using lib 4.2.3 and the publisher and subscriber on the same Ubuntu box.

> 

> Thanks,

> Benjy


> *From:* zeromq-dev  *On Behalf Of 
> *Justin Karneges
> *Sent:* Tuesday, May 14, 2019 7:10 AM
> *To:* Jamie Stewart via zeromq-dev 
> *Subject:* Re: [zeromq-dev] max PUB/SUB topics

> 

> [External Email]

> Hi,

> 

> Subscribing sends a message to the publisher. I believe you're hitting the 
> default high water mark, and subscription messages are getting dropped.

> 

> If I'm expecting lots of subscriptions, my rule of thumb is to set SNDHWM=0 
> on the SUB socket and RCVHWM=0 on the PUB socket. This way the application 
> will sooner die than lose a subscription message.

> 

> Justin

> 

> On Mon, May 13, 2019, at 10:06 AM, Bekritsky, Benjamin via zeromq-dev wrote:

>> I am using libzmq and setting up topics using binary data. In other words, 
>> my topic is the first 2 bytes of my message.

>> 

>> I subscribe by setting a and b to the values I’m interested in:

>>  for (uint16_t i = a; i <= b; i++)

>>  {

>>  d = zmq_setsockopt(sub_socket, ZMQ_SUBSCRIBE, , 2);

>>  if (d)

>>  {

>>  printf ("E: subscription failed: %s\n", strerror (errno));

>>  return -1;

>>  }

>>  }

>> 

>> My publisher publishes like this:

>>  string incoming_string = " this message";

>>  incoming_string.insert(0,1,i>>8);

>>  incoming_string.insert(0,1,i%256);

>> 

>>  int rc = zmq_send(pub_socket, incoming_string.c_str(), 
>> incoming_string.size(), 0);

>> 

>> I can’t seem to subscribe to more than 1000 topics (values 0x – 0x03e7). 
>> From what I understand, thousands of topics should be available.

>> 

>> Any guidance would be helpful.

>> 

>> Thanks,

>> Benjy

>> 

>> Benjamin Bekritsky

>> c/o Zebra Technologies

>> 2 Negev St. (Motorola Building)

>> 4th Floor

>> Airport City 7019900

>> Israel

>> 

>> 

>> 

>> 
>> - CONFIDENTIAL-

>> 

>> This email and any files transmitted with it are confidential, and may also 
>> be legally privileged. If you are not the intended recipient, you may not 
>> review, use, copy, or distribute this message. If you receive this email in 
>> error, please notify the sender immediately by reply email and then delete 
>> this email.

>> 

>> 
>> - CONFIDENTIAL-

>> This email and any files transmitted with it are confidential, and may also 
>> be legally privileged. If you are not the intended recipient, you may not 
>> review, use, copy, or distribute this message. If you receive this email in 
>> error, please notify the sender immediately by reply email and then delete 
>> this email.

>> ___

>> zeromq-dev mailing list

>> zeromq-dev@lists.zeromq.org

>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

>> 

> 

> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] max PUB/SUB topics

[Justin Karneges]

Hi,

Subscribing sends a message to the publisher. I believe you're hitting the 
default high water mark, and subscription messages are getting dropped.

If I'm expecting lots of subscriptions, my rule of thumb is to set SNDHWM=0 on 
the SUB socket and RCVHWM=0 on the PUB socket. This way the application will 
sooner die than lose a subscription message.

Justin

On Mon, May 13, 2019, at 10:06 AM, Bekritsky, Benjamin via zeromq-dev wrote:
> I am using libzmq and setting up topics using binary data. In other words, my 
> topic is the first 2 bytes of my message.

> 

> I subscribe by setting a and b to the values I’m interested in:

>  for (uint16_t i = a; i <= b; i++)

>  {

>  d = zmq_setsockopt(sub_socket, ZMQ_SUBSCRIBE, , 2);

>  if (d)

>  {

>  printf ("E: subscription failed: %s\n", strerror (errno));

>  return -1;

>  }

>  }

> 

> My publisher publishes like this:

>  string incoming_string = " this message";

>  incoming_string.insert(0,1,i>>8);

>  incoming_string.insert(0,1,i%256);

> 

>  int rc = zmq_send(pub_socket, incoming_string.c_str(), 
> incoming_string.size(), 0);

> 

> I can’t seem to subscribe to more than 1000 topics (values 0x – 0x03e7). 
> From what I understand, thousands of topics should be available.

> 

> Any guidance would be helpful.

> 

> Thanks,

> Benjy

> 

> Benjamin Bekritsky

> c/o Zebra Technologies

> 2 Negev St. (Motorola Building)

> 4th Floor

> Airport City 7019900

> Israel

> 

> 
> 
> - CONFIDENTIAL-
> 
>  This email and any files transmitted with it are confidential, and may also 
> be legally privileged. If you are not the intended recipient, you may not 
> review, use, copy, or distribute this message. If you receive this email in 
> error, please notify the sender immediately by reply email and then delete 
> this email. 
> 
>  - CONFIDENTIAL- 
>  This email and any files transmitted with it are confidential, and may also 
> be legally privileged. If you are not the intended recipient, you may not 
> review, use, copy, or distribute this message. If you receive this email in 
> error, please notify the sender immediately by reply email and then delete 
> this email. 
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] PUB-SUB Performance with 5000 subscriber

[Justin Karneges]

5000*500kb = 2.5gb. That's a lot of data. What throughput are you
expecting?
On Thu, Oct 25, 2018, at 8:11 PM, Hiren Shah wrote:
> Notice there is significant increase in latency for bigger Message
> Size when Number of subscriber increases.> 
> 4k Message size gets to all Subscriber in < 1sec but 500k Message Size
> takes about 60sec.> 
> With Async IO and 5000 clients 500k message should be quite faster
> then what I am seeing. I feel like I am missing option which I am
> setting.> 
> 
> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] question re: connect/handshake

[Justin Karneges]

On Sun, Jun 3, 2018, at 7:49 AM, Bill Torpey wrote:
> > On Jun 2, 2018, at 3:33 PM, Justin Karneges  wrote:
> > Keep in mind that PUB/SUB is unreliable by design, so if you absolutely 
> > must receive all messages then you'll need a fallback mechanism. And if you 
> > have a fallback then you may not need the welcome message after all.
> > 
> > In our app, we use SUB for best effort instant receiving, and REQ as a 
> > fallback "poll". On initialization, the client starts the SUB, waits 1 
> > second, then polls with REQ.
> 
> Hmmm.  I dislike relying on an arbitrary sleep — I much prefer to know 
> for sure what state the app is in.  Having said that, a lot of the 0MQ 
> unit tests seem to use that approach (" msleep (SETTLE_TIME);”).  
> 
> As for using the REQ socket to “prime the pump”, so to speak — isn’t 
> that pretty much relying on the same behavior that I’m asking about?  
> You’re assuming that if you get a reply on the REQ then the SUB must be 
> connected.  That may be true in practice, but I don’t know that that 
> behavior is documented anywhere.

The problem with subscription acknowledgments is they don't really work past 
the first hop (i.e. the broker). So you can know for sure that the broker 
considers your connection subscribed to some topic, but you can't know that an 
upstream broker or publisher considers the broker to be subscribed to that 
topic. In other words it's not end-to-end. And this isn't practical to solve 
either, when you consider multiple publishers or late-arriving publishers.

I agree that an arbitrary sleep isn't very satisfying. Weirdly it's about the 
only pure thing that can be done though, aside from doing nothing. Think of it 
as a multi-hop propagation timeout.

Our client doesn't send a REQ to assure the SUB is connected, but rather it 
sends a REQ after enough time has passed for us to believe that the SUB is 
probably already connected, to pick up anything that may have been missed 
before then.

Justin
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] question re: connect/handshake

[Justin Karneges]

Hi Bill,

I'm not sure if the actual handshakes would always finish in order, but you 
might have some success with the SUB socket handshake finishing by the time the 
broker needs to send on it. You basically have one extra trip of latency in the 
client->broker direction while the client sends its first message for the SUB 
handshake to catch up.

E.g.:

1) client starts SUB and PUB handshakes
2) PUB handshake finishes
3) client sends message over PUB socket
4) SUB handshake finishes
5) broker receives message from step 3 and sends it back out

That all said, I wouldn't rely on it, unless you can tolerate it sometimes not 
working. Better to use ZMQ_XPUB_WELCOME_MSG to be sure.

Keep in mind that PUB/SUB is unreliable by design, so if you absolutely must 
receive all messages then you'll need a fallback mechanism. And if you have a 
fallback then you may not need the welcome message after all.

In our app, we use SUB for best effort instant receiving, and REQ as a fallback 
"poll". On initialization, the client starts the SUB, waits 1 second, then 
polls with REQ.

Justin

On Sat, Jun 2, 2018, at 11:49 AM, Bill Torpey wrote:
> Hello all:
> 
> I have a question that I’m hoping someone with more experience than I 
> can help answer, which is whether the order of connections and/or 
> handshakes can be relied on in certain cases.  
> 
> I understand that generally connect and handshake happen asynchronously, 
> and that the only way to be certain is to use zmq_socket_monitor and 
> capture the individual events.
> 
> However, I have a specific use case in mind:
> 
> - process A is connecting to a zmq_proxy  at a well-known address 
> (essentially the "Weather Update" proxy from the Guide):
>  - it first connects a ZMQ_SUB socket (to the proxy’s ZMQ_XPUB socket)
>  - it next connects a ZMQ_PUB socket (to the proxy’s ZMQ_XSUB socket)
> 
> It turns out that it would be very handy to be able to rely on the SUB 
> socket completing its handshake BEFORE the PUB socket's handshake 
> completes. 
> 
> If that is the case, then I believe that process A can rely on the SUB 
> socket getting any message it publishes on the PUB socket.  More 
> importantly, it can rely on the fact that no other processes connected 
> to the proxy will see a message from process A's PUB socket that process 
> A's SUB socket does not see itself.
> 
> So I guess the question boils down to: is there any possibility that the 
> PUB socket's handshake will complete before the SUB socket's?
> 
> Given that the connect calls are both being done from the same process 
> to the same (other) process, it seems that this might be a reliable 
> pattern, but I don’t know the code well enough to be certain.
> 
> Or am I stuck with having to use  zmq_socket_monitor to capture the 
> events and provide synchronization around them?  (Which I would prefer 
> to avoid if possible -- that can be messy and error-prone).
> 
> Any tips, suggestions much appreciated!
> 
> Regards,
> 
> Bill Torpey
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Sharing socket safely between threads

[Justin Karneges]

The real issue here is thread affinity. Mere thread-unsafety can always
be worked-around by the application developer, by ensuring that no two
threads ever access the same resource at the same time. It is my
understanding that libzmq sockets are not thread safe, but they also
don't have thread affinity, so you can access a single socket from
different threads if you handle safety on your own.
Personally, I agree with the libzmq authors in that trying to do I/O on
the same socket from multiple threads is an anti-pattern. However, I
consider certain kinds of sharing to be legitimate, for example creating
a socket in one thread and then handing it off to a second thread, and
only that second thread does I/O. I think that fits within the spirit of
libzmq, since only one thread is actually doing I/O on the socket. If
you find yourself doing I/O on a socket from multiple threads,
protecting the access with a mutex, then you're in anti-pattern
territory. That said, it should work just fine, and libzmq authors'
opinions won't stop you. :)
FWIW, you might run into thread affinity in other libraries. For
example, last I checked, PyZMQ has thread-affinity of sockets. If you
create a socket in one thread and hand it off to another, I/O from the
other thread will fail. But it is my understanding that libzmq itself
does not have such limitation.
On Sat, May 12, 2018, at 2:08 PM, Bill Torpey wrote:
> 1. FWIW, my personal experience has been that it is safe to share a
>ZMQ_PUB socket between threads if protected with a mutex.
>Basically the sequence is lock/send/unlock.> 
> The alternative is to have an internal zmq_proxy with inproc on one
> side and something like TCP on the other side, which is an extra
> send/receive hop.  I have not found that to be necessary, and I have
> done a *lot* of testing (which has found several other edge cases).> 
> FWIW the docs specifically bless this approach
> (http://zeromq.org/area:faq):>> For those situations where a dedicated socket 
> per thread is
>> infeasible, a socket may be shared *if and only if* each thread
>> executes a full memory barrier before accessing the socket. Most
>> languages support a Mutex or Spinlock which will execute the full
>> memory barrier on your behalf.> and here
> (http://zguide.zeromq.org/page:all#Multithreading-with-ZeroMQ):> 
>> Technically it's possible to migrate a socket from one thread to
>> another but it demands skill.> 
> I have not tried doing that with ZMQ_SUB sockets — there is really no
> point, as a sigle thread sitting in a zmq_poll call on multiple
> sockets is probably the cleanest design anyway.> 
> 
> 2. I can definitely testify that trying to share a ZMQ_SUB socket
>*without* mutexes is guaranteed to crash, and that trying to share
>a ZMQ_SUB socket *with* mutexes is almost impossible to do without
>deadlocking.> 
> 
> 3.  Another situation is to have a single “main” thread setup all the
> sockets at startup and then hand them off to other threads (and
> never touch them again).  Strictly speaking you may only need a
> memory barrier, but using a mutex in this case ensures that you
> don’t try to use the socket concurrently from more than one
> thread.> 
> 
> 4.  Last but not least, if you’re planning on using inproc sockets for
> inter-thread communication, you may find this helpful:
> https://github.com/WallStProg/zmqtests/tree/master/threads> 
> 
>> On May 8, 2018, at 3:58 PM, Thomas Rodgers
>>  wrote:>> 
>> No, not really. I have designed my zmq based systems to either -
>> * orchestrate connections over the inproc transport
>> * performed the delicate dance of explicitly passing a fresh socket
>>   to a fresh thread the way that czmq actors[1] work,>>   as implemented in 
>> azmq[2]
>> 
>> On Mon, May 7, 2018 at 11:58 AM, Attila Magyari
>>  wrote:>>> This sounds promising. My concern is if there 
>> are some background
>>> threads internally in the ZMQ library, which would use the socket
>>> out of sync with mine, or anything else that I'm not thinking about.
>>> I can ensure that the socket won't be used from multiple threads.>>> 
>>> Do you have any experience with this, or only theory?
>>> 
>>> Thank you,
>>> Attila
>>> 
>>> 
>>> On Mon, May 7, 2018 at 5:49 PM Thomas Rodgers
>>>  wrote: The zmq docs say you need to ensure a 
>>> ‘full fence’ a mutex is one
 way of achieving that. 
 If you are using C++ (-std=c++11 or later) and you can guarantee
 there is no racy usage from another thread, you can issue a memory
 fence using - 
 std::atomic_thread_fence
 
 
 On Mon, May 7, 2018 at 8:42 AM Attila Magyari 
 wrote:> Hello,
> 
> I know that zmq sockets are not thread safe. However I can't think
> of a good design (explained below) without using the socket in
> several threads. What I want to do is connect the socket in a
> 

Re: [zeromq-dev] Multiple connects with a ZMQ_REQ socket appears not to work

[Justin Karneges]

On Fri, Feb 23, 2018, at 4:53 PM, Mark via zeromq-dev wrote:
> As I mentioned previously the docs on REQ/REP state:
> 
>"If no services are available, then any send operation on the
> socket shall block until at least one service becomes available."
> 
> but the send() doesn't block in this situation. As you said earlier
> the message is queued and sent async with send() returning to the
> caller.
> 
> I also mis-interpreted the docs to imply that when "at least one
> service becomes available" that any queued messages would go to that
> service, but that's not the case as the round-robin decision is only
> made once on the call to send() - not during the async sending
> process.
> 
> Anyhoo, it's all good now that I know better.

Yeah one thing that got me when I started out with ZeroMQ is understanding that 
queues only exist in the context of known peers, and that a zmq socket doesn't 
have a master queue or anything that exists in the absence of known peers. This 
is why writing to a socket that is binding but has no peers will block.

I say "known peers" rather than "peer connections" because you get a queue once 
you attempt to connect to a peer, even if that connection is not yet 
established.

Justin
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] How to get data a ZMQ_PUB service?

[Justin Karneges]

ZMQ programs may only send dummy data that has originated from within
the process. For example if your program obtains data by reading a file
or performing a network operation unrelated to zmq, and attempts to send
that data over a zmq socket, your computer will promptly catch fire. But
I have only heard this. You could try and see what happens.
On Mon, Feb 12, 2018, at 1:40 PM, Bernardo Augusto García Loaiza wrote:> Can I 
publisher service receive data from an external source and send
> them to the subscribers?> 
> In the wuserver.cpp[1] sample the data are generated from the same
> script ...> 
> Can I write a ZMQ_PUBLISHER entity which receive data from external
> data source / application ... ?> 
> Inline image 1
> Bernardo Augusto García Loaiza
> Ingeniero de Sistemas 
> Estudiante de Maestría en Ingeniería Informática - Universidad EAFIT
> http://about.me/bgarcial
> 
> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev


Links:

  1. http://zguide.zeromq.org/cpp:wuserver
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Server Socket Initiate Communication

[Justin Karneges]

Assuming you're talking about route IDs with respect to ROUTER sockets,
it is possible to use predetermined IDs when sending messages.
For example, a client can create a ROUTER socket and connect it to
multiple servers. As long as it also knows the ZMQ_IDENTITY used by each
of these servers (you'd need to obtain this information out-of-band
somehow), the client can send a message to a specific server by
including the server's ZMQ_IDENTITY as the first message part.
On Sat, Feb 10, 2018, at 7:29 AM, Matthew Harrigan wrote:
> 
> I apologize in advance if this is a dumb question, but would still
> appreciate knowing why.  So, why can't a server socket initiate
> communication? I am focused on this documentation
> http://api.zeromq.org/4-2:zmq-socket. AFAICT the only state change
> that happens in a server socket when a client socket connects to it is
> that the map that relates addresses to routing id's get updated.
> Suppose a machine with a server socket knows what address it want to
> communicate with, whether hard coded, from a beacon, service locator,
> whatever.  Why can't it just tell the server socket to make a routing
> id to that address and then start communicating?  Note I am working on
> a toy educational project where a gaggle of peers uses raft to get a
> leader and formally join or leave (different from crashing or network
> partitions).  In such a peer to peer network the symmetry of each peer
> binding a server socket to itself and talking to other peers seems
> appealing.  Thank you> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Publishers stops sending data after sometime. Subscriber is required to fix publisher

[Justin Karneges]

libzmq handles automatically reconnecting, so you shouldn't call connect
again without disconnecting first.
But yes, a disconnect and then connect is a way to force a reconnect, if
that's what you're asking. This is what you'd need to do if you were
sending/receiving your own heartbeats and needed a way to reconnect
after some silence.
If TCP keepalives are working though, then that's best since libzmq will
take care of the reconnecting for you.
On Sun, Jan 28, 2018, at 4:46 PM, Ravi Joshi via zeromq-dev wrote:
> Hi,
> 
> Setting following KEEPALIVEs in ZMQ SUB, the problem seems fixed.
> Since I haven't seen any issue from few hours.> 
> ZMQ_TCP_KEEPALIVE = 1
> ZMQ_TCP_KEEPALIVE_IDLE = 30
> ZMQ_TCP_KEEPALIVE_INTVL = 5
> ZMQ_TCP_KEEPALIVE_CNT = 6
> 
> Thank you very much. Meanwhile, an alternate idea came into my mind.
> Please see the following code snippet-> 
> --
> > while (ros::ok()) {
> zmq::message_t msg;
> int rc = 0;
> try {
> rc = zmq_socket.recv();
> }
> catch (zmq::error_t& e) {
> }
> if (rc) {
> // do work here
> }
> else {
> zmq_socket.connect(socket_address.c_str()); // re-connect
> }
> }
> --
> > 
> The above code snippet is not tested. It just came into my mind.
> Intuitively, it looks okay to me but I am not sure if it is
> acceptable in ZMQ.> 
> What do you say?
> 
> -
> Thanks
> Ravi 
> 
> 
> On Sunday, 28 January 2018 4:37 PM, Justin Karneges
> <jus...@karneges.com> wrote:> 
> 
> All that seems fine, but to get TCP keepalives to use a shorter
> timeout you'll want to set those additional options, yes.> 
> For example, in my apps I use:
> 
> ZMQ_TCP_KEEPALIVE = 1
> ZMQ_TCP_KEEPALIVE_IDLE = 30
> ZMQ_TCP_KEEPALIVE_INTVL = 5
> ZMQ_TCP_KEEPALIVE_CNT = 6
> 
> What this means is if there is 30 seconds of no I/O, then the peer
> will be pinged every 5 seconds, up to 6 times, before closing the
> connection. Thus, the connection should recover after about a minute.> 
> If you don't set these additional options, then the OS defaults are
> used, which can sometimes be hours (!) long.> 
> Justin
> 
> On Sat, Jan 27, 2018, at 9:02 PM, Ravi Joshi via zeromq-dev wrote:
>> Hi,
>> 
>> I am little confused. Let me first explain the scenario again.
>> 
>> There are 3 publishers written in C# language running on Windows 10
>> OS. On the other hand, there are 3 subscribers written in C++
>> language running on Ubuntu 14.04 LTS OS. The mapping from publisher
>> to subscriber is one to one.>> 
>> Now let me mention ZMQ socket configurations.
>> Publisher configuration-
>> SetOption(ZSocketOption.CONFLATE, 1);
>> 
>> Subscriber configuration-
>> socket.setsockopt(ZMQ_SUBSCRIBE, "", 0); // allow all messages
>> socket.setsockopt(ZMQ_RCVTIMEO, , sizeof(timeout)); //
>> int timeout = 1000>> socket.setsockopt(ZMQ_LINGER, , 
>> sizeof(linger)); // int
>> linger = 0>> socket.setsockopt(ZMQ_CONFLATE, , 
>> sizeof(conflate)); //
>> int conflate = 1>> socket.setsockopt(ZMQ_TCP_KEEPALIVE, 
>> _keepalive,
>> sizeof(tcp_keepalive)); // int tcp_keepalive = 1>> 
>> Do the above configurations look fine? Or do you want me to change
>> and try once?>> 
>> I am confused since I am not able to find that how to set HEARTBEAT
>> in Publisher-Subscriber.  Any suggestions, please?>> 
>> Regarding ZMQ_TCP_KEEPALIVE_*, I found following three variables
>> ZMQ_TCP_KEEPALIVE_IDLE, ZMQ_TCP_KEEPALIVE_CNT, and
>> ZMQ_TCP_KEEPALIVE_INTVL. The values for these variables is not clear
>> from the documentation. Any suggestions, please?>> 
>> 
>> Thank you very much.
>> 
>> -
>> Ravi
>> 
>> On Sunday, 28 January 2018 3:10 AM, Justin Karneges
>> <jus...@karneges.com> wrote:>> 
>> 
>> You'd still have to wait for the TCP keepalive to timeout the
>> connection before it will recover. On Ubuntu this might be a very
>> long time, so be sure to set all the ZMQ_TCP_KEEPALIVE_* options to
>> ensure a shorter timeout.>> 
>> On Sat, Jan 27, 2018, at 2:27 AM, Ravi Joshi via zeromq-dev wrote:
>>> Hi Justin,
>>> 
>>> I will check it using netstat.
>>> 
>>> Meanwhile, ZMQ_TCP_KEEPALIVE seems not working. I still see that
>>> after some time, Windows OS, where publishers are running, is

Re: [zeromq-dev] Publishers stops sending data after sometime. Subscriber is required to fix publisher

[Justin Karneges]

All that seems fine, but to get TCP keepalives to use a shorter timeout
you'll want to set those additional options, yes.
For example, in my apps I use:

ZMQ_TCP_KEEPALIVE = 1
ZMQ_TCP_KEEPALIVE_IDLE = 30
ZMQ_TCP_KEEPALIVE_INTVL = 5
ZMQ_TCP_KEEPALIVE_CNT = 6

What this means is if there is 30 seconds of no I/O, then the peer will
be pinged every 5 seconds, up to 6 times, before closing the connection.
Thus, the connection should recover after about a minute.
If you don't set these additional options, then the OS defaults are
used, which can sometimes be hours (!) long.
Justin

On Sat, Jan 27, 2018, at 9:02 PM, Ravi Joshi via zeromq-dev wrote:
> Hi,
> 
> I am little confused. Let me first explain the scenario again.
> 
> There are 3 publishers written in C# language running on Windows 10
> OS. On the other hand, there are 3 subscribers written in C++ language
> running on Ubuntu 14.04 LTS OS. The mapping from publisher to
> subscriber is one to one.> 
> Now let me mention ZMQ socket configurations.
> Publisher configuration-
> SetOption(ZSocketOption.CONFLATE, 1);
> 
> Subscriber configuration-
> socket.setsockopt(ZMQ_SUBSCRIBE, "", 0); // allow all messages
> socket.setsockopt(ZMQ_RCVTIMEO, , sizeof(timeout)); // int
> timeout = 1000> socket.setsockopt(ZMQ_LINGER, , 
> sizeof(linger)); // int
> linger = 0> socket.setsockopt(ZMQ_CONFLATE, , 
> sizeof(conflate)); //
> int conflate = 1> socket.setsockopt(ZMQ_TCP_KEEPALIVE, _keepalive,
> sizeof(tcp_keepalive)); // int tcp_keepalive = 1> 
> Do the above configurations look fine? Or do you want me to change and
> try once?> 
> I am confused since I am not able to find that how to set HEARTBEAT in
> Publisher-Subscriber.  Any suggestions, please?> 
> Regarding ZMQ_TCP_KEEPALIVE_*, I found following three variables
> ZMQ_TCP_KEEPALIVE_IDLE, ZMQ_TCP_KEEPALIVE_CNT, and
> ZMQ_TCP_KEEPALIVE_INTVL. The values for these variables is not clear
> from the documentation. Any suggestions, please?> 
> 
> Thank you very much.
> 
> -
> Ravi
> 
> On Sunday, 28 January 2018 3:10 AM, Justin Karneges
> <jus...@karneges.com> wrote:> 
> 
> You'd still have to wait for the TCP keepalive to timeout the
> connection before it will recover. On Ubuntu this might be a very long
> time, so be sure to set all the ZMQ_TCP_KEEPALIVE_* options to ensure
> a shorter timeout.> 
> On Sat, Jan 27, 2018, at 2:27 AM, Ravi Joshi via zeromq-dev wrote:
>> Hi Justin,
>> 
>> I will check it using netstat.
>> 
>> Meanwhile, ZMQ_TCP_KEEPALIVE seems not working. I still see that
>> after some time, Windows OS, where publishers are running, is showing
>> 0 MBPS transmission rate. After I restart subscribers in ROS on
>> Ubuntu, publishers start working. Please note that during this
>> process I am not restarting publishers at all.>> 
>> Below is the code snippet added to all subscribers-
>> 
>> int tcp_keepalive = 1;
>> 
>> zmq_socket.setsockopt(ZMQ_TCP_KEEPALIVE, _keepalive,
>> sizeof(tcp_keepalive));>> 
>> 
>>  -
>> Thanks
>> Ravi
>> 
>> 
>> On Saturday, 27 January 2018 5:36 PM, Justin Karneges
>> <jus...@karneges.com> wrote:>> 
>> 
>> One thing you might do is run netstat on both sides to see if the
>> connections are still listed. In a dead connection scenario, netstat
>> should no longer list the connection on the PUB side, but should
>> remain listing it on the SUB side.>> 
>> Note that it can take time for the PUB connection to give up. On
>> Linux, the default is something like 20 minutes after it dies, so
>> give the PUB side some extra time after messages stop transmitting.
>> If transmission hasn't worked for over 20 minutes and netstat is
>> still showing the connection on the PUB side, then the problem may be
>> something else.>> 
>> On Sat, Jan 27, 2018, at 12:13 AM, Ravi Joshi via zeromq-dev wrote:
>>> Hi Justin,
>>> 
>>> Thank you very much. How do I make sure that I am getting dead
>>> connections?>>> 
>>> For time being, I am enabling ZMQ_TCP_KEEPALIVE on all 3 SUB
>>> sockets.>>> 
>>> I will tell you the status of it after sometime.
>>> 
>>> Thanks
>>> -
>>> Ravi
>>> Sent from Yahoo Mail for iPhone[1]
>>> 
>>> On Saturday, January 27, 2018, 3:27 PM, Justin Karneges
>>> <jus...@karneges.com> wrote:>>>> Hi,
>>>> 
>>>> One issue with socket types that don't usually write data (such as
>>>> SUB) is that a dead connection migh

Re: [zeromq-dev] Publishers stops sending data after sometime. Subscriber is required to fix publisher

[Justin Karneges]

You'd still have to wait for the TCP keepalive to timeout the
connection before it will recover. On Ubuntu this might be a very long
time, so be sure to set all the ZMQ_TCP_KEEPALIVE_* options to ensure a
shorter timeout.
On Sat, Jan 27, 2018, at 2:27 AM, Ravi Joshi via zeromq-dev wrote:
> Hi Justin,
> 
> I will check it using netstat.
> 
> Meanwhile, ZMQ_TCP_KEEPALIVE seems not working. I still see that after
> some time, Windows OS, where publishers are running, is showing 0 MBPS
> transmission rate. After I restart subscribers in ROS on Ubuntu,
> publishers start working. Please note that during this process I am
> not restarting publishers at all.> 
> Below is the code snippet added to all subscribers-
> 
> int tcp_keepalive = 1;
> 
> zmq_socket.setsockopt(ZMQ_TCP_KEEPALIVE, _keepalive,
> sizeof(tcp_keepalive));> 
> 
>  -
> Thanks
> Ravi
> 
> 
> On Saturday, 27 January 2018 5:36 PM, Justin Karneges
> <jus...@karneges.com> wrote:> 
> 
> One thing you might do is run netstat on both sides to see if the
> connections are still listed. In a dead connection scenario, netstat
> should no longer list the connection on the PUB side, but should
> remain listing it on the SUB side.> 
> Note that it can take time for the PUB connection to give up. On
> Linux, the default is something like 20 minutes after it dies, so give
> the PUB side some extra time after messages stop transmitting. If
> transmission hasn't worked for over 20 minutes and netstat is still
> showing the connection on the PUB side, then the problem may be
> something else.> 
> On Sat, Jan 27, 2018, at 12:13 AM, Ravi Joshi via zeromq-dev wrote:
>> Hi Justin,
>> 
>> Thank you very much. How do I make sure that I am getting dead
>> connections?>> 
>> For time being, I am enabling ZMQ_TCP_KEEPALIVE on all 3 SUB sockets.>> 
>> I will tell you the status of it after sometime.
>> 
>> Thanks
>> -
>> Ravi
>> Sent from Yahoo Mail for iPhone[1]
>> 
>> On Saturday, January 27, 2018, 3:27 PM, Justin Karneges
>> <jus...@karneges.com> wrote:>>> Hi,
>>> 
>>> One issue with socket types that don't usually write data (such as
>>> SUB) is that a dead connection might go unnoticed forever. You can
>>> work around this by enabling TCP keep alives on the SUB socket. I
>>> don't know if you're getting dead connections here but just thought
>>> I'd mention it.>>> 
>>> Justin
>>> 
>>> On Fri, Jan 26, 2018, at 9:33 PM, Ravi Joshi via zeromq-dev wrote:
>>> > Hi,
>>> > 
>>> > I am using Publisher-Subscriber pattern consisting of 3
>>> > publishers to>>> > publish 3 different types of data. All 3 publishers 
>>> > are written
>>> > in a>>> > single C# file. However, each subscriber is written in a
>>> > separate C++>>> > file inside ROS. From the point of ZeroMQ, there is no
>>> > difference in>>> > each subscriber, since context, socket initialization 
>>> > and
>>> > receiving>>> > message is done in the same way for all subscriber. Hence, 
>>> > in
>>> > order to>>> > make the mail shorter, I am just posting code snippet of 1 
>>> > subscriber below.
>>> > 
>>> > The publisher code in C# snippet is available in Pastebin 
>>> > (https://pastebin.com/S65LmwuV).
>>> > The subscriber code in C++ snippet is available in Pastebin 
>>> > (https://pastebin.com/xb3V0n0u).
>>> > 
>>> > The publisher works well initially for some time and successfully>>> > 
>>> > transmits data at 700MBPS rate but stops transmitting any data
>>> > after 5-6>>> > hours.
>>> > 
>>> > In order to make publisher working again, I need to restart the 
>>> > subscribers. This is strange to me since it is unexpected
>>> > behavior as>>> > per the Publisher-Subscriber pattern is concerned.
>>> > 
>>> > Why such weird behavior? Any workaround, please.
>>> > 
>>> > -
>>> > Thanks
>>> > Ravi
>>> > ___
>>> > zeromq-dev mailing list
>>> > zeromq-dev@lists.zeromq.org
>>> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> 
>>> ___
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>> 
>> _
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev


Links:

  1. https://overview.mail.yahoo.com/?.src=iOS
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Publishers stops sending data after sometime. Subscriber is required to fix publisher

[Justin Karneges]

One thing you might do is run netstat on both sides to see if the
connections are still listed. In a dead connection scenario, netstat
should no longer list the connection on the PUB side, but should remain
listing it on the SUB side.
Note that it can take time for the PUB connection to give up. On Linux,
the default is something like 20 minutes after it dies, so give the PUB
side some extra time after messages stop transmitting. If transmission
hasn't worked for over 20 minutes and netstat is still showing the
connection on the PUB side, then the problem may be something else.
On Sat, Jan 27, 2018, at 12:13 AM, Ravi Joshi via zeromq-dev wrote:
> Hi Justin,
> 
> Thank you very much. How do I make sure that I am getting dead
> connections?> 
> For time being, I am enabling ZMQ_TCP_KEEPALIVE on all 3 SUB sockets.> 
> I will tell you the status of it after sometime.
> 
> Thanks
> -
> Ravi
> Sent from Yahoo Mail for iPhone[1]
> 
> On Saturday, January 27, 2018, 3:27 PM, Justin Karneges
> <jus...@karneges.com> wrote:>> Hi,
>> 
>> One issue with socket types that don't usually write data (such as
>> SUB) is that a dead connection might go unnoticed forever. You can
>> work around this by enabling TCP keep alives on the SUB socket. I
>> don't know if you're getting dead connections here but just thought
>> I'd mention it.>> 
>> Justin
>> 
>> On Fri, Jan 26, 2018, at 9:33 PM, Ravi Joshi via zeromq-dev wrote:
>> > Hi,
>> > 
>> > I am using Publisher-Subscriber pattern consisting of 3
>> > publishers to>> > publish 3 different types of data. All 3 publishers are
>> > written in a>> > single C# file. However, each subscriber is written in a
>> > separate C++>> > file inside ROS. From the point of ZeroMQ, there is no
>> > difference in>> > each subscriber, since context, socket initialization 
>> > and receiving>> > message is done in the same way for all subscriber. 
>> > Hence, in
>> > order to>> > make the mail shorter, I am just posting code snippet of 1 
>> > subscriber below.
>> > 
>> > The publisher code in C# snippet is available in Pastebin 
>> > (https://pastebin.com/S65LmwuV).
>> > The subscriber code in C++ snippet is available in Pastebin 
>> > (https://pastebin.com/xb3V0n0u).
>> > 
>> > The publisher works well initially for some time and successfully>> > 
>> > transmits data at 700MBPS rate but stops transmitting any data
>> > after 5-6>> > hours.
>> > 
>> > In order to make publisher working again, I need to restart the 
>> > subscribers. This is strange to me since it is unexpected
>> > behavior as>> > per the Publisher-Subscriber pattern is concerned.
>> > 
>> > Why such weird behavior? Any workaround, please.
>> > 
>> > -
>> > Thanks
>> > Ravi
>> > ___
>> > zeromq-dev mailing list
>> > zeromq-dev@lists.zeromq.org
>> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> 
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> 
> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev


Links:

  1. https://overview.mail.yahoo.com/?.src=iOS
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Publishers stops sending data after sometime. Subscriber is required to fix publisher

[Justin Karneges]

Hi,

One issue with socket types that don't usually write data (such as SUB) is that 
a dead connection might go unnoticed forever. You can work around this by 
enabling TCP keep alives on the SUB socket. I don't know if you're getting dead 
connections here but just thought I'd mention it.

Justin

On Fri, Jan 26, 2018, at 9:33 PM, Ravi Joshi via zeromq-dev wrote:
> Hi,
> 
> I am using Publisher-Subscriber pattern consisting of 3 publishers to 
> publish 3 different types of data. All 3 publishers are written in a 
> single C# file. However, each subscriber is written in a separate C++ 
> file inside ROS. From the point of ZeroMQ, there is no difference in 
> each subscriber, since context, socket initialization and receiving 
> message is done in the same way for all subscriber. Hence, in order to 
> make the mail shorter, I am just posting code snippet of 1 
> subscriber below.
> 
> The publisher code in C# snippet is available in Pastebin 
> (https://pastebin.com/S65LmwuV).
> The subscriber code in C++ snippet is available in Pastebin 
> (https://pastebin.com/xb3V0n0u).
> 
> The publisher works well initially for some time and successfully 
> transmits data at 700MBPS rate but stops transmitting any data after 5-6 
> hours.
> 
> In order to make publisher working again, I need to restart the 
> subscribers. This is strange to me since it is unexpected behavior as 
> per the Publisher-Subscriber pattern is concerned.
> 
> Why such weird behavior? Any workaround, please.
> 
> -
> Thanks
> Ravi
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] PUB/SUB model and time-ordering SUB-side

[Justin Karneges]

Hmm that is a lot of messages to try to retain the order of. Your buffer
time will need to be larger than the clock drift between publishers.
Even you manage to keep your clocks within 1 second accuracy and use a 1
second buffer, that's still a million buffered packets.

Maybe you can shard processing so that no single worker needs a buffer
that large. But in any case you're probably still looking at thousands
of buffered messages per worker. It might be possible to optimize using
a fixed size ring buffer (another pattern common in multimedia :)) but I
can't say for sure. Good luck with the optimizing.
On Wed, Dec 6, 2017, at 01:38 PM, Francesco wrote:
> Hi Justin,
> you're absolutely right, I want to do something very very similar to a
> jitter buffer.> 
> I 've found some implementations:
> https://github.com/icefreedom/jitter_buffer/tree/master/include/jitter_buffer>
>  https://github.com/alpartis/rtp.jitter
> but honestly they are so much focused on RTP that are not
> useful to me.> 
>  It should be easy to write a generic message-oriented re-order
>  container using a std::map having the timestamp as key and the
>  message as value but honestly that does not look something high
>  performance (I expect to push about 1Mpps in and get the same rate in
>  output, at least in average).> Perhaps a possible solution is to couple 
> std::map with Boost memory
> pool allocator
> (http://www.boost.org/doc/libs/1_65_1/libs/pool/doc/html/boost_pool/pool/interfaces.html)
> to decrease memory fragmentation and reduce to zero malloc/free calls> 
> Thanks for the reply
> Francesco
> 
> 
> 
> 2017-12-06 18:54 GMT+01:00 Justin Karneges <jus...@karneges.com>:
>> __
>> Hi,
>> 
>> It sounds like you need logic similar to a jitter buffer, which is
>> commonly used in RTP media streaming (voip / TV airwaves).>> 
>> Basically, you have a time buffer (say 300 milliseconds) that
>> timestamped messages are held in before processing. Each message sits
>> in this queue for the defined time limit, and if any other messages
>> arrive during that time then the messages are sorted by their
>> timestamps. Once the time limit elapses for a message, it becomes
>> available for reading. Note that this approach introduces a fixed
>> amount of latency (e.g. in the case of a 300ms buffer, messages will
>> run 300ms behind).>> 
>> I don't have any libraries to suggest, but you might look around for
>> jitter buffer implementations as inspiration.>> 
>> 
>> Justin
>> 
>> 
>> On Wed, Dec 6, 2017, at 03:55 AM, Francesco wrote:
>>> Hi all,
>>> As you know when using PUB/SUB model the order of arrival of
>>> messages at SUB-side cannot be garantueed and generally speaking,
>>> the SUB will receive messages out of order. This is a well known
>>> problem, see e.g.:>>>   https://cloud.google.com/pubsub/docs/ordering
>>> 
>>> My question is: in case in the SUB you need strict time ordering,
>>> are you aware of any good C++ implementation of a reordering queue?>>> 
>>> I used for other purposes moodycamel's queue
>>> (http://moodycamel.com/blog/2013/a-fast-lock-free-queue-for-c++)
>>> which is thread-safe but it does not perform time-reordering.>>> 
>>> Thanks!
>>> 
>>> Francesco
>>> 
>>> 
>>> 
>>> _
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> 
>> 
>> 
>> ___
>>  zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> 
> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] PUB/SUB model and time-ordering SUB-side

[Justin Karneges]

Hi,

It sounds like you need logic similar to a jitter buffer, which is
commonly used in RTP media streaming (voip / TV airwaves).
Basically, you have a time buffer (say 300 milliseconds) that
timestamped messages are held in before processing. Each message sits in
this queue for the defined time limit, and if any other messages arrive
during that time then the messages are sorted by their timestamps. Once
the time limit elapses for a message, it becomes available for reading.
Note that this approach introduces a fixed amount of latency (e.g. in
the case of a 300ms buffer, messages will run 300ms behind).
I don't have any libraries to suggest, but you might look around for
jitter buffer implementations as inspiration.
Justin

On Wed, Dec 6, 2017, at 03:55 AM, Francesco wrote:
> Hi all,
> As you know when using PUB/SUB model the order of arrival of messages
> at SUB-side cannot be garantueed and generally speaking, the SUB will
> receive messages out of order. This is a well known problem, see e.g.:>   
> https://cloud.google.com/pubsub/docs/ordering
> 
> My question is: in case in the SUB you need strict time ordering, are
> you aware of any good C++ implementation of a reordering queue?> 
> I used for other purposes moodycamel's queue
> (http://moodycamel.com/blog/2013/a-fast-lock-free-queue-for-c++) which
> is thread-safe but it does not perform time-reordering.> 
> Thanks!
> 
> Francesco
> 
> 
> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] connect a Web Page to zeromq-radio

[Justin Karneges]

You may also find Pushpin interesting:
https://github.com/fanout/pushpin

It can listen for data using ZeroMQ (SUB or PULL) and send over raw
WebSockets or long-lived HTTP responses. It's mainly useful if you have
a web API-oriented architecture.
Justin

On Wed, Nov 29, 2017, at 04:52 AM, Juergen Gnoss wrote:
> Many thanks Kevin,


> 


> that's exactly what I was looking for.


> 


> You made my day.


> 
> Ju
> 
> 
> 
> *From:* zeromq-dev  on behalf of
> Kevin Sapper  *Sent:* Wednesday, November 29,
> 2017 7:44 AM *To:* ZeroMQ development list *Subject:* Re: [zeromq-dev]
> connect a Web Page to zeromq-radio>  
> Hi Juergen,
> 
> AJAX supports only polling which is not what you want. Have a look at
> WebSockets which support communications in both directions.> 
> 
> Also have a look athttps://github.com/zeromq/zwssock for your server
> and https://github.com/zeromq/JSMQ for the client (browser).> 
> //Kevin 
> 
> 2017-11-28 15:51 GMT+01:00 Juergen Gnoss  :
> 
>> 


>> I haven't done Web programming for a long time, so I'm a bit
>> outdated.>> 


>> What I need to do is:


>> 


>> The web page uses Frames.


>> 


>> In one of the frames I need to show a list of events that is
>> published>> by a czmq radio socket.


>> 


>> The list should be updated (kind of automatic) every time a new event>> is 
>> send by the socket.


>> 


>> I remember there was something like AJAX to do stuff like that,
>> but not>> sure what's the actual way to do it.


>> 


>> Someone can point me in the right direction please.


>> 


>> Ju


>> 


>> 


>> 
>> 
>> 
>> 
>> ___
>>  zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> 
> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Detecting abandoned clients (ie, half closed sockets)

[Justin Karneges]

Hi Chuck,

libzmq doesn't allow setting an activity timeout as far as I know, so the 
nearest way to solve this is with TCP keep alives. You can configure them using 
zmq_setsockopt and the ZMQ_TCP_KEEPALIVE* options. With TCP keep alives turned 
on, the TCP subsystem will close the socket if it doesn't receive special keep 
alive packets from the client after awhile. This ensures libzmq will always 
properly clean up the socket. If you're using PULL or SUB sockets this is 
essential.
One issue to be aware is that TCP keep alives allegedly may not be supported by 
some mobile devices/networks. I've never done any investigation myself about 
this, it's just something I've heard. However, I don't think this actually 
matters too much. If the server is unable to receive keep alives from a client, 
then it'll just always timeout the client after awhile, forcing the client to 
reconnect. You could set a long keep alive timeout so this doesn't happen very 
often (which is already standard practice, the default on Linux is something 
like 4 hours).
Hope that helps.

Justin

On Tue, Jul 25, 2017, at 06:35 AM, Chuck Price wrote:
> I have a service processing periodic messages (periodic could be every 1 to 
> 10 seconds or so per client) from mobile clients connecting over intermittent 
> LTE connections. The server is using a PULL socket. It is written in Go, 
> using goczmq. > 
> The communication is one way, no reply is ever sent to the client. There can 
> be many clients per server. The connection is encrypted. > 
> The server only cares about the latest messages from the client. If the LTE 
> connection drops, the client does not queue messages, but instead just eats 
> the error and waits for connectivity to resume.> 
> On the server side, the result appears to be a socket (file descriptor) leak. 
> When the client reconnects, the server side doesn't notice that the old 
> connection is defunct, and doesn't have any way to destroy the socket. The 
> server is running on Linux (Debian). > 
> Is there a way to track when a client connects to a PULL socket and record 
> the socket? With some sort of hook like that, I could attach a timer and 
> garbage collect abandoned sockets.> 
> Thanks,
> 
> -chuck
> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Stateless service protocols

[Justin Karneges]

Florian,

I don't know anything about Swarm's load balancer, but the most common
load balancers create TCP connections to backend servers as needed, and
are able to route different incoming requests to different backend
servers as long as the client is using HTTP (or other layer 7 protocol
the load balancer has awareness of). If a load balancer does not
understand the protocol, basic TCP routing is possible but then the
routing is pinned to a single backend server until the connection is
terminated by the client or backend.
ZeroMQ doesn't work well with such common load balancers for a couple
of reasons:
1) I'm not aware of any load balancers that understand the ZeroMQ
   protocol, so you can only use TCP routing.2) TCP routing pins to a specific 
backend which means you lose out on
   actual load balancing.
Instead, you should use ZeroMQ's built-in load balancing capability.
There are two ways to do this:
1) Build a ZeroMQ broker node. Create a process that binds two ZeroMQ
   sockets, one for receiving work, and one for sending work. Configure
   your nodes to connect to the broker. As you add or remove client or
   server nodes, routing should work automatically.
2) Go brokerless. A ZeroMQ socket can connect to more than one peer, so
   have each client node connect to all of the server nodes directly. If
   the number of nodes in your cluster changes, then reconfigure the
   client nodes to add or remove ZeroMQ connections.
Justin

On Sun, Jun 25, 2017, at 01:51 PM, picfl...@web.de wrote:
> Hi,
>  
> a few days ago I posted a question here regarding the combination of
> Zeromq and Docker Swarm.>  
> As a follow up to this thread. Since it is not possible to really use
> a stateful connections with the load balancer provided by Docker
> Swarm, I am curious if it is possible to write distributed
> architectures with entirely stateless protocols?>  
> Thanks,
>  
> Florian
> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Asyncronous clients

[Justin Karneges]

Hi Andrey,

ROUTER sockets read the first part of the message as the recipient
address. Is it possible you're using the wrong address when sending?
Justin

On Mon, Apr 24, 2017, at 01:08 AM, Андрей Олейник wrote:
> Hello,
> 
> I have a chat application that receives messages through WebSockets
> and processes them on workers connected by a DEALER-ROUTER pattern.
> Chat sends and receives ZMQ messages through one DEALER socket. It has
> been working until I added second worker (ROUTER socket). From now
> there is not guaranty that client will receive its own response.> 
> As I understand the solution could be to use separate DEALER socket
> for each WebSocket connection or use one socket with a wrapper that
> will handle sharing across WebSockets connections.> 
> What is the best way to have it done?
> 
> Thank you,
> Andrey
> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] publish/subscribe and the "fast producer" problem

[Justin Karneges]

On Mon, Mar 6, 2017, at 01:26 AM, Francesco wrote:
> Hi Justin,
> 
> >> > My advice
> >> > is to publish at a fixed rate, for example by sleeping between publishes.
> >>
> >> Unfortunately this is not a solution in my case, as the events I
> >> publish are generated by other incoming events that I cannot control
> >> and in general I will not know at which rate they arrive.
> >
> > Ah, but even if your writes automatically slowed down to the fastest
> > subscriber, you'd still face this problem. What will you do with
> > incoming events while you're waiting for the fastest subscriber to
> > become writable again?
> 
> In such a case I just need to drop input events.

If you want to drop events to subscribers that can't read, including
events to the fastest subscriber, then you simply use PUB. ;)

I think this moves us into the realm of diagnostics. You want to know if
the publisher is dropping messages.

It might be handy if there were an alternative to ZMQ_XPUB_NODROP (say
ZMQ_XPUB_ATLEASTONE) that required at least one subscriber to be
writable, but not all of them. Then you could send with ZMQ_DONTWAIT,
and an EAGAIN error would indicate that not even the fastest subscriber
was writable (you could then discard the message yourself and not retry
sending it).

To solve your problem without changing ZeroMQ, you might make a
subscriber feedback system. For example, add a sequence ID to the
published payloads, and if a subscriber sees an ID out of sequence then
it can keep a running count of missed messages. Periodically, each
subscriber should submit the number of messages it has missed (or zero
if none missed) to the publisher (via a separate socket, like PUSH) and
then zero out its counter. As long as the publisher regularly receives
messages saying zero missed, then you know there's at least one
subscriber out there keeping up. If nobody is saying zero missed, then
you've gone over.
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] publish/subscribe and the "fast producer" problem

[Justin Karneges]

On Sun, Mar 5, 2017, at 04:03 AM, Francesco wrote:
> 2017-03-03 21:49 GMT+01:00 Justin Karneges <jus...@karneges.com>:
> > It sounds like your goal is some kind of sensible flow control (I'm not sure
> > what else an "at least 1 subscriber can read" use-case really is).
> Yes exactly: the problem is that the only type of "flow control" that
> can be done now (ZMQ_XPUB_NODROP=1) leads to a scenario that does not
> scale well: if I have 1k subscribers and suddenly just one of them
> slows down to 1message/sec for whatever reason (networking issue,
> software bug, whatever), the publisher would slow down to 1message/sec
> basically propagating the failure of 1 subscriber to the whole
> network.
> 
> Of course also the opposite case exists: if I have 1k subscribers and
> suddenly just one of them increases its processing speed by a 10x
> factor, the publisher would follow it publishing 10x more messages per
> sec potentially causing other subscribers to drop lots of messages.
> However I think this case is much more unlikely than the first one.

Thanks, this helps confirm your issue is about flow control and not
reliability.

> > My advice
> > is to publish at a fixed rate, for example by sleeping between publishes.
> 
> Unfortunately this is not a solution in my case, as the events I
> publish are generated by other incoming events that I cannot control
> and in general I will not know at which rate they arrive.

Ah, but even if your writes automatically slowed down to the fastest
subscriber, you'd still face this problem. What will you do with
incoming events while you're waiting for the fastest subscriber to
become writable again?

Justin
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] publish/subscribe and the "fast producer" problem

[Justin Karneges]

And what if there are no subscribers? Publishing should block?



It sounds like your goal is some kind of sensible flow control (I'm not
sure what else an "at least 1 subscriber can read" use-case really is).
My advice is to publish at a fixed rate, for example by sleeping between
publishes.


I do wish ZMQ_RATE worked for all PUB sockets and not just PGM-based.



On Fri, Mar 3, 2017, at 12:31 PM, Francesco wrote:

> Hi all,

> 

> I'm new to ZeroMQ but so far all my experiments with it have been
> quite positive, so thanks for your great work!
> 

> However, one thing that I cannot really sort out is the following: I
> have written a small sample program where I create a ZMQ_PUB socket
> and I continuously zmq_msg_send() messages in it, never sleeping. This
> is simulating what I will do in a larger program where I plan to use
> ZeroMQ. Such program is a massively-parallel utility that needs to
> send in a fanout fashion (1 to many) several short messages per second
> (up to say 1million messages / second).
> 

> In my scenario I don't care about subscribers joining late or
> eventually loosing some messages (if the network is slow or the
> subscriber itself is too slow). I do care however about detecting such
> conditions where messages are dropped.
> 

> My problem is the "fast producer" one: this sample program shows that
> the zmq_msg_send() never returns an error; doing some math such my
> little utility says that is publishing data at rates up to 400Gbps...
> the only problem is that the NIC on the computer is a 1Gbps NIC. Of
> course all subscribers report missing 99% of messages (I put a
> sequence number in the messages I send).
> 

> This problem does not appear to be new, some interesting references I
> found are:
> 

>
> http://grokbase.com/t/zeromq/zeromq-dev/11ca11s9b9/pub-sub-pattern-rate-control-and-backpressure
>(Dec 2011)
>
> http://grokbase.com/t/zeromq/zeromq-dev/12797gy703/notify-send-er-that-theyve-hit-the-high-water-mark
>(Jul 2012)
>
> http://grokbase.com/t/zeromq/zeromq-dev/129n2e2sx5/high-water-mark-notification-for-publisher
>(Sep 2012)
> 

> I experimented a little bit with ZeroMQ and found that:

>   - ZMQ_RATE is not doing anything

>   - ZMQ_XPUB_NODROP set to 1 works BUT basically ties the publisher to
> the SLOWEST subscriber: from my experiments it looks like (despite
> the documentation) the publisher now blocks every time there is
> just 1 subscriber queue that has hit the HWM
> 

> as written in some of these posts what I would like to have is a
> NODROP socket option that allows my publisher to send data as fast as
> the FASTEST subscriber can handle.
> 

> So here's my question: is there any way to achieve the above, i.e.
> block the publisher if ALL subscriber queues hit their HWM ?
> 

> 

> Thanks a lot for any hint!

> 

> Francesco

> 

>  

> 

> 

> 

> _

> zeromq-dev mailing list

> zeromq-dev@lists.zeromq.org

> https://lists.zeromq.org/mailman/listinfo/zeromq-dev


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZMQ_FD and inproc:// socket

[Justin Karneges]

What Max says is true, BUT there is actually a specific bug with inproc
sockets not working with ZMQ_FD.

(I'm the one that filed the original issue)

On Wed, Nov 16, 2016, at 05:59 PM, Max Kozlovsky wrote:
> Hi,
>
> It is kind of tricky.
>
> The availability of data on the file descriptor returned with ZMQ_FD
> signals that there is a zmq socket state change, i.e. the receive
> queue goes from empty to non-empty. Any operation on the socket
> (send/receive/getsockopt with ZMQ_EVENTS) may clear the notification.
> No further notifications will be received until there is another state
> change. This means the application has to continue sending/receiving
> data until getsockopt with ZMQ_EVENTS says further operations are not
> possible. The application should not access the file descriptor
> directly beyond using it as poll/epoll file descriptor.
>
> I am not familiar with boost::aio, but you'll need to do at least the
> following:
> 1) define your own read handler which is called when the file
>descriptor signals data availability, which will call
>zmq_msg_recv() on corresponding zmq socket.
> 2) either exhaust the incoming data completely each time read handler
>is called, or somehow mark the file descriptor as having the data
>available so your read handler is called again when the control is
>returned to the library.
>
> Max
>
>
>
> On Tue, Nov 15, 2016 at 5:06 AM, Arnaud Kapp
>  wrote:
>> Hello,
>>
>> I'm using zmqpp in my project, and I have a special case where I need
>> to integrate
>> with boost::asio (this is what azmq does, but for now I just need it
>> once, so I don't want
>> to switch libraries).
>>
>> The idea was to rely on ZMQ_FD and add the corresponding FD to ASIO's
>> event loop.
>> However, I've found that async_read_some() wasn't triggered. It turns
>> out it's likely an issue
>> in libzmq: https://github.com/zeromq/libzmq/issues/1434
>>
>> After taking a quick look at AZQM it seems it's also using ZMQ_FD.
>> Can anyone tell me what's the trick to get them to work?
>> Thanks,
>>
>>
>> --
>> Kapp Arnaud - Xaqq
>>
>>
>> ___
>>  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] Newbie question re websockets

[Justin Karneges]

There are a couple of ways to look at this:
 
1) For doing ZeroMQ communication over a WebSocket, there is "ZWS". It
   seems to be a work in progress. Some code here:
   https://github.com/zeromq/zwssock
 
2) For gatewaying from a ZeroMQ application to arbitrary WebSocket peers
   there's Mongrel2 ( http://mongrel2.org ) and Zurl (
   https://github.com/fanout/zurl ).
 
On Tue, Jun 21, 2016, at 07:53 AM, Mike Lowry wrote:
> I am building an application to provide a range of transaction-
> oriented services to native clients on various platforms.
>
> I am long-time familiar with the Microsoft stack, but after analyzing
> the cost of scaling up I decided to move to an Ubuntu server platform.
> I intend to use websockets (WSS) for communications due to the
> continued bidirectional connection, efficiency and security.  I
> discovered ØMQ and have begun reading the guide and other
> documentation, but am not yet sufficiently familiar with the protocols
> to differentiate or determine if conflict exists in this decision.  I
> have been unable to find anything “official” in the Guide or
> Reference. A general search has provided a multiplicity of commentary,
> mostly out-of-date, so I thought I would ask directly – where can I
> find current, valid documentation on the use/non-use of websockets
> with ØMQ?  Any guidance you can provide will be much appreciated.
>
> *Mike Lowry*
> Email m...@techcitysouth.com
> Phone 678-462-2338
>
> _
> 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] Broadcast mode for ZMQ_STREAM

[Justin Karneges]

Hey Jens,
 
My initial thought is that this doesn't feel right. You'd be limited to
broadcast (making it a kind of substandard PUB), and you'd need to
change the "mute state" behavior too (otherwise a single slow client
triggers EAGAIN).
 
On Fri, Jun 17, 2016, at 10:09 AM, Jens Auer wrote:
> Hi,
>
> I am using ZMQ_STREAM to receive and deliver data from/to non-zeroMQ
> applications. For delivery, I have to send the data to a number of
> connected clients. All clients receive a copy of the data. Since a
> ZMQ_STREAM socket needs a first peer identity part, I have to manually
> add this every time I send a data message, and keep track of connected
> client ids. I think it would be nice if ZMQ_STREAM could do this
> internally. I think this could be done by allowing empty peer ids
> which are then interpreted as “broadcast”. Any thoughts on this?
>
> Best wishes,
> Jens
>
>
> Virenfrei. www.avast.com[1]
> _
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
 

Links:

  1. 
https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] What are the “serious caveats” with ZMQ_FD?

[Justin Karneges]

I would not rely on this. Query ZMQ_EVENTS after every send no matter
what.

On Mon, May 23, 2016, at 02:23 AM, Huttunen, Kalle (GE Healthcare)
wrote:
> It seems that sending on the socket makes the ZMQ_FD readable. That in
> turn triggers the calling of the code where I check ZMQ_EVENTS and
> receive everything from the socket. This way I end up checking ZMQ_EVENTS
> after each send.
> 
> Is the ZMQ_FD becoming readable when sending on the socket something that
> can be relied on?
> 
> -- 
> Kalle Huttunen
> ___
> 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] What are the “serious caveats” with ZMQ_FD?

[Justin Karneges]

"update the state" is strange wording but it means you need to query
ZMQ_EVENTS.
 
And yes, you should assume that even a call to zmq_recv() might yield a
situation where there is more to read, but the fd doesn't become
readable. Basically, check ZMQ_EVENTS after every call to zmq_send or
zmq_recv, and whenever the fd becomes readable, regardless of which
events you are interested in.
 
On Mon, May 2, 2016, at 01:07 AM, Kalle Huttunen wrote:
> Okay, this one I missed because I was looking at an old version of the
> man page (http://api.zeromq.org/master:zmq-getsockopt takes you to
> 2.2.0 man page).
>
> Full quote from the 4.1.5 man page
> (http://api.zeromq.org/4-1:zmq-getsockopt):
>
> "The returned file descriptor is also used internally by the zmq_send
> and zmq_recv functions. As the descriptor is edge triggered,
> applications must update the state of ZMQ_EVENTS after each invocation
> of zmq_send or zmq_recv.To be more explicit: after calling zmq_send
> the socket may become readable (and vice versa) without triggering a
> read event on the file descriptor."
>
> This definitely sounds like a caveat I should handle. The quote raises
> some questions, though:
>
> - What exactly does it mean to "update the state of ZMQ_EVENTS"?
>
> - Do both zmq_send() and zmq_recv() reset all events in the FD? So if
>   I'm only interested on events about incoming messages (I check only
>   ZMQ_POLLIN from ZMQ_EVENTS), do I need to "update the state of
>   ZMQ_EVENTS" after both zmq_send() and zmq_recv(), or is it enough to
>   do it only after zmq_send()?
>
> --
> Kalle Huttunen
>
> ma 2. toukokuuta 2016 klo 4.16 KIU Shueng Chuan 
> kirjoitti:
>> From the man page for zmq_getsockopt:
>> "after calling zmq_send the socket may become readable (and vice
>> versa) without triggering a read event on the file descriptor."
>>
>> On 1 May 2016 3:33 am, "Kalle Huttunen"  wrote:
>>> The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why
>>> can't I use standard I/O multiplexing functions such as select() or
>>> poll() on ZeroMQ sockets?" question:
>>>
>>> > Note that there's a way to retrieve a file descriptor from ZeroMQ
>>> > socket (ZMQ_FD socket option) that you can poll on from version
>>> > 2.1 onwards, however, there are some serious caveats when using
>>> > it. Check the documentation carefully before using this feature.
>>>
>>> I've prototyped integrating ZeroMQ socket receiving to Qt's and
>>> custom select() based event loops, and on the first glance
>>> everything seems to work.
>>>
>>> From the documentation I have identified two "caveats" that I handle
>>> in my code:
>>>
>>> 1. The ability to read from the returned file descriptor does not
>>>necessarily indicate that messages are available to be read from
>>>the socket
>>>
>>> This I have solved by checking ZMQ_EVENTS before reading from the
>>> socket.
>>>
>>> 2. Events are signaled in edge-triggered fashion
>>>
>>> This one I have solved by always receiving all the messages from the
>>> socket when the file descriptor signals.
>>>
>>> Are there some caveats that I'm missing?
>>>
>>> --
>>> Kalle Huttunen
>>>
>>> ___
>>>  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] What are the “serious caveats” with ZMQ_FD?

[Justin Karneges]

I believe multipart messages are treated atomically, which means if
you're able to receive the first part then you're able to receive all
the remaining parts immediately. When QZmq was first written I was not
aware of the atomic handling, and so the code is probably more complex
than it needs to be.
 
On Sat, Apr 30, 2016, at 11:45 PM, Kalle Huttunen wrote:
> Hi, thanks for your answer. The README of your QZmq project rises up
> an interesting point: multipart messages. How do they work in relation
> to ZMQ_FD? When the FD signals read, have all message parts been
> received?
>
> --
> Kalle Huttunen
>
> la 30. huhtikuuta 2016 klo 23.16 Justin Karneges <jus...@affinix.com>
> kirjoitti:
>> __
>> Expanding on your first point: the file descriptor only triggers read
>> notifications, and the notification means to query ZMQ_EVENTS. For
>> example, when a zmq socket becomes writable, the ZMQ_FD file
>> descriptor becomes readable, and you react to that by checking
>> ZMQ_EVENTS and discover the zmq socket can be written to.
>>
>> Also you may be interested in https://github.com/jkarneges/qzmq
>>
>> On Sat, Apr 30, 2016, at 12:32 PM, Kalle Huttunen wrote:
>>> The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why
>>> can't I use standard I/O multiplexing functions such as select() or
>>> poll() on ZeroMQ sockets?" question:
>>>
>>> > Note that there's a way to retrieve a file descriptor from ZeroMQ
>>> > socket (ZMQ_FD socket option) that you can poll on from version
>>> > 2.1 onwards, however, there are some serious caveats when using
>>> > it. Check the documentation carefully before using this feature.
>>>
>>> I've prototyped integrating ZeroMQ socket receiving to Qt's and
>>> custom select() based event loops, and on the first glance
>>> everything seems to work.
>>>
>>> From the documentation I have identified two "caveats" that I handle
>>> in my code:
>>>
>>> 1. The ability to read from the returned file descriptor does not
>>>necessarily indicate that messages are available to be read from
>>>the socket
>>>
>>> This I have solved by checking ZMQ_EVENTS before reading from the
>>> socket.
>>>
>>> 2. Events are signaled in edge-triggered fashion
>>>
>>> This one I have solved by always receiving all the messages from the
>>> socket when the file descriptor signals.
>>>
>>> Are there some caveats that I'm missing?
>>>
>>> --
>>> Kalle Huttunen
>>> _
>>> 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] What are the “serious caveats” with ZMQ_FD?

[Justin Karneges]

Expanding on your first point: the file descriptor only triggers read
notifications, and the notification means to query ZMQ_EVENTS. For
example, when a zmq socket becomes writable, the ZMQ_FD file descriptor
becomes readable, and you react to that by checking ZMQ_EVENTS and
discover the zmq socket can be written to.
 
Also you may be interested in https://github.com/jkarneges/qzmq
 
On Sat, Apr 30, 2016, at 12:32 PM, Kalle Huttunen wrote:
> The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why
> can't I use standard I/O multiplexing functions such as select() or
> poll() on ZeroMQ sockets?" question:
>
> > Note that there's a way to retrieve a file descriptor from ZeroMQ
> > socket (ZMQ_FD socket option) that you can poll on from version 2.1
> > onwards, however, there are some serious caveats when using it.
> > Check the documentation carefully before using this feature.
>
> I've prototyped integrating ZeroMQ socket receiving to Qt's and custom
> select() based event loops, and on the first glance everything seems
> to work.
>
> From the documentation I have identified two "caveats" that I handle
> in my code:
>
> 1. The ability to read from the returned file descriptor does not
>necessarily indicate that messages are available to be read from
>the socket
>
> This I have solved by checking ZMQ_EVENTS before reading from
> the socket.
>
> 2. Events are signaled in edge-triggered fashion
>
> This one I have solved by always receiving all the messages from the
> socket when the file descriptor signals.
>
> Are there some caveats that I'm missing?
>
> --
> Kalle Huttunen
> _
> 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] Moving list to Google groups?

[Justin Karneges]

Hey folks,

I spoke with MailmanLists and they are willing to host the ZeroMQ
mailing list for free. All they ask for is a link on the mailing list
page. If you'd prefer the list remain Mailman-based and simply don't
want to host it, then I'd say this is the best the way to go. They'll
import archives too.

Re: MailmanLists vs. dotList (aka Mailmanhost), both appear to be
Mailman hosting experts with a long lives (8 years and 11 years,
respectively). Other than cost, it's hard to say on the outside which
one is better, but as a customer of MailmanLists I can vouch for their
helpful support. MailmanLists also claims to be a financial contributor
to the FSF which is pretty cool.

On Mon, Apr 18, 2016, at 05:21 PM, c wrote:
> Jim Idle  writes:
> 
> I'm a nay on Google Groups. As seen with SourceForge, sometimes the
> priorities of companies change. This is especially true for a publically
> traded company.
> 
> The price points of https://www.mailmanhost.com/pricing/ seem better
> than http://www.mailmanlists.net/ but I have no personal experience with
> either.
> 
> > You just add your email address to the google list - you don't
> > actually need a Google account. Thre is really no difference to now.
> 
> In my experience list maintainers end up needing to enable the Google
> Account
> requirement on their groups to combat spam. 
> ___
> 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] Moving list to Google groups?

[Justin Karneges]

If you like Mailman, I suggest http://www.mailmanlists.net/ . It's
affordable, and the admins are responsive and helpful. I recently
started using it on one of my lists.

Google groups is decent. I use it on a couple of my other lists. The
Google account stuff is a little obnoxious but it's hard to beat free.

On Wed, Apr 13, 2016, at 03:45 PM, Pieter Hintjens wrote:
> Hi all,
> 
> I'd like to raise this question for discussion. The problem is that
> zeromq-dev is running on an iMatix server, and I'd like to remove
> iMatix infrastructure from our community, over time. It's a matter of
> long term sustainability.
> 
> (Apart from the list, iMatix also hosts downloads.zeromq.org which we
> can start to move to Github release attachments IMO.)
> 
> Anyhow, re. lists, let's weigh pros and cons of Google groups versus
> other options. I'll make the decision based on this thread and other
> factors.
> 
> Thanks
> 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] Zeromq behaviour on tcp reconnection, and socket IDs

[Justin Karneges]

Sounds mostly right.

Indeed there is a queue per "known" ZeroMQ connection. For clients, this
means a queue is created the moment zmq_connect() is called and the
queue persists regardless of whether or not the underlying transport
(e.g. TCP) is actually connected. For servers, this means a queue only
exists while a client is connected and is destroyed afterwards. Note
that the ZeroMQ socket objects themselves only have queues in the
context of connections. If a ZeroMQ socket has three known connections,
then there are three queues. If it has no known connections, then there
are no queues. This is why writing to a server socket with no clients
connected to it may block, because there is no queue yet. The
ZMQ_IMMEDIATE option can be used to make clients only have queues when a
connection is established, similar to server behavior.

As for when underlying transport connections are made, it is my
understanding that this is done automatically regardless of whether
or not you try to write or read on the socket. So you should not need
to call recv to force a reconnect or anything, but I could be wrong
about this.

One gotcha to be aware of with reconnections is that ZeroMQ may not
detect a dead connection unless it has data to write. In this case,
sending data may induce a reconnect. However, this is not possible to do
with all socket types (e.g. PULL). Best to use ZMQ_TCP_KEEPALIVE if you
want to ensure all connections will get automatically repaired.

On Tue, Feb 9, 2016, at 05:46 AM, Tom Quarendon wrote:
> Hi,


> I’m trying to get clear in my mind how the reconnection logic works in
> zeromq. It doesn’t seem to be explained anywhere that I can find, but
> apologies if I’ve missed something.


>


> I think that the behaviour must be something like follows. I’m
> considering “request/reply” flows here, don’t know whether the
> situation is different for pub/sub types, haven’t considered those
> yet. I’m also specifically considering tcp,
 but I guess ipc would be the same (being another disconnected transport
 in zeromq).


>


> The “client” (being the one who connects) will attempt to reconnect
> the tcp socket when it has a message in the output buffer that it
> needs to send. The fact that the connection is lost doesn’t affect the
> output buffer, if I’ve done a zmq_msg_send
 that message won’t be lost inside zmq if the tcp connection is lost.
 Zeromq just tried to remake the connection, and once it has it can send
 the next message on the output buffer. The client CAN reconnect,
 because it did the original connection.


>


> The “client” will also attempt to reconnect if it does a recv and the
> connection is broken. Again, it CAN connect. This doesn’t affect the
> buffers in which zeromq holds the incoming messages that it reads from
> the socket before they get
 passed to the application. Once a message is received from the tcp
 socket and put on the internal buffers, it isn’t lost just because the
 socket needs reconnecting.


>


> If the “server” detects a lost connection, it just closes down the
> socket, throws away the buffers and so on. The server CAN’T initiate a
> reconnect, it wouldn’t know where to connect to. In an environment
> where clients come and go frequently,
 say, in a public Wi-Fi environment, it would soon run out of resources
 otherwise. Since there’s nothing it can use to correlate a client
 reconnecting (the source port may be different, the IP address may have
 even changed), there’s nothing it could usefully do with the messages
 anyway, outbound ones especially (possibly it could keep the inbound
 queue and throw that away once empty). When the client reconnects, then
 as far as zeromq is concerned, it’s just another new connection.


>


> The client setting an identity on the socket would allow the
> **application** code in the server to correlate messages, to tell that
> these two apparently unrelated connections are actually from the same
> source, but essentially means
 nothing to zeromq itself.


>


> Is that a reasonable description, or do I have it wrong somewhere?


>


> 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] last message lost in pipeline

[Justin Karneges]

It would be cool if libzmq, during shutdown, would write as much to the
socket as it can before quitting. This way, small messages could live in
the operating system's send buffer and survive after the process
terminates. Of course if messages are too large, or there are too many
messages, then those might be lost.

On Wed, Jan 27, 2016, at 06:28 AM, Tomaz Beltram wrote:
> Thanks for this information. I can work around it now that I know its a
> known issue. I already have another REQ/REP control connection that can
> handle this case.
> 
> On 27. 01. 2016 15:16, Pieter Hintjens wrote:
> > There are issues using zmq_ctx_destroy where if we wait for messages
> > to be sent, it can deadlock. Afair we do not wait and thus in some
> > cases the last message can be lost.
> >
> > My advice is to not trust your transport to send the last message in a
> > stream. Rather, use a handshake to close a connection. If you can't do
> > this (and over push/pull you can't) then the only other option is to
> > wait a while before closing the socket.
> >
> >
> >
> > On Wed, Jan 27, 2016 at 1:58 PM, Tomaz Beltram  
> > wrote:
> >> Hi,
> >>
> >> I am using the pipeline pattern with one PULL socket with zmq_bind() to
> >> an arbitrary port on the localhost interface (tcp://127.0.0.1:*) and one
> >> PUSH socket with zmq_connect() to the port that was assigned by the system.
> >>
> >> The sender may finish and call zmq_close() and zmq_ctx_destroy() before
> >> the receiver gets all messages that were sent. This should be OK, since
> >> according to the documentation zmq_close() should wait for undelivered
> >> messages to be transferred.
> >>
> >> Very rarely I observe that the last message that was sent is never
> >> received. I was not able to reproduce the issue with a minimum test case
> >> that I prepared and even in the real application its occurrence is very
> >> seldom. Still I would like to track it down and avoid if possible. Any
> >> ideas what I should do differently?
> >>
> >> wbr
> >> Tomaz
> >> ___
> >> 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] level-triggered FD

[Justin Karneges]

Also beware that inproc sockets are broken with ZMQ_FD. 
https://github.com/zeromq/libzmq/issues/1434

If you decide to work on level-triggered FDs, you might ensure that it
works for all socket types.

On Tue, Jan 26, 2016, at 09:29 AM, Doron Somech wrote:
> I will give it some time in the ZeroMQ hackathon :-)
>
> On Tue, Jan 26, 2016 at 5:51 PM, MinRK  wrote:
>>
>>
>> On Fri, Jan 22, 2016 at 5:30 PM, Doron Somech
>>  wrote:
>>> the FD must be read-only, it might be possible in some OS but I
>>> won't be portable.
>>>
>>> Regarding the Command FD, it must be used, otherwise the Recv/Send
>>> FD won't work.
>>>
>>> So in your case you need to be add the event-loop both the command
>>> FD (which is the regular FD) and Recv/Send FD.
>>>
>>> When command FD is signaled you must call zmq_process_comands, which
>>> currently doesn't exist. When recv/send FD is signaled you can call
>>> recv/send. zmq_process_command it what causing the other FDs to get
>>> signaled.
>>>
>>> The bottom line, this is kind of syntactic sugar, it will be the
>>> equivalent of calling has_in or has_out immediately after FD is
>>> signaled and only then call recv/send.
>>
>>
>> Gotcha, thanks for the explanation. I think this will still be a huge
>> improvement.
>>
>>
>> -MinRK
>>
>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jan 22, 2016 at 5:54 PM, MinRK  wrote:


 On Fri, Jan 22, 2016 at 4:19 PM, Doron Somech 
 wrote:
> The FD today is signalled when ever a command should be processes.
> What we can do is split it to 3 different FD:


> * Command FD : The one being used right now, this still must be
>   used, when ever signalled call process commands (which we should
>   expose in API).
>
* Recv FD: use as level triggered to receive.
>
* Send FD: use as level triggered to send.

> Only issue with this solution, you should include in your event
> loop minimum two FD, one for processing commands and one for send/
> recv.



 I think two FDs would be fine; certainly better than what we have
 now. It would eliminate the significant problem of one signal for
 separate events. Perhaps this is a naïve question: Is it not
 possible to have an FD signal writable when the socket becomes
 writable and readable when the socket becomes readable? If they
 both have to be read-only FDs, that seems fine, as long as the
 signaling for send and recv are separated somehow. I'm not sure
 what users would do with the Command FD.


 -MinRK


> For thread safe sockets this is a little simpler as we can make
> one FD for all sockets for processing commands.


> On Jan 22, 2016 2:52 PM, "Pieter Hintjens"  wrote:
>> Yes, the edge triggered FD in libzmq has been a constant
>> source of
>>
annoyance. Maybe someone on this list knows how to fix it.
>>
>>
On Fri, Jan 22, 2016 at 1:40 PM, MinRK  wrote:
>>
> Hi all,
>>
>
>>
> I've implemented yet another eventloop integration in pyzmq
> (asyncio, this
>>
> time), and this is only nontrivial because of the edge-triggered
> read-only
>>
> zmq.FD. Integrating into existing eventloops would be much easier
> if we had
>>
> a more traditional level-triggered FD to work with.
>>
>
>>
> Is there a technical reason why we can't add a zmq.LEVEL_FD that would
>>
> behave in a more conventional manner:
>>
>
>>
> - level-triggered
>>
> - signal write when socket is writable
>>
> - signal read when socket is readable
>>
>
>>
> I would work on this myself, but unfortunately I don't think I
> have the
>>
> relevant expertise.
>>
>
>>
> -MinRK
>>
>
>>
> ___
>>
> 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 

Re: [zeromq-dev] state of publishers and subscribers via ZMQ_PUB and ZMQ_SUB

[Justin Karneges]

Ah, yes I didn't think about non-graceful disconnects. Enabling TCP
keep alives is probably the best answer in terms of keeping ZeroMQ
usage pure, though I know there are some concerns about this as a
general solution.

Keep alives in the ZMTP protocol would be ideal. Is this being
considered?

On Fri, Oct 23, 2015, at 10:49 PM, Doron Somech wrote:
> Just to clarify, zeromq doesn't recognize disconnection (yet),
> operating system is, however it cannot recognize disconnection when it
> is not graceful. This why we need the heart beat. The reason the
> publisher need to be the client, the one doing connect is responsible
> to do reconnections and only send operation can recognize
> disconnection when it is ungraceful (recv will block forever or until
> send operation happen on the same socket). Because in pub/sub only
> publisher is doing send operation publisher need to be the client for
> reconnection to happen automatically.


> On Oct 24, 2015 6:54 AM, "Justin Karneges" <jus...@affinix.com> wrote:
>> __
>> Sockets automatically reconnect. You don't have to think about
>> connections, just messages.
>>
>>
>> On Fri, Oct 23, 2015, at 08:01 PM, Aravind Sethuraman wrote:
>>> sorry i guess the answer to my question is in Zoron's email
>>> ...subscribe to ping heartbeatok i will give this a shot...
>>>
>>> thanks everyone
>>>
>>> On Fri, Oct 23, 2015 at 10:47 PM, Aravind Sethuraman
>>> <arvi...@gmail.com> wrote:
>>>> interesting point...so if sockets do not connect or are in midst of
>>>> connecting or were connected and a system comes down, upon restart,
>>>> do systems implicitly reconnect?
>>>>
>>>> On Fri, Oct 23, 2015 at 9:54 PM, Justin Karneges
>>>> <jus...@affinix.com> wrote:
>>>>> __
>>>>> With ZeroMQ, any socket type can bind or connect. Who binds and
>>>>> who connects is matter of which entities should have stable or
>>>>> dynamic existence, not who is acting as a "server" in some kind of
>>>>> traditional sense. So yeah, you can have a PUB socket connect to a
>>>>> SUB socket and vice versa. Similarly you can have a REP socket
>>>>> connect to a REQ socket. Realizing that these combinations are
>>>>> possible is one of those "ah-hah" moments of enjoying ZeroMQ. :)
>>>>>
>>>>> As for knowing when subscribers are connecting/reconnecting, in
>>>>> general you should not need to care about this.
>>>>>
>>>>> On Fri, Oct 23, 2015, at 06:21 PM, Aravind Sethuraman wrote:
>>>>>> hello doron, i am actually interested in making the publisher a
>>>>>> client and subscriber a server. Correct me if i am wrong but is
>>>>>> it not a departure from the usual understanding of publisher
>>>>>> being a server and subscriber clients? is it even possible to do
>>>>>> that (i am guessing since you mentioned it; it must be ) . also
>>>>>> how do i know which subscribers are connected and are
>>>>>> reconnecting etc?
>>>>>>
>>>>>> On Fri, Oct 23, 2015 at 5:55 PM, Justin Karneges
>>>>>> <jus...@affinix.com> wrote:
>>>>>>> __
>>>>>>> If you make the subscriber the client, reconnections should
>>>>>>> still work. I tested this myself again just now to be sure.
>>>>>>>
>>>>>>> On Fri, Oct 23, 2015, at 02:07 PM, Doron Somech wrote:
>>>>>>>> make the publisher the client (connect) and the subscriber the
>>>>>>>> server (bind), this is important, it will not work the other
>>>>>>>> way, send heartbeat from publisher every X seconds (don't
>>>>>>>> forget to make sure subscriber subscribe to the heartbeat). If
>>>>>>>> you do it that way reconnection will happen automatically.
>>>>>>>> Alternatively you can just enable TCP keep alive.


>>>>>>>> On Oct 23, 2015 11:53 PM, "Aravind Sethuraman"
>>>>>>>> <arvi...@gmail.com> wrote:
>>>>>>>>> I am building a full mesh of publishers and subscribers (no
>>>>>>>>> brokers) and as i would like to implement re-connecting when
>>>>>>>>> there is a reboot of a node. How can i get a list of current
>>>>>&g

Re: [zeromq-dev] state of publishers and subscribers via ZMQ_PUB and ZMQ_SUB

[Justin Karneges]

Sockets automatically reconnect. You don't have to think about
connections, just messages.


On Fri, Oct 23, 2015, at 08:01 PM, Aravind Sethuraman wrote:
> sorry i guess the answer to my question is in Zoron's email
> ...subscribe to ping heartbeatok i will give this a shot...
>
> thanks everyone
>
> On Fri, Oct 23, 2015 at 10:47 PM, Aravind Sethuraman
> <arvi...@gmail.com> wrote:
>> interesting point...so if sockets do not connect or are in midst of
>> connecting or were connected and a system comes down, upon restart,
>> do systems implicitly reconnect?
>>
>> On Fri, Oct 23, 2015 at 9:54 PM, Justin Karneges
>> <jus...@affinix.com> wrote:
>>> __
>>> With ZeroMQ, any socket type can bind or connect. Who binds and who
>>> connects is matter of which entities should have stable or dynamic
>>> existence, not who is acting as a "server" in some kind of
>>> traditional sense. So yeah, you can have a PUB socket connect to a
>>> SUB socket and vice versa. Similarly you can have a REP socket
>>> connect to a REQ socket. Realizing that these combinations are
>>> possible is one of those "ah-hah" moments of enjoying ZeroMQ. :)
>>>
>>> As for knowing when subscribers are connecting/reconnecting, in
>>> general you should not need to care about this.
>>>
>>> On Fri, Oct 23, 2015, at 06:21 PM, Aravind Sethuraman wrote:
>>>> hello doron, i am actually interested in making the publisher a
>>>> client and subscriber a server. Correct me if i am wrong but is it
>>>> not a departure from the usual understanding of publisher being a
>>>> server and subscriber clients? is it even possible to do that (i am
>>>> guessing since you mentioned it; it must be ) . also how do i know
>>>> which subscribers are connected and are reconnecting etc?
>>>>
>>>> On Fri, Oct 23, 2015 at 5:55 PM, Justin Karneges
>>>> <jus...@affinix.com> wrote:
>>>>> __
>>>>> If you make the subscriber the client, reconnections should still
>>>>> work. I tested this myself again just now to be sure.
>>>>>
>>>>> On Fri, Oct 23, 2015, at 02:07 PM, Doron Somech wrote:
>>>>>> make the publisher the client (connect) and the subscriber the
>>>>>> server (bind), this is important, it will not work the other way,
>>>>>> send heartbeat from publisher every X seconds (don't forget to
>>>>>> make sure subscriber subscribe to the heartbeat). If you do it
>>>>>> that way reconnection will happen automatically. Alternatively
>>>>>> you can just enable TCP keep alive.


>>>>>> On Oct 23, 2015 11:53 PM, "Aravind Sethuraman"
>>>>>> <arvi...@gmail.com> wrote:
>>>>>>> I am building a full mesh of publishers and subscribers (no
>>>>>>> brokers) and as i would like to implement re-connecting when
>>>>>>> there is a reboot of a node. How can i get a list of current
>>>>>>> state of subscribers to a publisher node?
>>>>>>>
>>>>>>> thanks aRavind
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> 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] state of publishers and subscribers via ZMQ_PUB and ZMQ_SUB

[Justin Karneges]

With ZeroMQ, any socket type can bind or connect. Who binds and who connects is 
matter of which entities should have stable or dynamic existence, not who is 
acting as a "server" in some kind of traditional sense. So yeah, you can have a 
PUB socket connect to a SUB socket and vice versa. Similarly you can have a REP 
socket connect to a REQ socket. Realizing that these combinations are possible 
is one of those "ah-hah" moments of enjoying ZeroMQ. :)

As for knowing when subscribers are connecting/reconnecting, in general
you should not need to care about this.

On Fri, Oct 23, 2015, at 06:21 PM, Aravind Sethuraman wrote:
> hello doron, i am actually interested in making the publisher a client
> and subscriber a server. Correct me if i am wrong but is it not a
> departure from the usual understanding of publisher being a server and
> subscriber clients? is it even possible to do that (i am guessing
> since you mentioned it; it must be ) . also how do i know which
> subscribers are connected and are reconnecting etc?
>
> On Fri, Oct 23, 2015 at 5:55 PM, Justin Karneges
> <jus...@affinix.com> wrote:
>> __
>> If you make the subscriber the client, reconnections should still
>> work. I tested this myself again just now to be sure.
>>
>> On Fri, Oct 23, 2015, at 02:07 PM, Doron Somech wrote:
>>> make the publisher the client (connect) and the subscriber the
>>> server (bind), this is important, it will not work the other way,
>>> send heartbeat from publisher every X seconds (don't forget to make
>>> sure subscriber subscribe to the heartbeat). If you do it that way
>>> reconnection will happen automatically. Alternatively you can just
>>> enable TCP keep alive.


>>> On Oct 23, 2015 11:53 PM, "Aravind Sethuraman" <arvi...@gmail.com>
>>> wrote:
>>>> I am building a full mesh of publishers and subscribers (no
>>>> brokers) and as i would like to implement re-connecting when there
>>>> is a reboot of a node. How can i get a list of current state of
>>>> subscribers to a publisher node?
>>>>
>>>> thanks aRavind
>>>>
>>>>
>>>>
>>>> ___
>>>> 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] state of publishers and subscribers via ZMQ_PUB and ZMQ_SUB

[Justin Karneges]

If you make the subscriber the client, reconnections should still work.
I tested this myself again just now to be sure.

On Fri, Oct 23, 2015, at 02:07 PM, Doron Somech wrote:
> make the publisher the client (connect) and the subscriber the server
> (bind), this is important, it will not work the other way, send
> heartbeat from publisher every X seconds (don't forget to make sure
> subscriber subscribe to the heartbeat). If you do it that way
> reconnection will happen automatically. Alternatively you can just
> enable TCP keep alive.


> On Oct 23, 2015 11:53 PM, "Aravind Sethuraman"
>  wrote:
>> I am building a full mesh of publishers and subscribers (no brokers)
>> and as i would like to implement re-connecting when there is a reboot
>> of a node. How can i get a list of current state of subscribers to a
>> publisher node?
>>
>> thanks aRavind
>>
>>
>>
>> ___
>>
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] Tie Breaker

[Justin Karneges]

Sure thing. And yeah, if you're always polling forever for writability
before writing, then you effectively have a backpressure strategy.

Note that if you begin polling for read and write at the same time, then
you open the door to potentially processing new data while you've still
got pending outbound data to write, and then you will face those three
choices I mentioned.

On Tue, Jul 28, 2015, at 05:07 PM, Kenneth Adam Miller wrote:
 Thank you, by the way.

 On Tue, Jul 28, 2015 at 8:07 PM, Kenneth Adam Miller
 kennethadammil...@gmail.com wrote:
 There's no need to take any of those options because in my case,
 because the producer polls every time before sending.

 I think I realize with your first sentence what I missed when I
 wasn't vocalizing my issue. I think I now know that it's not because
 the other clients aren't concurrent that there is an issue, it's the
 lack of isolating the location in code for polling into doing both
 read and write polling in one call. If it were one call, then the
 send lockup could never happen, but right now, it occurs in sequence,
 where if you return from polling for read, you read, do work, and
 then poll before sending that back out. In any case, I think I am
 highly confident I have the correct implementation path now.

 On Tue, Jul 28, 2015 at 7:43 PM, Justin Karneges
 jus...@affinix.com wrote:
 __
 You can poll for read and write at the same time, so there shouldn't
 be any issue with both peers sending simultaneously and then failing
 to read.

 Note that if you can't write, then you need to think about how to
 manage your outbound messages. The three basic choices you have are:
 1) Backpressure (while waiting to write, stop doing anything that
causes new messages to be produced)
 2) Drop messages
 3) Queue every message, indefinitely (caution to the wind!)

 The third option is almost never what you want. It sucks having to
 choose between the first and second options but that's reality. Once
 you've decided on your strategy then you'll know what code to write.

 On Tue, Jul 28, 2015, at 04:28 PM, Kenneth Adam Miller wrote:
 I can't use ZeroMQ for this, because I know if I could this
 wouldn't be a problem. But since there are so many systems
 engineers on the channel and fundamentally it's what ZMQ aims to
 solve, I think it's the appropriate place.

 For a scalability benchmark meant to emulate our real world
 scenario, I have a cycle created between a producer and a consumer,
 where the producer spams a fifo object that the consumer is
 listening on. The consumer does some validation work on the data
 that it was hit with and sends it back out over a different fifo
 object that the producer is concurrently listening to (rather it's
 a chain of four processes linked in this way).

 -   process_echo - Producer
 consumer                -    process_echo -

 This works fine from the perspective of the producer, because
 listening and writing requires no coordination between threads. But
 the producer and echoing processes were written singled threaded,
 and from the perspective that it would poll only for input and not
 for when it writes.

 Well, as my testing went along I discovered that I had to make both
 the producer and consumer poll on output so that no data could be
 lost when the sender goes to send and the fifo isn't being read
 from fast enough. (possibly that's wrong)

 But using poll on the sender has caused hangups on the system as a
 whole. Poll returns for readers, I think, when someone has already
 written or is writing. And for writers, when someone is blocking
 (whether polling or in read) to read.

 But the problem that this solves brings up a different problem: if
 the single threaded programs poll to write, then the cycle could
 deadlock where every side is polling to write, before even one
 message makes it fully round circle.

 My thought is, I could break it by making the consumer concurrent
 in reading and writing, that way, lockup on send cannot happen,
 because there will always be a reader to allow execution to
 continue in the echo tool and consumer. But that's hard because the
 code base is large.

 I said all of that just to ask-does anybody have any alternative
 suggestions regarding how to approach this exact problem?

 All fifo objects are in non-blocking mode.
 _
 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] Tie Breaker

[Justin Karneges]

You can poll for read and write at the same time, so there
shouldn't be any issue with both peers sending simultaneously and
then failing to read.

Note that if you can't write, then you need to think about how to manage
your outbound messages. The three basic choices you have are:
1) Backpressure (while waiting to write, stop doing anything that causes
   new messages to be produced)
2) Drop messages
3) Queue every message, indefinitely (caution to the wind!)

The third option is almost never what you want. It sucks having to
choose between the first and second options but that's reality. Once
you've decided on your strategy then you'll know what code to write.

On Tue, Jul 28, 2015, at 04:28 PM, Kenneth Adam Miller wrote:
 I can't use ZeroMQ for this, because I know if I could this wouldn't
 be a problem. But since there are so many systems engineers on the
 channel and fundamentally it's what ZMQ aims to solve, I think it's
 the appropriate place.

 For a scalability benchmark meant to emulate our real world scenario,
 I have a cycle created between a producer and a consumer, where the
 producer spams a fifo object that the consumer is listening on. The
 consumer does some validation work on the data that it was hit with
 and sends it back out over a different fifo object that the producer
 is concurrently listening to (rather it's a chain of four processes
 linked in this way).

 -   process_echo - Producer
 consumer                -    process_echo -

 This works fine from the perspective of the producer, because
 listening and writing requires no coordination between threads. But
 the producer and echoing processes were written singled threaded, and
 from the perspective that it would poll only for input and not for
 when it writes.

 Well, as my testing went along I discovered that I had to make both
 the producer and consumer poll on output so that no data could be lost
 when the sender goes to send and the fifo isn't being read from fast
 enough. (possibly that's wrong)

 But using poll on the sender has caused hangups on the system as a
 whole. Poll returns for readers, I think, when someone has already
 written or is writing. And for writers, when someone is blocking
 (whether polling or in read) to read.

 But the problem that this solves brings up a different problem: if the
 single threaded programs poll to write, then the cycle could deadlock
 where every side is polling to write, before even one message makes it
 fully round circle.

 My thought is, I could break it by making the consumer concurrent
 in reading and writing, that way, lockup on send cannot happen,
 because there will always be a reader to allow execution to
 continue in the echo tool and consumer. But that's hard because the
 code base is large.

 I said all of that just to ask-does anybody have any alternative
 suggestions regarding how to approach this exact problem?

 All fifo objects are in non-blocking mode.
 _
 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] socket event monitoring problem when using an event loop

[Justin Karneges]

Possibly related: https://github.com/zeromq/libzmq/issues/1434

You might see if you have better luck using async i/o with ipc instead
of inproc.

On Wed, Jul 1, 2015, at 07:47 AM, Chris Laws wrote:
 I was recently working on getting the socket event monitor working in
 an async focused Python library, aiozmq, and I had great difficulty
 getting it working reliably. Hopefully this post might save someone
 some time if they are trying something similar in the future.

 tl;dr when using async programming model (e.g. event loop) connect
 before bind when using using the socket monitor PAIR sockets.

 The library I was working with uses pyzmq for lots of its internals.
 It is worth noting that I had no problem using the socket monitor from
 pyzmq along with the typical blocking style approach where I would run
 the socket event monitor poller in a separate thread.

 However when I tried to use the socket monitor along with the
 asynchronous model encouraged by the Python (3.4) asyncio module I
 found that the delivery of socket events was very unreliable - often
 the events would only come through when I was shutting down the
 monitor transport (the socket) at the end of a test.

 I started out using pyzmq's get_monitor_socket function which would
 enable the socket monitor using the following sequence:
 - dynamically generate an inproc:// address to use;
 - request libzmq to create and bind a PAIR socket to the address;
 - create a new PAIR socket and connect it to the inproc:// address;
 - return the connected PAIR socket.

 This sequence of events turned out to be the cause of the problem I
 observed. However, this common approach only seems to be a problem
 when using the socket in an event loop (async) which is watching the
 file descriptor for a ready_ready event.

 I eventually found this problem mentioned here:
 https://github.com/mkoppanen/php-zmq/issues/130 and then here
 http://lists.zeromq.org/pipermail/zeromq-dev/2014-January/024545.html

 I changed the socket monitor enabling code sequence to:
 - create a dynamic inproc:// address;
 - create a new PAIR socket and attempt to connect it to the address
   (even through there is no PAIR socket bound to receive the
   connection)
 - request libzmq to create and bind a PAIR socket to the address;
 - return the connected PAIR socket.

 The exact implementation is here:
 https://github.com/aio-libs/aiozmq/blob/master/aiozmq/core.py#L537

 Using this sequence I was able to reliably monitor the PAIR socket's
 file descriptor to receive socket monitor events while running within
 the asyncio event loop.

 Regards, Chris

 _
 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] Ping Pong Heartbeats Quick Server Restart Issue

[Justin Karneges]

 I'm curious if anyone has solved this quick server restart problem in a
 clean way with socket patterns?  Or if you have other suggestions?  Or if
 you have example code of ping/pong handling this case I'd love to see it.

I suggest having the server send some kind of shutdown message. This is
basically the same as how regular TCP connection loss is indicated,
except that you have to do it yourself rather than the OS doing it for
you.

Of course, the advantage of the OS doing it for you is that you can
ensure a close packet is sent even if your process crashes. This may bit
a bit harder to do with ZeroMQ, depending on the language.
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] XPUB connect socket doesn't receive unsubscribe when peer disconnects

[Justin Karneges]

Seems to only happen if the XPUB connects rather than binds. Is this
intended behavior?

The problem is that if I restart the process on the other side (with a
SUB socket), then XPUB never clears the subscription, and so the
publisher could accumulate lots of old subscriptions over time.

Justin
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] SUB connect socket causes zmq_term to block

[Justin Karneges]

Hi,

I've noticed that if I create a SUB socket, call
setsockopt(...ZMQ_SUBSCRIBE...), and then connect to a peer that doesn't
exist (I'm using ipc://foo), and then call zmq_close() on the socket
followed by zmq_term(), then the termination will hang.

There is slightly more to it that I cannot figure out yet though. I
can't reproduce the bug in a small test program that only performs
exactly these steps. However, I can reproduce it 100% in my larger
event-driven application that uses ZMQ_FD and ZMQ_EVENTS with an event
loop (Qt). I report it in case anyone might have an idea about how this
can happen. I've tried strace to see what is different between my app
and a small test case, but nothing stands out.

Fortunately it is possible to work around by setting ZMQ_LINGER on the
socket. However I consider it a bug since SUB technically has no write
queue, at least from the application's perspective, so it should not
block shutdown.

My theory is that since SUB under the hood sends the subscription to the
publisher, it is the combination of a pending subscription and a connect
socket (which causes the queue to be created in the absence of a peer)
that causes the zmq engine to consider the socket to have a pending
write and so it employs the blocking behavior on shutdown, even though
the application didn't actually write anything. If I don't subscribe, or
if I bind instead of connect, or if I use a non-SUB socket, then this
problem doesn't occur. Further, if I create a second application that
binds to ipc://foo, and start this application while the original is
blocking on zmq_term, then the original will finish and exit. So it's
clearly waiting on a connect.

Happy to investigate this further if anyone can direct me.

Justin
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] A bit too reliable ;)

[Justin Karneges]

One thing you could do is have commands associated with a particular
child process lifetime. So when a child starts up, it sends a message to
the master process with a unique id representing itself as a running
instances, and then when a master sends a shutdown message it would
include this id. Child processes simply ignore messages from the master
if the id doesn't match the child's run id.

On Sat, Jan 10, 2015, at 11:42 AM, Daniel Krikun wrote:
 Hello,


 I have a problem which seems to arise from zeromq reliability
 behaviors.

There is a master that spawns few processes which perform some tasks on
its behalf; eventually the master sends a message over PUSH socket (one
for each process) to shutdown itself. After some time the master can
respawn the processes and so on.

The problem emerges when one of the child processes crashes prematurely:
the master still sends the shutdown message, the child process receives
it and shuts down mistakenly.

While I can think of at least 2 solutions: timestamping (to detect an
obsolete message), or heartbeat (to avoid sending shutdown message to a
dead process), I thought, there must be a way for master to reset a
connection *before* spawning the child process in order to purge
outgoing messages.

I tried to close() a socket but that didn't help.

 I'm using libzmq-2.2.0, TCP transport on a single Windows 7 x64
 machine.


 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] create a new job per HTTP request

[Justin Karneges]

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

Re: [zeromq-dev] ZMQ_FD clarification

[Justin Karneges]

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] Router socket reconnection failure

[Justin Karneges]

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] thoughts on pub-sub messaging and reliability

[Justin Karneges]

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] simple publish subscribe not working with zeromq

[Justin Karneges]

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

[Justin Karneges]

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] It looks like socket id's can't change with a router-router topology. Is that correct?

[Justin Karneges]

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] 0MQ-based proxy worker crashes with Assertion failed: pipe (bundled/zeromq/src/session_base.cpp:441)

[Justin Karneges]

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] restful access

[Justin Karneges]

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

[zeromq-dev] queue overhead

[Justin Karneges]

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] PUB/SUB unreliabiliity

[Justin Karneges]

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:
 

Re: [zeromq-dev] Router-Router Reconnection Issue

[Justin Karneges]

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] Task queues using ZeroMQ and inproc

[Justin Karneges]

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

[zeromq-dev] How to file an issue? (was: ROUTER not routing?)

[Justin Karneges]

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?

[Justin Karneges]

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] ROUTER not routing?

[Justin Karneges]

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

Re: [zeromq-dev] ROUTER not routing?

[Justin Karneges]

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?

[Justin Karneges]

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?

[Justin Karneges]

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?

[Justin Karneges]

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] ROUTER not routing?

[Justin Karneges]

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?

[Justin Karneges]

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?

[Justin Karneges]

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?

[Justin Karneges]

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] Linux: Qt support with ZeroMQ..

[Justin Karneges]

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..

[Justin Karneges]

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

Re: [zeromq-dev] Linux: Qt support with ZeroMQ..

[Justin Karneges]

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] Send HTTP request and get response using ZeroMQ

[Justin Karneges]

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

[Justin Karneges]

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] Send HTTP request and get response using ZeroMQ

[Justin Karneges]

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

[Justin Karneges]

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] Can we customize a behaviour for in-mem queued messages after reconnect?

[Justin Karneges]

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] will receive fail if TCP goes down in REQ socket

[Justin Karneges]

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] Does ZMQ handle tcp-RST?

[Justin Karneges]

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

[Justin Karneges]

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] What exact networking problems ZMQ does solve?

[Justin Karneges]

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

[zeromq-dev] pubsub subscription acknowledgement

[Justin Karneges]

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] thread affinity

[Justin Karneges]

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] thread affinity

[Justin Karneges]

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] Client-side web applications with ZeroMQ

[Justin Karneges]

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] wrong version number on website

[Justin Karneges]

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] http over zeromq spec

[Justin Karneges]

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?

[Justin Karneges]

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

Re: [zeromq-dev] Router socket messages lost when too quick after connection and how to know if ready to send

[Justin Karneges]

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

[zeromq-dev] using REQ in a real application

[Justin Karneges]

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

[Justin Karneges]

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

[zeromq-dev] http over zeromq spec

[Justin Karneges]

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

Re: [zeromq-dev] ZMTP 3.0 Status: Sharing Single TCP connection (Example code ?)

[Justin Karneges]

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] pushpin

[Justin Karneges]

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] Why socket.send will block without consumer

[Justin Karneges]

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

Re: [zeromq-dev] do I need to create a context more then once?

[Justin Karneges]

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] Many to many

[Justin Karneges]

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] Greetings questions about inproc PUB/SUB inside Twisted.

[Justin Karneges]

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