[zeromq-dev] Connect to UDP Multicast CoT Server
Doron Somech
somdoron at gmail.com
Sat Oct 1 16:35:44 CEST 2016
Udp only work with radio-dish. You can use pgm for pubsub.
On Fri, Sep 30, 2016, 16:53 Craig Stutts ARA/SED <cstutts at ara.com> wrote:
> Hey guys,
>
> I'm new to network programming and I am having trouble connecting to a
> Cursor on Target multicast UDP server using ZMQ 4.2.0 (master). I'm getting
> a "The protocol is not compatible with the socket type" error in
> zmq_connect. The manual page for zmq_connect doesn't mention UDP, but the
> below link suggests that it should be possible using the ZMQ_RADIO socket
> type. This type appears to no longer exist in this version, so I'm using
> ZMQ_SUB. Below is my code.
>
> UDP Link
> https://github.com/zeromq/libzmq/blob/master/doc/zmq_udp.txt
>
> void *ctx = zmq_ctx_new();
> void *sub = zmq_socket(ctx, ZMQ_SUB);
> int rc = zmq_connect(sub, "udp://239.2.3.1:6968");
> cout << zmq_strerror(errno) << endl;
>
> char buf[256];
> rc = zmq_recv(sub, buf, 256, 0);
> cout << "Return Message: " << buf << endl;
> zmq_close(sub);
> zmq_ctx_destroy(ctx);
>
> I have also tried int rc = zmq_connect(sub, "epgm://192.168.3.150;
> 239.2.3.1:6968"); which includes the Wireless IPv4 network that the CoT
> device is on. This command returns a "Protocol not supported" error.
>
> Thanks,
>
> Craig
>
> -----Original Message-----
> From: zeromq-dev [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf
> Of zeromq-dev-request at lists.zeromq.org
> Sent: Friday, September 30, 2016 6:00 AM
> To: zeromq-dev at lists.zeromq.org
> Subject: zeromq-dev Digest, Vol 6, Issue 16
>
> 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. Re: ZeroMQ 4.2 release, planning (Pieter Hintjens)
> 2. Re: ZeroMQ 4.2 release, planning (Benjamin Henrion)
> 3. czmq + draft mode (Wes Young)
> 4. Re: czmq + draft mode (Wes Young)
> 5. Re: czmq + draft mode (Kevin Sapper)
> 6. Re: czmq + draft mode (Wes Young)
> 7. Question about context and/or socket creation (James Chapman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 29 Sep 2016 12:13:28 +0200
> From: Pieter Hintjens <ph at imatix.com>
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Cc: Luca Boccassi <luca.boccassi at gmail.com>
> Subject: Re: [zeromq-dev] ZeroMQ 4.2 release, planning
> Message-ID:
> <CADL5_sgzND_NbiSJ8qiJ4Ph22pNOkdNHZ_85=
> tuieqz_+1P1iA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hopefully you're back! :-)
>
> I see a lot of good stiff since May. Especially getting properly signed
> downloads via HTTPS from github, rather than HTTP from zeromq.org.
>
> Let's try to get a 4.2 release out :-)
>
> -Pieter
>
> On Tue, Sep 27, 2016 at 8:41 AM, Doron Somech <somdoron at gmail.com> wrote:
> > Sorry for the late response, increasing the msg_t structure will be
> > great, however this will require changing a lot of binding.
> >
> > Sorry for disappearing, baby and full time job is a lot :-), hopefully
> > I'm back...
> >
> >
> >
> >
> > On Mon, Aug 29, 2016 at 6:46 PM, Luca Boccassi <luca.boccassi at gmail.com>
> wrote:
> >> Sorry, I meant if we go with (1), not (2), we might bump the size as
> >> well, since we are already doing another ABI-breaking change.
> >>
> >> I agree on the solution as well.
> >>
> >> On Mon, 2016-08-29 at 17:12 +0200, Pieter Hintjens wrote:
> >>> I'm confused between the (1) and (2) choices, and can't see where
> >>> bumping the message size fits.
> >>>
> >>> Nonetheless, I think bumping the size, fixing the alignment issues,
> >>> and bumping the ABI version is the best solution here.
> >>>
> >>> On Fri, Aug 26, 2016 at 12:33 PM, Luca Boccassi <
> luca.boccassi at gmail.com> wrote:
> >>> > I've given some more thoughts and testing to the alignment issue.
> >>> > I can reproduce the problem by enabling alignment checks on x86 too.
> >>> >
> >>> > But most importantly, I think we cannot get away from bumping the
> >>> > ABI with this fix, however we rearrange it, simply because
> >>> > applications need to be rebuilt against the new header to be
> >>> > fixed. A simple rebuild of the libzmq.so is not enough. And the
> >>> > way to do this is to bump the ABI so that distros can schedule
> transitions and rebuilds and so on.
> >>> >
> >>> > So the choice list is now restricted to:
> >>> >
> >>> > 1) Bump ABI
> >>> > 2) Revert the fix and leave everything broken on sparc64 and some
> >>> > aarch64 (rpi3 seems not to be affected, must depend on the SoC
> >>> > flavour)
> >>> >
> >>> > If we go with 2, we might as well get 2 birds with one stone and
> >>> > bump the zmq_msg_t size to 128 as we have talked about in the past.
> >>> >
> >>> > Doron, this would help with the new UDP based socket types right?
> >>> >
> >>> > Pros of bumping msg size:
> >>> >
> >>> > - we can get rid of the malloc() in the lmsg type case as all the
> >>> > data will fit
> >>> >
> >>> > Cons:
> >>> >
> >>> > - for the vsm/cmsg type cases (for most architectures anyway) it
> >>> > won't fit anymore into a single cacheline
> >>> >
> >>> > Given all this, I'd say we should go for it.
> >>> >
> >>> > Opinions?
> >>> >
> >>> > On Sat, 2016-08-13 at 16:59 +0100, Luca Boccassi wrote:
> >>> >> Hello,
> >>> >>
> >>> >> Trying to give some thoughts again on the libzmq 4.2 release.
> >>> >> It's really long overdue!
> >>> >>
> >>> >> The main issue from my point of view is this change:
> >>> >>
> >>> >> https://github.com/zeromq/libzmq/commit/d9fb1d36ff2008966af538f72
> >>> >> 2a1f4ab158dbf64
> >>> >>
> >>> >> -typedef struct zmq_msg_t {unsigned char _ [64];} zmq_msg_t;
> >>> >> +/* union here ensures correct alignment on architectures that
> >>> >> require it, e.g.
> >>> >> + * SPARC
> >>> >> + */
> >>> >> +typedef union zmq_msg_t {unsigned char _ [64]; void *p; }
> >>> >> zmq_msg_t;
> >>> >>
> >>> >>
> >>> >> This is flagged by the common ABI checkers tools as an ABI
> >>> >> breakage
> >>> >> (see: http://abi-laboratory.pro/tracker/timeline/zeromq/ ). And
> >>> >> it makes sense from this point of view: if some applications on
> >>> >> some architectures are broken due to wrong alignment, they would
> >>> >> need to be rebuilt, and the way to ensure that is to bump the ABI
> >>> >> "current" digit to make sure maintainers do a rebuild.
> >>> >>
> >>> >> On the other hand, signaling an ABI breakage is a pain, and a
> >>> >> cause of major churn for packagers and maintainers. It means for
> >>> >> example a new package has to be created (eg: libzmq5 -> libzmq6),
> >>> >> and a transition has to be started and all reverse dependencies
> >>> >> need to be rebuilt. And if this is pointless for all save a few
> >>> >> corner cases (eg SPARC64 as for
> >>> >> above) it's all quite frustrating.
> >>> >>
> >>> >> So we have a choice to make before we release 4.2, four
> >>> >> possibilities as far as I can see:
> >>> >>
> >>> >> 1) Ignore the ABI checkers and get yelled at by maintainers and
> >>> >> packagers. Also the SPARC64 users will most likely NOT get their
> >>> >> bug fixed
> >>> >> 2) Bump ABI revision to 6 and get yelled at by maintainers and
> >>> >> packagers
> >>> >> 3) Revert the above change and postpone it to when we have a more
> >>> >> generally useful reason to break ABI (bump zmq_msg_t from 64 to
> >>> >> 128 bytes for example, Doron?)
> >>> >> 4) Try to be clever and revert the above change and use something
> >>> >> like #pragma pack(8). This will fool the ABI checkers (I tried
> >>> >> it), and given that typedef is only used externally to allocate
> >>> >> the right size it shouldn't actually affect anything, apart from
> >>> >> the users of SPARC64 which should get the bugfix with this too.
> >>> >> This is very sneaky :-)
> >>> >>
> >>> >> CC'ing Lazslo, the Debian maintainer, given what we choose to do
> >>> >> might result in a lot of work for him :-)
> >>> >>
> >>> >> Opinions?
> >>> >>
> >>> >> Kind regards,
> >>> >> Luca Boccassi
> >>> >>
> >>> >> On Tue, 2016-05-03 at 10:39 +0200, Pieter Hintjens wrote:
> >>> >> > Hi all,
> >>> >> >
> >>> >> > I'm just throwing some ideas on the table. We have a good
> >>> >> > package of work on master and it's probably time to make a 4.2
> release.
> >>> >> >
> >>> >> > Luca has already back-ported the enable/disable draft design
> >>> >> > from zproject (CZMQ et al). Yay! So we can now release stable
> >>> >> > master safely, while continuing to refine and extend the draft
> API sections.
> >>> >> >
> >>> >> > I propose:
> >>> >> >
> >>> >> > - to end with the stable fork policy; this was needed years ago
> >>> >> > when we had massively unstable masters. It's no longer a problem.
> >>> >> > - to use the github release function for libzmq releases and
> >>> >> > deprecate the separate delivery of tarballs.
> >>> >> > - we aim to make a 4.2.0 rc asap, then fix any issues we get,
> >>> >> > with patch releases as usual.
> >>> >> > - we backport the release function to older maintained releases
> >>> >> > (4.1,
> >>> >> > 3.2) so that their tarballs are provided by github instead of
> >>> >> > downloads.zeromq.org.
> >>> >> >
> >>> >> > Problems:
> >>> >> >
> >>> >> > - this will break a few things that depend on
> >>> >> > downloads.zeromq.org. To be fixed as we go.
> >>> >> > - github tarballs are not identical to source tarballs,
> >>> >> > particularly they lack `configure`. I propose changing our
> >>> >> > autotools build instructions so they always start with
> >>> >> > `./autogen,sh` no matter where the sources come from.
> >>> >> >
> >>> >> > I think this will work and also let us gracefully
> >>> >> > deprecate/switch off the downloads box.
> >>> >> >
> >>> >> > -Pieter
> >>> >> > _______________________________________________
> >>> >> > 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
> >>> _______________________________________________
> >>> 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: 2
> Date: Thu, 29 Sep 2016 12:17:57 +0200
> From: Benjamin Henrion <zoobab at gmail.com>
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Cc: Luca Boccassi <luca.boccassi at gmail.com>
> Subject: Re: [zeromq-dev] ZeroMQ 4.2 release, planning
> Message-ID:
> <
> CANjd3ncqMsuuBrYeZ2Z6qLYiypHJi1qPGXbNVTj3Yo4DK6ou2A at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Sep 29, 2016 at 12:13 PM, Pieter Hintjens <ph at imatix.com> wrote:
> > Hopefully you're back! :-)
> >
> > I see a lot of good stiff since May. Especially getting properly
> > signed downloads via HTTPS from github, rather than HTTP from
> > zeromq.org.
>
> How do you make automated mirrors with HTTP?
>
> With FTP, it is one command.
>
> --
> Benjamin Henrion <bhenrion at ffii.org>
> FFII Brussels - +32-484-566109 - +32-2-3500762 "In July 2005, after
> several failed attempts to legalise software patents in Europe, the patent
> establishment changed its strategy.
> Instead of explicitly seeking to sanction the patentability of software,
> they are now seeking to create a central European patent court, which would
> establish and enforce patentability rules in their favor, without any
> possibility of correction by competing courts or democratically elected
> legislators."
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 29 Sep 2016 14:52:09 -0400
> From: Wes Young <wes at barely3am.com>
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Subject: [zeromq-dev] czmq + draft mode
> Message-ID: <26671DA9-92C8-4E3F-9FC4-804233FF9097 at barely3am.com>
> Content-Type: text/plain; charset="utf-8"
>
> odd-ball question:
>
> if API’s are in “draft” mode, would it be prudent to add:
>
> #ifdef CZMQ_BUILD_DRAFT_API
>
> …
>
> #endif
>
> around the .c files [1]?
>
> configure.ac seems to obscure this problem by setting -enable-drafts=yes
> by default, but if you “try to take things into your own hands” [ie: w/o
> using configure, say for generating libs for cross-platform bindings], not
> setting the ‘CZMQ_BUILD_DRAFT_API’ var seems to make things fall apart.
>
>
> [1] [i have zero problem pushing some PRs here, jw if there’s an opinion
> out there]
> https://github.com/zeromq/czmq/compare/master...wesyoung:master
>
> --
> wes
> wesyoung.me
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 203 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: <
> http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160929/ff2f3bd4/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 4
> Date: Thu, 29 Sep 2016 15:06:44 -0400
> From: Wes Young <wes at barely3am.com>
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Subject: Re: [zeromq-dev] czmq + draft mode
> Message-ID: <620BD265-BB30-4C90-89E9-E22EFF3A7FD0 at barely3am.com>
> Content-Type: text/plain; charset="utf-8"
>
> gah, i guess this is made up for in the src/Makefile.am
>
> if ENABLE_DRAFTS
>
> …
>
> figures as i fire off the email… a bit confusing but i guess there’s
> probably not an easy way to get around it.
>
> > On Sep 29, 2016, at 2:52 PM, Wes Young <wes at barely3am.com> wrote:
> >
> > if API’s are in “draft” mode, would it be prudent to add:
>
> --
> wes
> wesyoung.me
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 203 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: <
> http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160929/dde1cf74/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 5
> Date: Thu, 29 Sep 2016 21:17:29 +0200
> From: Kevin Sapper <kevinsapper88 at gmail.com>
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Subject: Re: [zeromq-dev] czmq + draft mode
> Message-ID:
> <
> CAJg_8U2+YMWu5GoKzcZ3YDnnAvcuBuB86OYtxcxc8W7yZ0RVew at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I really like to avoid ifdefs as they tend to make things more complicated.
>
> For your cross compile issue you could consider adding the build script to
> zproject like I did for raspberry pi.
>
> Am 29.09.2016 21:06 schrieb "Wes Young" <wes at barely3am.com>:
>
> > gah, i guess this is made up for in the src/Makefile.am
> >
> > if ENABLE_DRAFTS
> >
> > …
> >
> > figures as i fire off the email… a bit confusing but i guess there’s
> > probably not an easy way to get around it.
> >
> > > On Sep 29, 2016, at 2:52 PM, Wes Young <wes at barely3am.com> wrote:
> > >
> > > if API’s are in “draft” mode, would it be prudent to add:
> >
> > --
> > wes
> > wesyoung.me
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160929/9646f1e5/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Thu, 29 Sep 2016 15:40:08 -0400
> From: Wes Young <wes at barely3am.com>
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Subject: Re: [zeromq-dev] czmq + draft mode
> Message-ID: <6F865CEA-F21E-4054-AC2C-CE2CA5FA92A3 at barely3am.com>
> Content-Type: text/plain; charset="utf-8"
>
> ack, ty!
>
> > On Sep 29, 2016, at 3:17 PM, Kevin Sapper <kevinsapper88 at gmail.com>
> wrote:
> >
> > For your cross compile issue you could consider adding the build script
> to zproject like I did for raspberry pi.
>
> --
> wes
> wesyoung.me
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 203 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: <
> http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160929/84a0e138/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 7
> Date: Fri, 30 Sep 2016 10:50:23 +0100
> From: James Chapman <james at linux-101.org>
> To: ZeroMQ development list <zeromq-dev at lists.zeromq.org>
> Subject: [zeromq-dev] Question about context and/or socket creation
> Message-ID:
> <CAHvkzymKZysStXCDieQ1=
> tKd8-xUn_j6STUz1yEWRvU8xvuHEw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> [apologies if you've received this twice, first send was not from my
> subscribed email address and I'm not sure it actually went to the list]
>
> Hi all,
>
> Quick question regarding the creation of contexts and sockets. Some quick
> insight:
> I have a function that gets called from a thread pool that creates a
> context, a socket, sends a REQ message and waits for a REP, after which the
> socket is closed and then deleted. If the program runs for long enough, it
> eventually crashes, the last call being in zmq.hpp (line 657)
>
> zmq::socket_t::init(zmq::context_t & context_, int type_) { ...
> ptr = zmq_socket (context_.ptr, type_ ); <--- Crash here
>
>
>
> So my question is basically, am I using contexts and sockets correctly by
> creating new instances each time I want to send a message or should I be
> re-using these as much as possible?
>
> Thanks
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160930/f32c539d/attachment-0001.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> ------------------------------
>
> End of zeromq-dev Digest, Vol 6, Issue 16
> *****************************************
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20161001/4dbe851b/attachment.htm>
More information about the zeromq-dev
mailing list