[zeromq-dev] zeromq-dev Digest, Vol 66, Issue 5
Andrew Davey
as.davey at gmail.com
Wed Jun 5 13:15:39 CEST 2013
unsubscribe
end
On 5 Jun 2013 20:00, <zeromq-dev-request at lists.zeromq.org> wrote:
> Send zeromq-dev mailing list submissions to
> zeromq-dev at lists.zeromq.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> or, via email, send a message with subject or body 'help' to
> zeromq-dev-request at lists.zeromq.org
>
> You can reach the person managing the list at
> zeromq-dev-owner at lists.zeromq.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of zeromq-dev digest..."
>
>
> Today's Topics:
>
> 1. How to open a socket on a real file ? (Laurent Alebarde)
> 2. Zeromq - epgm transport on Red Hat 4 (Emmanuel TAUREL)
> 3. Re: Dealer send succeeded/failed (Erwin)
> 4. Re: Dealer send succeeded/failed (Martin Sustrik)
> 5. Re: Dealer send succeeded/failed (Erwin Karbasi)
> 6. Re: How to open a socket on a real file ? (Pieter Hintjens)
> 7. Re: Dealer send succeeded/failed (Pieter Hintjens)
> 8. Re: Zeromq - epgm transport on Red Hat 4 (Steven McCoy)
> 9. why the REQUEST_TIMEOUT is so long in the Lazy Pirate client
> ? (Laurent Alebarde)
> 10. clonecli6 example: clone_get return value (Kent Headley)
> 11. Re: why the REQUEST_TIMEOUT is so long in the Lazy Pirate
> client ? (Pieter Hintjens)
> 12. Re: clonecli6 example: clone_get return value (Pieter Hintjens)
> 13. Re: Zeromq - epgm transport on Red Hat 4 (Emmanuel TAUREL)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 04 Jun 2013 12:18:41 +0200
> From: Laurent Alebarde <l.alebarde at free.fr>
> Subject: [zeromq-dev] How to open a socket on a real file ?
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Message-ID: <51ADBF01.9000709 at free.fr>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi list,
>
> In the presentation of Ian Barber, there is a PHP example where the
> socket is a file descriptor on the standard input.
>
> $ctx = new ZMQContext();
> $sock = $ctx->getSocket(ZMQ::SOCKET_PULL);
> $sock->bind("tcp://*:5555");
> $fh = fopen("php://stdin", 'r');
> $poll = new ZMQPoll();
> $poll->add($sock, ZMQ::POLL_IN);
> $poll->add($fh, ZMQ::POLL_IN);
> while(true) {
> $events = $poll->poll($read, $write);
> if($read[0] === $sock) {
> echo "ZMQ: ", $read[0]->recv();
> } else {
> echo "STDIN: ", fgets($read[0]);
> }}
>
> I have not find anything on that in the documentation. I would need more
> information please, especially to transfer a file from one process to an
> other, possibly with streaming, in C.
>
> Cheers,
>
> Laurent.
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130604/289f089f/attachment.html
>
> ------------------------------
>
> Message: 2
> Date: Tue, 04 Jun 2013 13:17:54 +0200
> From: Emmanuel TAUREL <taurel at esrf.fr>
> Subject: [zeromq-dev] Zeromq - epgm transport on Red Hat 4
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Message-ID: <51ADCCE2.7000202 at esrf.fr>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello all,
>
> I am trying to use ZMQ PUB/SUB with epgm transport on a Red Hate 4
> Linux host - 32 bits.
>
> - 1 - First, some issues related to compilation:
> Due to ZMQ bug XXX, I have to use ZMQ 3.2.3. It comes with libpgm
> 5.1.118. When you compiled this OpenPGM release on Red Hat 4 host, it
> fails with
> error
>
> time.c:451:4: #error "gettimeofday() or ftime() required to calculate
> counter offset"
> time.c: In function `pgm_tsc_init':
> time.c:715: error: `pgm_gettimeofday_update' undeclared (first use in
> this function)
>
> I already discuss this point on this mailing list and Steve advice me to
> use OpenPGM 5.2.122. See mail thread
> http://lists.zeromq.org/pipermail/zeromq-dev/2013-March/020775.html
> Nevertheless, to avoid warnings due to Red Hat 4 gcc release (< 4)
> during ZMQ/OpenPGM compilation, and according to Steve advice, you have
> to replace all instances of:
>
>
> #if defined( __GNUC__ ) && !defined( __sun ) && !defined( __CYGWIN__ )
>
>
> with:
>
> #if (defined( __GNUC__ ) && ( __GNUC__ >= 4 )) && !defined( __sun )
> && !defined( __CYGWIN__ )
>
> 1. include/pgm/packet.h
> 2. include/impl/ip.h
> 3. include/impl/ticket.h
>
> After applying this recipe, I finally have a zeromq 3.2.3 library
> including OpenPGM 5.2.122 compiled for Red Hat 4
>
> - 2 - I am not able to send/receive messages using this library
> The publisher is running on the Red Hat 4 box using the library compiled
> as previously described.
> The subscriber is running on a Debian6 box using ZeroMQ 3.2.2 and
> OpenPGM 5.1.118
> Everything seems to work fine because I do not have any reported error
> on both side but I do not receive messages on the subscriber side. The
> same code works without problem between a ubuntu 10.04 host (or 12.04)
> and a Centos 5 host. If I run tcpdump on the publisher host, on the IP
> address selected for multicast transfer, I see only IGMP "Join group"
> packets. Nothing more.
>
> I have set on both side the following env. variables:
> PGM_MIN_LOG_LEVEL=TRACE and PGM_LOG_MASK=0xffff
> The publisher outputs are:
>
> Minor: OpenPGM 5.2.122 (1487) 2013-05-31 09:42:52 Linux i686
> Minor: Detected 2 available 2 online 2 configured CPUs.
> Minor: Using gettimeofday() timer.
>
> at process startup
>
> Trace: Opening UDP encapsulated sockets.
> Trace: Set socket sharing.
> Trace: Request socket packet-info.
> Trace: Assuming IP header size of 20 bytes
> Trace: Assuming UDP header size of 8 bytes
> Trace: Create transmit window.
> Trace: Binding receive socket to INADDR_ANY
> Trace: Binding send socket to interface index 2
> Trace: Setting ODATA rate regulation to 7680000 bytes per second.
> Trace: Join multicast group 226.30.31.32 on interface index 2
> Trace: Multicast send interface set to 160.103.236.92 index 2
> Warn: ToS/DSCP setting requires CAP_NET_ADMIN or ADMIN capability.
>
> When the subscriber connects. Nothing more printed (even when the
> messages should be sent).
>
> The subscriber outputs are:
> Minor: OpenPGM 5.1.118 (1369) 2012-12-14 08:09:37 Linux x86_64
> Minor: Detected 6 available 6 online 6 configured CPUs.
> Minor: Using TSC timer.
> Minor: TSC frequency set to 2825 MHz
> Trace: Opening UDP encapsulated sockets.
> Trace: Set socket sharing.
> Trace: Request socket packet-info.
> Trace: Assuming IP header size of 20 bytes
> Trace: Assuming UDP header size of 8 bytes
> Trace: Binding receive socket to INADDR_ANY
> Trace: Binding send socket to interface index 2
> Trace: Join multicast group 226.30.31.32 on interface index 2
> Trace: Multicast send interface set to 160.103.236.228 index 2
>
> Any help appreciated. Thank's in advance
>
> Emmanuel
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130604/fd31ab8a/attachment-0001.htm
>
> ------------------------------
>
> Message: 3
> Date: Tue, 4 Jun 2013 11:54:24 +0000 (UTC)
> From: Erwin <erwin at optinity.com>
> Subject: Re: [zeromq-dev] Dealer send succeeded/failed
> To: zeromq-dev at lists.zeromq.org
> Message-ID: <loom.20130604T135346-417 at post.gmane.org>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Guys,
>
> Any help please.
>
> Thanks,
> Erwin
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 04 Jun 2013 14:33:01 +0200
> From: Martin Sustrik <sustrik at 250bpm.com>
> Subject: Re: [zeromq-dev] Dealer send succeeded/failed
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Cc: Erwin <erwin at optinity.com>
> Message-ID: <51ADDE7D.8060204 at 250bpm.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Erwin,
>
> No it is not possible to detect the failure of the peer. The problem is
> inherently semi-decidable, i.e. you can make sure that peer is alive (if
> it responds), but there's no way to distinguish a peer failure from a
> slow/dead network.
>
> Thus the only thing you can do is a handshake with the peer and if
> response isn't received in, say, 1 minute, consider the peer dead. Of
> course, you won't be 100% sure -- it can still be caused by network
> failure, congestion or somesuch.
>
> Martin
>
> On 04/06/13 13:54, Erwin wrote:
> > Hi Guys,
> >
> > Any help please.
> >
> > Thanks,
> > Erwin
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 4 Jun 2013 17:21:03 +0300
> From: Erwin Karbasi <erwin at optinity.com>
> Subject: Re: [zeromq-dev] Dealer send succeeded/failed
> To: Martin Sustrik <sustrik at 250bpm.com>
> Cc: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Message-ID:
> <CAG7=
> OFAgxhXKnYkKXaRRxxP+N7oS-dnGQLF7WfQ8JgATkGSKgg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Martin,
>
> Thank you a lot for clear explanation.
> We need to implement heartbeating feature.
>
> Cheers,
> Erwin
> On Jun 4, 2013 3:33 PM, "Martin Sustrik" <sustrik at 250bpm.com> wrote:
>
> > Hi Erwin,
> >
> > No it is not possible to detect the failure of the peer. The problem is
> > inherently semi-decidable, i.e. you can make sure that peer is alive (if
> it
> > responds), but there's no way to distinguish a peer failure from a
> > slow/dead network.
> >
> > Thus the only thing you can do is a handshake with the peer and if
> > response isn't received in, say, 1 minute, consider the peer dead. Of
> > course, you won't be 100% sure -- it can still be caused by network
> > failure, congestion or somesuch.
> >
> > Martin
> >
> > On 04/06/13 13:54, Erwin wrote:
> >
> >> Hi Guys,
> >>
> >> Any help please.
> >>
> >> Thanks,
> >> Erwin
> >>
> >> ______________________________**_________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/**mailman/listinfo/zeromq-dev<
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev>
> >>
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130604/104e29ff/attachment-0001.htm
>
> ------------------------------
>
> Message: 6
> Date: Tue, 4 Jun 2013 17:08:54 +0200
> From: Pieter Hintjens <ph at imatix.com>
> Subject: Re: [zeromq-dev] How to open a socket on a real file ?
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Message-ID:
> <CADL5_sjWadZOyXGKhbsNAujjvXX8xBdkQqiSj0L32HuDh=
> YC9g at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Laurent,
>
> What Ian is showing is the ability of zmq_poll to work with native
> file handles as well as ZeroMQ sockets. There's an explanation in the
> zmq_poll man page. http://api.zeromq.org/3-2:zmq-poll
>
> However what you're asking for is somewhat different and I'd suggest
> reading Chapter 7 of the Guide (or buy the O'Reilly book!) which
> develops a file transfer protocol and application (FileMQ).
>
> Finally, you may simply use FileMQ in your application, it is a C API
> that is very easy to call. https://github.com/zeromq/filemq
>
> -Pieter
>
> On Tue, Jun 4, 2013 at 12:18 PM, Laurent Alebarde <l.alebarde at free.fr>
> wrote:
> > Hi list,
> >
> > In the presentation of Ian Barber, there is a PHP example where the
> socket
> > is a file descriptor on the standard input.
> >
> > $ctx = new ZMQContext();
> > $sock = $ctx->getSocket(ZMQ::SOCKET_PULL);
> > $sock->bind("tcp://*:5555");
> > $fh = fopen("php://stdin", 'r');
> > $poll = new ZMQPoll();
> > $poll->add($sock, ZMQ::POLL_IN);
> > $poll->add($fh, ZMQ::POLL_IN);
> > while(true) {
> > $events = $poll->poll($read, $write);
> > if($read[0] === $sock) {
> > echo "ZMQ: ", $read[0]->recv();
> > } else {
> > echo "STDIN: ", fgets($read[0]);
> > }}
> >
> > I have not find anything on that in the documentation. I would need more
> > information please, especially to transfer a file from one process to an
> > other, possibly with streaming, in C.
> >
> > Cheers,
> >
> > Laurent.
> >
> >
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 4 Jun 2013 17:11:16 +0200
> From: Pieter Hintjens <ph at imatix.com>
> Subject: Re: [zeromq-dev] Dealer send succeeded/failed
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Message-ID:
> <
> CADL5_sjdVRcVbppUTFPS9yBKnz1mYq4+kNrp+ZkFCoZpv41pJQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Erwin,
>
> Sorry for the late reply, I'm at a conference. You will find numerous
> examples that do what you need in Chapter 4 of the Guide. Heartbeating
> is part of it, but there are other aspects too, such as failover and
> retries. To properly build this you should work through the examples
> until you understand each type of failure that can affect your
> use-case, and how to detect it and deal with it.
>
> -Pieter
>
> On Tue, Jun 4, 2013 at 4:21 PM, Erwin Karbasi <erwin at optinity.com> wrote:
> > Hi Martin,
> >
> > Thank you a lot for clear explanation.
> > We need to implement heartbeating feature.
> >
> > Cheers,
> > Erwin
> >
> > On Jun 4, 2013 3:33 PM, "Martin Sustrik" <sustrik at 250bpm.com> wrote:
> >>
> >> Hi Erwin,
> >>
> >> No it is not possible to detect the failure of the peer. The problem is
> >> inherently semi-decidable, i.e. you can make sure that peer is alive
> (if it
> >> responds), but there's no way to distinguish a peer failure from a
> slow/dead
> >> network.
> >>
> >> Thus the only thing you can do is a handshake with the peer and if
> >> response isn't received in, say, 1 minute, consider the peer dead. Of
> >> course, you won't be 100% sure -- it can still be caused by network
> failure,
> >> congestion or somesuch.
> >>
> >> Martin
> >>
> >> On 04/06/13 13:54, Erwin wrote:
> >>>
> >>> Hi Guys,
> >>>
> >>> Any help please.
> >>>
> >>> Thanks,
> >>> Erwin
> >>>
> >>> _______________________________________________
> >>> zeromq-dev mailing list
> >>> zeromq-dev at lists.zeromq.org
> >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >>
> >>
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 4 Jun 2013 11:56:32 -0400
> From: Steven McCoy <steven.mccoy at miru.hk>
> Subject: Re: [zeromq-dev] Zeromq - epgm transport on Red Hat 4
> To: taurel at esrf.fr, ZeroMQ development list
> <zeromq-dev at lists.zeromq.org>
> Message-ID:
> <CAGFWLihsLr+U7QiXdMDyks9XN=
> waLANc7C-3traEDeKT8KHOFg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On 4 June 2013 07:17, Emmanuel TAUREL <taurel at esrf.fr> wrote:
>
> > Any help appreciated. Thank's in advance
> >
> >
> Modify the stock remote_thr.cpp to use a ZMQ_PUB socket then define a rate
> limit slightly higher than the default,
>
> s = zmq_socket (ctx, ZMQ_PUB);
> if (!s) {
> printf ("error in zmq_socket: %s\n", zmq_strerror (errno));
> return -1;
> }
>
> // Add your socket options here.
> // For example ZMQ_RATE, ZMQ_RECOVERY_IVL and ZMQ_MCAST_LOOP for PGM.
>
> int rate = 10 * 1000;
> rc = zmq_setsockopt (s, ZMQ_RATE, (void*)&rate, sizeof (rate));
> if (rc != 0) {
> printf ("error in zmq_setsockopt: %s\n", zmq_strerror (errno));
> return -1;
> }
>
> Running the following,
>
> [steve-o at nylabdev4 perf]$ *./remote_thr "epgm://eth0;239.192.0.30:6030"
> 100 10*
> Warn: ToS/DSCP setting requires CAP_NET_ADMIN or ADMIN capability.
>
> [steve-o at nylabdev4 perf]$ lsb_release -a
> LSB Version:
> :core-3.0-amd64:core-3.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch
> Distributor ID: RedHatEnterpriseAS
> Description: Red Hat Enterprise Linux AS release 4 (Nahant Update 8)
> Release: 4
> Codename: NahantUpdate8
>
> Whilst,
>
> [steve-o at nylabdev4 ~]$ *sudo /usr/sbin/tcpdump port 6030*
> Password:
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> 11:55:26.013107 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> 11:55:26.013439 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> 11:55:26.013444 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> 11:55:26.013498 IP nylabdev4.38468 > 239.192.0.30.6030: UDP, length 1048
> 11:55:26.113495 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> 11:55:26.213494 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> 11:55:26.313494 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> 11:55:26.413493 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> 11:55:26.513495 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> 11:55:27.813499 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
>
> 10 packets captured
> 10 packets received by filter
> 0 packets dropped by kernel
>
> --
> Steve-o
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130604/05d75963/attachment-0001.htm
>
> ------------------------------
>
> Message: 9
> Date: Tue, 04 Jun 2013 18:09:51 +0200
> From: Laurent Alebarde <l.alebarde at free.fr>
> Subject: [zeromq-dev] why the REQUEST_TIMEOUT is so long in the Lazy
> Pirate client ?
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Message-ID: <51AE114F.60602 at free.fr>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi list,
>
> I wonder why in the "Lazy Pirate client", the REQUEST_TIMEOUT parameter
> is requested to be at least 1,000 ms ? I understand a reasonable minimum
> time is required to avoid false positives, but it seems hugely long, no
> ? It depends also on the transport.
>
> Cheers,
>
>
> Laurent.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130604/4be6165a/attachment-0001.htm
>
> ------------------------------
>
> Message: 10
> Date: Mon, 3 Jun 2013 23:04:22 -0700
> From: Kent Headley <headley at mbari.org>
> Subject: [zeromq-dev] clonecli6 example: clone_get return value
> To: zeromq-dev at lists.zeromq.org
> Message-ID: <0EA84F3A-82D9-4B89-A127-3B1F5C1F9541 at mbari.org>
> Content-Type: text/plain; charset="us-ascii"
>
> An HTML attachment was scrubbed...
> URL:
> http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130603/ca00e3ef/attachment-0001.htm
>
> ------------------------------
>
> Message: 11
> Date: Tue, 4 Jun 2013 21:09:37 +0200
> From: Pieter Hintjens <ph at imatix.com>
> Subject: Re: [zeromq-dev] why the REQUEST_TIMEOUT is so long in the
> Lazy Pirate client ?
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Message-ID:
> <CADL5_sgYJDNP3yHQ7TPmmzgZp6SzRuMtn1=
> VJc5UNKjSQs1k+Q at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> The timeout depends on heartbeating, and decreasing the timeout
> requires faster heartbeating. You can certainly do that and get
> slightly faster response in case of failure, at the cost of extra
> traffic. It'd be a good trade-off for clustering, but maybe less
> important for clients.
>
> -Pieter
>
>
> On Tue, Jun 4, 2013 at 6:09 PM, Laurent Alebarde <l.alebarde at free.fr>
> wrote:
> > Hi list,
> >
> > I wonder why in the "Lazy Pirate client", the REQUEST_TIMEOUT parameter
> is
> > requested to be at least 1,000 ms ? I understand a reasonable minimum
> time
> > is required to avoid false positives, but it seems hugely long, no ? It
> > depends also on the transport.
> >
> > Cheers,
> >
> >
> > Laurent.
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
>
>
> ------------------------------
>
> Message: 12
> Date: Tue, 4 Jun 2013 21:14:33 +0200
> From: Pieter Hintjens <ph at imatix.com>
> Subject: Re: [zeromq-dev] clonecli6 example: clone_get return value
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Message-ID:
> <
> CADL5_sifzaBAXGEYNjbijTrJ01kpsYRwppcUQd_ENH039B13NA at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Kent,
>
> Nice catch. The API should get a string, for a few reasons. First,
> symmetry with clone_set. Second, kvmsg is an internal detail, it
> should not be visible to calling applications.
>
> The code is therefore buggy... do you want to try to fix it and send a
> pull request, or shall I do that?
>
> -Pieter
>
> On Tue, Jun 4, 2013 at 8:04 AM, Kent Headley <headley at mbari.org> wrote:
> > Hello,
> >
> > I've been trying out some code based on the clone client/server example
> code
> > in the 0MQ Guide (clone.c, clonecli6.c and clonesrv6.c, zmq v 3.2.2).
> > As with other ZMQ code I've tried so far, the example code builds and
> runs
> > cleanly - ZMQ is very nice that way.
> >
> > The clone client/server appear to do essentially what I need in an
> > application.
> > As a starting point, I'm using clonecli6 as-is, and wrote a clone client
> in
> > C using the clone class; it is very similar to clonecli6.c, but another
> > thread catches and handles signals.
> >
> > There is one thing I am confused about, that I haven't seen posted on the
> > archives:
> > When clone_get() is invoked, should the return value be treated as a
> kvmsg
> > or as a string?
> >
> > I ask because it looks like the clonesvr6/clonecli6 example works as
> > follows:
> >
> > The clonesvr6 stores a key:kvmsg pair in its hash map (stores entire
> kvmsg
> > received from clone agent).
> > The clonecli6 agent stores a key:string pair in its hash map when it
> > receives a SET message from clone_set().
> > The clonecli6 agent stores a key:kvmsg pair in its hash map when it
> receives
> > a a (kvmsg) update from clonesvr.
> >
> > Does that mean that a client's zhash_lookup ( in clone_get() ) may return
> > either a string or kvmsg, depending on whether the server is running and
> the
> > state of the transaction between the clone agent and clonesvr?
> > So, I'm unclear about whether clone_get is intended to return a string
> > value, or a kvmsg.
> >
> > The clonecli6.c example only posts updates and never calls clone_get(),
> so
> > the ambiguity isn't apparent until I try to write a client that
> subscribes
> > to the (clonecli6) updates.
> >
> > To illustrate, if I modify the clonecli6.c to update a single subtree
> > ("/client/" instead of "/client/randof(10000)"),
> > I expect the following client to consume updates produced by clonecli6:
> >
> > #include "clone.c"
> > #define SUBTREE "/client/"
> >
> > int main (void)
> > {
> > // Create distributed hash instance
> > clone_t *clone = clone_new ();
> >
> > // Specify configuration
> > clone_subtree (clone, SUBTREE);
> > clone_connect (clone, "tcp://localhost", "5556");
> > clone_connect (clone, "tcp://localhost", "5566");
> >
> > // Set random tuples into the distributed hash
> > while (!zctx_interrupted) {
> >
> > // Set random value, check it was stored
> > char key [255];
> > sprintf (key, "%s", SUBTREE);
> > printf("clone requesting key %s\n",key);
> >
> > // What does clone_get really return?
> > char *sval=clone_get (clone, key);
> >
> > if(sval!=NULL){
> > int len=strlen(sval);
> > printf("message value len %d:\n",len);
> > printf("[%s]\n",sval);
> > if(len>1){
> > kvmsg_t *kval=(kvmsg_t *)sval;
> > byte *mbody=kvmsg_body(kval);
> > printf("kval: [%s]\n",(char *)mbody);
> > }else
> > printf("message len <= 1\n");
> >
> > }else{
> > printf("NULL message \n");
> > }
> > sleep (1);
> > }
> > clone_destroy (&clone);
> > return 0;
> > }
> >
> > Maybe I'm doing something wrong, but in addition to my uncertainty about
> the
> > return value of clone_get(), this client crashes:
> >
> > *** glibc detected *** ../../git/zguide/examples/C/evilclone: double
> free or
> > corruption (out): 0xb5a1ceb0 ***
> > ======= Backtrace: =========
> > /lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0xb75c1ee2]
> > ../../git/zguide/examples/C/evilclone[0x804964a]
> > /usr/local/lib/libczmq.so.1(zhash_update+0x5b)[0xb76fe36b]
> > ../../git/zguide/examples/C/evilclone[0x804a6e1]
> > ../../git/zguide/examples/C/evilclone[0x804b9ab]
> > /usr/local/lib/libczmq.so.1(s_thread_shim+0x3a)[0xb770701a]
> > /lib/i386-linux-gnu/libpthread.so.0(+0x6d4c)[0xb752ed4c]
> > /lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb763ad3e]
> >
> >
> > I believe this is caused by the clone agent_control_message GET handler
> > (clone.c:284) calling free(value), which releases the memory reference
> > returned by clone_get.
> > Even if I change comment out that free(value) the example still does not
> > return valid strings (or a kvmsg).
> >
> > In my own application, I modified the clone agent update handler so that
> it
> > only ever stores string values (never kvmsg) in its hash map.
> > So, only string values are returned by clone_get().
> > I also eliminated the aforementioned free(value) in clone.c.
> > Doing so seems to work, and valgrind indicates no memory leaks.
> >
> > Have I stumbled upon an issue with this example, or do I misunderstand
> how
> > the clone example should work?
> >
> > Kent Headley
> > headley at mbari.org
> >
> > ==================================
> > Monterey Bay Aquarium Research Institute
> > 7700 Sandholdt Road
> > Moss Landing, CA 95039
> >
> >
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
>
>
> ------------------------------
>
> Message: 13
> Date: Wed, 05 Jun 2013 09:02:34 +0200
> From: Emmanuel TAUREL <taurel at esrf.fr>
> Subject: Re: [zeromq-dev] Zeromq - epgm transport on Red Hat 4
> To: Steven McCoy <steven.mccoy at miru.hk>
> Cc: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Message-ID: <51AEE28A.5020908 at esrf.fr>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Steve,
>
> Thank's for your answer. I have done exactly the same test than you:
> - Small changes in perf/remote_thr.cpp file
> - Compile it and run it
> - Look at tcpdump output
>
> but on my Red Hat4 host, tcpdump is desperately silent.
>
> I have tried on my Ubuntu 12.04 with zeromq 3.2.3 using OpenPGM 5.1.118
> and 5.2.122 and obviously both cases run fine.
>
> From what I understand from the result of your lsb_release command,
> your RHE4 host is 64 bits. Mine is 32. Could it be the reason
> of the problem?
> Is it the way I have compiled zeromq for RHE4 (previously reported)
> which results in this issue?
>
> Here is the result of lsb_release -a on my host
> LSB Version:
> :core-3.0-ia32:core-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch
> Distributor ID: RedHatEnterpriseWS
> Description: Red Hat Enterprise Linux WS release 4 (Nahant Update 6)
> Release: 4
> Codename: NahantUpdate6
>
> Thank's for your help
>
> Emmanuel
>
>
> On 04/06/2013 17:56, Steven McCoy wrote:
> > On 4 June 2013 07:17, Emmanuel TAUREL <taurel at esrf.fr
> > <mailto:taurel at esrf.fr>> wrote:
> >
> > Any help appreciated. Thank's in advance
> >
> >
> > Modify the stock remote_thr.cpp to use a ZMQ_PUB socket then define a
> > rate limit slightly higher than the default,
> >
> > s = zmq_socket (ctx, ZMQ_PUB);
> > if (!s) {
> > printf ("error in zmq_socket: %s\n", zmq_strerror (errno));
> > return -1;
> > }
> >
> > // Add your socket options here.
> > // For example ZMQ_RATE, ZMQ_RECOVERY_IVL and ZMQ_MCAST_LOOP for
> PGM.
> >
> > int rate = 10 * 1000;
> > rc = zmq_setsockopt (s, ZMQ_RATE, (void*)&rate, sizeof (rate));
> > if (rc != 0) {
> > printf ("error in zmq_setsockopt: %s\n", zmq_strerror (errno));
> > return -1;
> > }
> >
> > Running the following,
> >
> > [steve-o at nylabdev4 perf]$ *./remote_thr
> > "epgm://eth0;239.192.0.30:6030 <http://239.192.0.30:6030>" 100 10*
> > Warn: ToS/DSCP setting requires CAP_NET_ADMIN or ADMIN capability.
> >
> > [steve-o at nylabdev4 perf]$ lsb_release -a
> > LSB Version:
> > :core-3.0-amd64:core-3.0-noarch:graphics-3.0-amd64:graphics-3.0-noarch
> > Distributor ID: RedHatEnterpriseAS
> > Description: Red Hat Enterprise Linux AS release 4 (Nahant Update 8)
> > Release: 4
> > Codename: NahantUpdate8
> >
> > Whilst,
> >
> > [steve-o at nylabdev4 ~]$ *sudo /usr/sbin/tcpdump port 6030*
> > Password:
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> > listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> > 11:55:26.013107 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> > 11:55:26.013439 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> > 11:55:26.013444 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> > 11:55:26.013498 IP nylabdev4.38468 > 239.192.0.30.6030: UDP, length 1048
> > 11:55:26.113495 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> > 11:55:26.213494 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> > 11:55:26.313494 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> > 11:55:26.413493 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> > 11:55:26.513495 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> > 11:55:27.813499 IP nylabdev4.36877 > 239.192.0.30.6030: UDP, length 36
> >
> > 10 packets captured
> > 10 packets received by filter
> > 0 packets dropped by kernel
> >
> > --
> > Steve-o
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130605/cfdc993e/attachment-0001.htm
>
> ------------------------------
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
> End of zeromq-dev Digest, Vol 66, Issue 5
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130605/3ff86d4c/attachment.htm>
More information about the zeromq-dev
mailing list