Am 06.02.2014 18:50, schrieb Michel Pelletier:
It's true a client can only make ~60K outgoing connections (due to
ephemeral port exhaustion) but a server with bound sockets can have up to
64K connections _per port_. Here's a blog post from urban airship
detailing their experiments with
Le 05/02/2014 13:46, Pieter Hintjens a écrit :
Thanks for the proposals changes,
And thanks for your great help.
To amend my debt, I propose you a patch to suppress duplicated code in
curve_server and curve_client, concerning the encode and decode
functions. I did that some months ago
Hi Devs,
I would like to publish hundreds even thousands events to subscribers as
quick as possible, but there is a condition several subscribers have to
fetch events firstly than others. In other words there exists priority
which set of subscribers will get events first than others set of
Sounds nice. If you make that patch against libcurve, I'll merge it.
On Fri, Feb 7, 2014 at 10:35 AM, Laurent Alebarde l.aleba...@free.fr wrote:
Le 05/02/2014 13:46, Pieter Hintjens a écrit :
Thanks for the proposals changes,
And thanks for your great help.
To amend my debt, I propose you
Maybe a simple publisher on two channels is enough? i.e. in pyzmq the
following you did not provide much information
# simple publisher
import zmq
from random import randrange
import random
import time
import json
context = zmq.Context()
socket = context.socket(zmq.PUB)
No, the patch I wrote was against libzmq.
Le 07/02/2014 15:28, Pieter Hintjens a écrit :
Sounds nice. If you make that patch against libcurve, I'll merge it.
On Fri, Feb 7, 2014 at 10:35 AM, Laurent Alebarde l.aleba...@free.fr wrote:
Le 05/02/2014 13:46, Pieter Hintjens a écrit :
Thanks for
Hi folks,
Currently using 0MQ 3.2.3 on Red Hat Linux 6.4. I have a ZRE application
in which a server is reading from a Router socket and replying to a Dealer
socket, all in non-blocking mode. I have set the RCVHWM and SNDHWM options
to 100 on all sockets.
There is a use case where a client
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,
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,
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
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:
Hi,
1) ROUTER in program A is set to connect to a bind socket in program
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
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
13 matches
Mail list logo
