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:[email protected]] On Behalf Of [email protected] Sent: Friday, September 30, 2016 6:00 AM To: [email protected] Subject: zeromq-dev Digest, Vol 6, Issue 16 Send zeromq-dev mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 <[email protected]> To: ZeroMQ development list <[email protected]> Cc: Luca Boccassi <[email protected]> Subject: Re: [zeromq-dev] ZeroMQ 4.2 release, planning Message-ID: <CADL5_sgzND_NbiSJ8qiJ4Ph22pNOkdNHZ_85=tuieqz_+1p...@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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >>> 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 >>> >> > [email protected] >>> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >> >>> >> >>> > >>> > >>> > >>> > _______________________________________________ >>> > zeromq-dev mailing list >>> > [email protected] >>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev ------------------------------ Message: 2 Date: Thu, 29 Sep 2016 12:17:57 +0200 From: Benjamin Henrion <[email protected]> To: ZeroMQ development list <[email protected]> Cc: Luca Boccassi <[email protected]> Subject: Re: [zeromq-dev] ZeroMQ 4.2 release, planning Message-ID: <canjd3ncqmsuubryez2z6qlyiyphji1qpgxbnvtj3yo4dk6o...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Thu, Sep 29, 2016 at 12:13 PM, Pieter Hintjens <[email protected]> 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 <[email protected]> To: ZeroMQ development list <[email protected]> Subject: [zeromq-dev] czmq + draft mode Message-ID: <[email protected]> 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 <[email protected]> To: ZeroMQ development list <[email protected]> Subject: Re: [zeromq-dev] czmq + draft mode Message-ID: <[email protected]> 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 <[email protected]> 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 <[email protected]> To: ZeroMQ development list <[email protected]> Subject: Re: [zeromq-dev] czmq + draft mode Message-ID: <cajg_8u2+ymwu5gokzcz3ydnnavcubub86oytxcxc8w7yz0r...@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" <[email protected]>: > 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 <[email protected]> wrote: > > > > if API’s are in “draft” mode, would it be prudent to add: > > -- > wes > wesyoung.me > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > 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 <[email protected]> To: ZeroMQ development list <[email protected]> Subject: Re: [zeromq-dev] czmq + draft mode Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" ack, ty! > On Sep 29, 2016, at 3:17 PM, Kevin Sapper <[email protected]> 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 <[email protected]> To: ZeroMQ development list <[email protected]> Subject: [zeromq-dev] Question about context and/or socket creation Message-ID: <CAHvkzymKZysStXCDieQ1=tkd8-xun_j6stuz1yewrvu8xvu...@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 [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev ------------------------------ End of zeromq-dev Digest, Vol 6, Issue 16 ***************************************** _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
