[zeromq-dev] Connect to UDP Multicast CoT Server

Craig Stutts ARA/SED cstutts at ara.com
Fri Sep 30 15:53:28 CEST 2016


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
*****************************************


More information about the zeromq-dev mailing list