Udp only work with radio-dish. You can use pgm for pubsub. On Fri, Sep 30, 2016, 16:53 Craig Stutts ARA/SED <[email protected]> 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:[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= > [email protected]> > 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= > [email protected]> > 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
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
