Yes, but I'm working on it in C nor Android(currently):
https://github.com/zeromq/pyre/blob/master/pyre/zbeacon.py#L208
On 2015-03-23 15:23, Kenneth Adam Miller wrote:
Since you have acknowledged that a UDP stack is needed on android in
C, do you have a public repository where youre testing
I'm doing this using JeroMq (may use jzmq at some point) so I'm at the mercy of
the JVM.
I have a wrapper around the JVM that heartbeats also, it and will kill the JVM
if it doesn't reply with a pong. After the wrapper kills the JVM, it will
quickly restart the JVM so I'm not sure there is a
On 2015-03-20 14:41, Pieter Hintjens wrote:
Could you provide me a spec for the multicast? Then I'll add it to
the RFC.
The other discovery methods I'd like to eventually make are bluetooth
and manual (i.e. provide the Zyre API with node endpoints taken from
arbitrary mechanisms).
It's not
Since you have acknowledged that a UDP stack is needed on android in C, do
you have a public repository where you're testing and working on it?
On Mon, Mar 23, 2015 at 9:42 AM, Arnaud Loonstra arn...@sphaero.org wrote:
On 2015-03-20 14:41, Pieter Hintjens wrote:
Could you provide me a spec
Thanks, I really like this idea.
I was trying to keep my server stateless, but so far haven't come up with a way
to do that.
Maybe there isn't a stateless way or socket pattern that will handle this case.
From: Doron Somech somdo...@gmail.com
To: Russell
Have the heartbeat reply include a guid which represents the instance of the
server, the server picks a guid at startup and always uses it. If the client
sees two different guids then it knows the server restarted and can take
action. The server side state is minimal, the client needs to track
We used multicast first, and then switched to broadcast UDP because
the Android stack filters (or used to) incoming multicast when it is
running as an access point.
On Mon, Mar 23, 2015 at 5:58 PM, Arnaud Loonstra arn...@sphaero.org wrote:
but I'm working on it in C nor Android
Add 'not' to
It is a bug. Anyway you can work around it by calling server.Monitor with
null as the endpoint before closing the server.
On Mon, Mar 23, 2015 at 6:48 PM, Leonard Michelet
leonard.miche...@openwide.fr wrote:
Hello everyone, I'm having problem using Monitor with NetMQ. Please tell
me if there
Hello everyone, I'm having problem using Monitor with NetMQ. Please tell me if
there is a dedicated place to ask about NetMQ, or possibly report bug.
Here's what I do :
1) I create and bind a DEALER socket, associate a monitor to it and start
monitoring it.
2) Then I Unbind the socket, stop
but I'm working on it in C nor Android
Add 'not' to that... I'm working on it in Python
On 03/23/2015 04:05 PM, Arnaud Loonstra wrote:
Yes, but I'm working on it in C nor Android(currently):
https://github.com/zeromq/pyre/blob/master/pyre/zbeacon.py#L208
Hrmm... Thinking through this.
I originally didn't think the UUID method would work because I was considering
what would happen if I ever supported load balancing (i.e. Multiple primaries
/ multiple secondaries.)
But I'm not doing that currently, so there should only be a primary and
11 matches
Mail list logo