Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Luca Boccassi]

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/d9fb1d36ff2008966af538f722a1f4ab158dbf64
> 
> -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
> > 

Re: [zeromq-dev] Is there a zmq debug tool?

[zhangkai.gis]

I use vpn combine 192.168.9.58 to 172.16.9.108.I have no idea is the vpn 
effects.

2016-08-26 

zhangkai.gis 



From:"zhangkai.gis"
Date:2016-08-26 08:45
Subject:Re: [zeromq-dev] Is there a zmq debug tool?
To:"ZeroMQ development list"
Cc:

Thanks for the tool.My zmq is version 3.2.0 Is it possible to use the 
tool?besides I have check my push server(located in linux 192.168.2.224) It 
shows my pull client(located in win7 192.168.9.58) connect to it.But when I use 
tcpdump to show whether or not the server push data.I found that no data was 
sended.I set up another linux pull client(located in linux 192.168.2.66) I can 
saw the server push data to the linux pull client.(when the push server send 
three times I got one send to linux pull client.PUBISH-PULL model works like 
that).
Thanks,
zhangkai 


From:Kevin Sapper 
Date:2016-08-25 17:26
Subject:Re: [zeromq-dev] Is there a zmq debug tool?
To:"ZeroMQ development list"
Cc:

Hi,


you can use wireshark. There's a lua extension for wireshark that can handle 
zmtp messages https://github.com/whitequark/zmtp-wireshark.


//Kevin



2016-08-25 9:02 GMT+00:00 zhangkai.gis :

Hello all,
 I established a zmq push server(bind) in linux(192.168.2.225) and run a 
zmq pull client(connect) in Win7 64 bits(192.168.9.58). I can saw that.The 
windows client can connect to the server.But when server have message to 
push.The client did not receive msg?How can I debug with this?Is there some 
tools or method to debug with?

Thanks,
zhangkai

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] nomenclature

[Andrew Hume]

o. i think this is a misunderstanding.  it seems we’re using some terms 
very differently.

when i say “how the data will flow thru the system”, i mean “datum X needs to 
go to entity E via intermediate point Z”.
Z might be a queue and i don’t care about any subdetails (at this level) such 
as TCP/IP details or somesuch.
Z might be a router (or a malamute) and i don’t care (at this level) about any 
subdetails of Z.
so that is your “what data should be where”.

because i am talking about a communication web, i think that specifying what 
the endpoint does with
the data is out of scope. but in your context, it is plausible to say what 
responses (if any) there might be,
and how they are handled.

to my mind, it is a stretch to call that a protocol, but it is not wrong.

your analysis of teh highway system fits with the above; my claim that you need 
to know your destination
is clearly true. i never cared about “all possible configurations” (i never 
said it, but i see that you took
“flow” that way).

alex, thanks for the long reply; it helped me figure how i misspoke.
(assuming my analysis is correct!)

andrew

> On Aug 26, 2016, at 12:08 AM, alex.  wrote:
> 
> Hi Andrew,
> 
> I have to agree with Pieter here. What you want to be thinking about is: What 
> data should be where? And what shall happen with it when it is there?
> 
> I feel this is what you also want to do, but I think Pieter is right in 
> pointing out that thinking about all possible data flow is a mistake, and 
> protocols are a better vantage point. The problem, imho, is briefly: "data 
> flow" encompasses all possible events in your system, protocols define only 
> what events are legal in your system.
> 
> To use your analogy: The national highway system in Germany isn't greatly 
> defined (with it's countless driveways, reststops, roadworks, etc.), and I 
> don't suppose any one person in Germany knows *all* about it, let alone know 
> how all vehicles behave at any one point in time on the highway system. 
> However, the law on traffic in Germany (STVO) is still just 53 paragraphs 
> long and only one of them (§18) is concerned specifically about highways. 
> Still, our highway system works, everday, with all the countless vehicles 
> driving there every day. I'd say the STVO scaled extremely well!
> 
> And here is the interesting part: In almost all cases accidents aren't faults 
> of the driving rules, but of the drivers not upholding the rules. As a 
> computer scientist, you could say that bad drivers are the bugs of the road 
> system. And for the few cases where your protocol was faulty, you only have 
> to change one or two sentences in your law/protocol (not all the drivers).
> 
> So I would also recommend to you to not think about all the moving parts in 
> all their possible configurations (i.e. all the cars on the road), but to 
> really boil it down to: What data should be where? And how should receivers 
> of that data respond to it? That is, write a protocol.
> 
> Best,
> alex.
> 
> P.S. This is also why I came to love finite state machines: as they translate 
> your protocol-law perfectly into code.
> 
> Am 25.08.2016 um 21:36 schrieb Andrew Hume:
>> pieter,
>> 
>>  i can’t figure out what you’re saying here. based on my several years 
>> experience
>> with you, i have to conclude that i have somehow misspoken.
>> 
>>  i have a distributed application. that is, there are a number of 
>> discrete components
>> that (for this discussion) are distinct processes running on some number of 
>> servers.
>> some are accessed thru RPC calls, others generate work that then processed by
>> some number of worker components.
>> 
>>  in order for this to work, i clearly need to figure out how data will 
>> flow
>> through this system. as i have understood the design methodology around 
>> zeromq,
>> this means figuring out the fixed points in the data flow and organising the
>> components around those fixed points. some of these allow for “scaling”
>> (as in increasing the size of a worker pool).
>> 
>>  so i don’t understand
>> 1) how can this sort of design be a “mistake”? how can you do anything 
>> without
>> (trying to) understand where the data needs to go?
>> 
>> 2) many protocols (which i guess you mean things defined by RFCs) don’t 
>> scale;
>> they simply detail teh bi-lateral contract between (roughly) user and 
>> supplier of a service
>> (like NTP). i know some address this directly (like the Gossip protocol), 
>> but surely you don’t mean just those?
>> 
>>  andrew
>> 
>> 
>>> On Aug 24, 2016, at 11:06 AM, Pieter Hintjens  wrote:
>>> 
>>> FWIW I have come to believe that trying to design or even understand
>>> the overall flows of data is a mistake, at least when you want to
>>> scale.
>>> 
>>> What does scale is to speak of protocols and implementations. I know
>>> this isn't a happy answer yet it's a proven one (RFCs, Internet).
>>> 
>>> 

Re: [zeromq-dev] nomenclature

[alex.]

Hi Andrew,

I have to agree with Pieter here. What you want to be thinking about is: 
What data should be where? And what shall happen with it when it is there?


I feel this is what you also want to do, but I think Pieter is right in 
pointing out that thinking about all possible data flow is a mistake, 
and protocols are a better vantage point. The problem, imho, is briefly: 
"data flow" encompasses all possible events in your system, protocols 
define only what events are legal in your system.


To use your analogy: The national highway system in Germany isn't 
greatly defined (with it's countless driveways, reststops, roadworks, 
etc.), and I don't suppose any one person in Germany knows *all* about 
it, let alone know how all vehicles behave at any one point in time on 
the highway system. However, the law on traffic in Germany (STVO) is 
still just 53 paragraphs long and only one of them (§18) is concerned 
specifically about highways. Still, our highway system works, everday, 
with all the countless vehicles driving there every day. I'd say the 
STVO scaled extremely well!


And here is the interesting part: In almost all cases accidents aren't 
faults of the driving rules, but of the drivers not upholding the rules. 
As a computer scientist, you could say that bad drivers are the bugs of 
the road system. And for the few cases where your protocol was faulty, 
you only have to change one or two sentences in your law/protocol (not 
all the drivers).


So I would also recommend to you to not think about all the moving parts 
in all their possible configurations (i.e. all the cars on the road), 
but to really boil it down to: What data should be where? And how should 
receivers of that data respond to it? That is, write a protocol.


Best,
alex.

P.S. This is also why I came to love finite state machines: as they 
translate your protocol-law perfectly into code.


Am 25.08.2016 um 21:36 schrieb Andrew Hume:

pieter,

i can’t figure out what you’re saying here. based on my several years 
experience
with you, i have to conclude that i have somehow misspoken.

i have a distributed application. that is, there are a number of 
discrete components
that (for this discussion) are distinct processes running on some number of 
servers.
some are accessed thru RPC calls, others generate work that then processed by
some number of worker components.

in order for this to work, i clearly need to figure out how data will 
flow
through this system. as i have understood the design methodology around zeromq,
this means figuring out the fixed points in the data flow and organising the
components around those fixed points. some of these allow for “scaling”
(as in increasing the size of a worker pool).

so i don’t understand
1) how can this sort of design be a “mistake”? how can you do anything without
(trying to) understand where the data needs to go?

2) many protocols (which i guess you mean things defined by RFCs) don’t scale;
they simply detail teh bi-lateral contract between (roughly) user and supplier 
of a service
(like NTP). i know some address this directly (like the Gossip protocol), but 
surely you don’t mean just those?

andrew



On Aug 24, 2016, at 11:06 AM, Pieter Hintjens  wrote:

FWIW I have come to believe that trying to design or even understand
the overall flows of data is a mistake, at least when you want to
scale.

What does scale is to speak of protocols and implementations. I know
this isn't a happy answer yet it's a proven one (RFCs, Internet).

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev