Hello Cornelius,
Thanks for pointing that out. I Used ProcessDevice and it worked the way i
want, but was not able to understand, some questions:
1) Does ProcessDevice takes care of doing the clean up work ??
2) Is there way i can close the processdevice or i can check if its already
running
From what I understand it may take more time to fix it by closing the
offender's connection and may cause other problems, if this is the case I'd
rather have a working fix right now.
I am working on a project where zeromq (or crosroads btw) would be of great
help but I need to have the server
Hello,
I am working on a requirement whereby a process (say producer) needs to
send out one-way messages to a variable number of processes (say consumers).
The publish-subscribe model seemed good for this because the consumers will
subscribe to messages from the producer. I tried using ZeroMQ to
Hello,
I understand I have to use zmq_poll which is essentially event-driven. So
that solves problem (1) and (3). However, I still need some comments on
point (2) below.
Thanks!
On 26 March 2012 12:52, Rajalakshmi Iyer r...@blismobile.com wrote:
Hello,
I am working on a requirement whereby
On Mar 26, 2012, at 10:24 AM, Rajalakshmi Iyer wrote:
Hello,
I understand I have to use zmq_poll which is essentially event-driven. So
that solves problem (1) and (3). However, I still need some comments on point
(2) below.
Thanks!
On 26 March 2012 12:52, Rajalakshmi Iyer
On Mon, Mar 26, 2012 at 4:42 PM, Chuck Remes li...@chuckremes.com wrote:
That is a far better mechanism than the built-in HWM mechanism. Since it
isn't built in to the library, you would have to add this logic at the
application level. Since it *requires* two-way communication between the
Hello,
I am trying a simple PUBLISH/SUBSCRIBE setup with ZeroMQ 2.1.11.
Here is the server code:
#include zmq.hpp
#include iostream
using namespace std;
int main(void)
{
On Sat, Mar 24, 2012 at 10:59 AM, Chuck Remes li...@chuckremes.com wrote:
FYI, this patch was rejected by crossroads-io. They prefer it be handled by
closing the offending connection rather than silently allowing it to connect
but with an auto identity.
The problem here is that the protocol
Just an update,
I have also tried adding:
subscriber.setsockopt(ZMQ_SUBSCRIBE, , 0);
so the subscriber will subscribe to all messages.
But this did not help either.
Thanks,
Raj
On 26 March 2012 17:14, Rajalakshmi Iyer r...@blismobile.com wrote:
Hello,
I am trying a simple
Hi list,
I'm considering using czmq in my single threaded application.
However, the application is already using an event driven framework in
which a file descriptor has to be registered along with a callback
that is invoked when it becomes readable.
My question is: can I use the file descriptor
On Mar 26, 2012, at 11:08 AM, Ian Barber wrote:
On Mon, Mar 26, 2012 at 4:42 PM, Chuck Remes li...@chuckremes.com wrote:
That is a far better mechanism than the built-in HWM mechanism. Since it
isn't built in to the library, you would have to add this logic at the
application level.
Is it possible to provide both behaviors (reject, autoid) switched
with a socket option?
-Michel
On Mon, Mar 26, 2012 at 9:15 AM, Pieter Hintjens p...@imatix.com wrote:
On Sat, Mar 24, 2012 at 10:59 AM, Chuck Remes li...@chuckremes.com wrote:
FYI, this patch was rejected by crossroads-io.
On Mon, Mar 26, 2012 at 5:53 PM, Chuck Remes li...@chuckremes.com wrote:
Yes, this is true. I answered assuming that the OP wanted to work with
just a single set of sockets rather than having a side channel for
communicating the credit flows. Either way will work, so it's up to the OP
to
On Mar 26, 2012, at 11:58 AM, Ian Barber wrote:
If 3.1 was an option and you wanted a tasty one socket set hack, you can
communicate credit via subscribe messages back up stream :)
Absolutely. I would love to add this kind of back channel communication so
that we could have credit-based flow
On Sunday 25, rektide wrote:
Robert, thanks for the reply. I confess to not understanding the issue
fully. Are there any workarounds or possibilities you'd want to explore, to
test out, as a possible way forwards? I'm just looking to pull whatever
constructive guidanc eI can from you (or any
Yes, it should work fine.
On Mar 26, 2012 11:44 AM, Alex Zeffertt azeffe...@cambridgesys.com
wrote:
Hi list,
I'm considering using czmq in my single threaded application.
However, the application is already using an event driven framework in
which a file descriptor has to be registered along
Sure, but we need a patch for the reject behavior then.
On Mar 26, 2012 11:55 AM, Michel Pelletier pelletier.mic...@gmail.com
wrote:
Is it possible to provide both behaviors (reject, autoid) switched
with a socket option?
-Michel
On Mon, Mar 26, 2012 at 9:15 AM, Pieter Hintjens
Hi Alex,
That'll be fine - the fd events are edge-triggered and would work with any
reactor implementation. Just remember to read until completion as the
notification can be for more than one message (zmq protocol is framed) as
well. Failure to do so will result in further notifications not being
On Sun, Mar 25, 2012 at 23:05, Ronald Swain proj_symb...@live.com wrote:
Hello Cornelius,
Thanks for pointing that out. I Used ProcessDevice and it worked the way i
want, but was not able to understand, some questions:
1) Does ProcessDevice takes care of doing the clean up work ??
2) Is
I have two processes that need to exchange data. Process A has to perform
time-critical work, but also needs to obtain some configuration data from
process B. Initially, I considered using REQ/REP sockets since it's a
roundtrip query, doing something like on A:
initialize work unit
if (previously
I wondered about this as well. I want to make a worker that does remote
method calls, and it would expose a REQ/REP interface that other workers would
use whenever they want to make a remote call.
Since the work bottleneck is time (waiting for remote server responses), I'd
prefer the worker
You can use non-blocking ROUTER on a poll loop and REQ or REP on the
other end, that way you can handle requests and their responses as
they come and as you compute them, respectively. Whether to use REQ
or REP only matters for whichever end starts the conversation.
The LRU pattern documented in
22 matches
Mail list logo
