Re: [zeromq-dev] Erlang implementation of ZMTP 3.1

___ > 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 -- Alex Bligh ___ 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?

ogle Groups and many others): spam resistance. Lists at sourceforge that I'm on have more spam than genuine messages. So don't go there please. -- Alex Bligh ___ 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?

f them seem to reply trimming all context, which makes following conversations hard. -- Alex Bligh ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Packet ordering in RTR->DLR chains

Any ideas on this one? Alex On 14 Mar 2016, at 16:58, Alex Bligh wrote: > If messages are transmitted through chains of RTR->DLR from A to Z, and it is > guaranteed the intervening application code does not reorder the packets, is > it guaranteed that ZeroMQ will also not

[zeromq-dev] Packet ordering in RTR->DLR chains

and Z will continue to be ordered? Obviously this is the case for REQ->...->REP chains, but what about RTR->DLR->RTR->DLR (for example) chains where there may be more than one message in flight at once? -- Alex Bligh ___ zeromq-dev m

Re: [zeromq-dev] Thread safe Pub/Sub and Multicast

sh topic) is string and currently limited to 15 chars > (might be increased in the future) Can I put in a bid for at least 16? 16 is the minimum required for the binary encoding of a UUID (128 bits). What's the reason for a compile time li

[zeromq-dev] [ANN] Providing a golang channel wrapper for pebbe/zmq4 golang zmq binding

://github.com/pebbe/zmq4/pull/81 but the current view of the maintainer is that this is not desirable, (as per that pull request) therefore I am providing it as a separate library. -- Alex Bligh ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http

Re: [zeromq-dev] Loadtag entries on api.zeromq.org

On 24 Feb 2016, at 10:35, Pieter Hintjens wrote: > OK, fixed now. Thanks! Alex > On Wed, Feb 24, 2016 at 9:07 AM, Pieter Hintjens wrote: >> Something went wrong, thanks for reporting this. I'll fix it later today. >> >> On 23 Feb 2016 21:54, "Alex Blig

[zeromq-dev] Loadtag entries on api.zeromq.org

api.zeromq.org appears to have been invaded by "LOAD TAG: entry" and "LOAD TAG: simpara". See e.g.: http://api.zeromq.org/4-0:zmq-socket It would be more readable without these. -- Alex Bligh ___ zeromq-dev mai

[zeromq-dev] ZeroMQ thread safety (or not)

hich is going to be problematic in go as the same goroutine can be scheduled between different OS threads) I can't immediately see why the above would not work. -- Alex Bligh ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Multiplexing a TCP endpoint

uded save for the fact that I had thought the service ID should probably be the innermost frame (possibly after the empty frame delimiter and with it's own zero frame delimiter) so the transport over TCP could (if necessary) be routed transparently through RTR sockets. -- Alex Bligh

[zeromq-dev] Multiplexing a TCP endpoint

missing something. In many ways it would seem to be easier to modify the endpoint protocol. Am I missing something? Am I approaching this the right way? -- Alex Bligh ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev