[zeromq-dev] SOLUTION-- Encryption failure problem and wireless connectivity

Steve Murphy murf at parsetree.com
Mon Dec 15 20:40:24 CET 2014


Pieter--

I'm sorry if I gave the wrong impression. I didn't make it clear
that my app was running on over a dozen different hosts,
all spread across the internet. I was also trying to
run it on my home machine, and found I couldn't get a curve
connection to any other box from just my local machine.   I don't think
that
CURVE affects the network at all. My theory is that my wireless
connection was so lousy at the moment (it varies with
time and, apparently, weather conditions), irregardless
of CURVE, that CURVE couldn't get in a word
edgewise and the handshake couldn't complete the
startup protocol. The same software, running on a machine
a more solid network connection, yielded successful
CURVE encryption and communication.

At least, that's my theory as to why it wouldn't work on my machine.

I suspect that, had I run the program some hours/days earlier or
later, I wouldn't have had any problems. Such are the transient
vagaries of wireless, temperature, weather, auroras, sunspots,
and maybe even the phase of the moon.

murf



On Mon, Dec 15, 2014 at 5:10 AM, Pieter Hintjens <ph at imatix.com> wrote:

> There's no theory where CURVE encryption can affect network
> performance. So anything you're seeing which suggests this is
> coincidence. The only plausible interference I could imagine is heavy
> CPU cost on a node causing it to be slightly slower, yet this should
> make the network happier, not sadder.
>
> If you have any theory how encryption could affect network
> reliability, I'd like to hear it.
>
> On Sun, Dec 14, 2014 at 2:47 AM, Steve Murphy <murf at parsetree.com> wrote:
> > Pieter--
> >
> > C
> > ould you elaborate a little on the coincidence?
> > I, and maybe others, could benefit by your thoughts,
> > I believe!
> >
> > murf
> >
> >
> > On Thu, Dec 11, 2014 at 10:45 AM, Pieter Hintjens <ph at imatix.com> wrote:
> >>
> >> Since CurveZMQ runs over TCP, and the encryption is entirely
> >> abstracted from the network, this is probably coincidence.
> >>
> >> On Thu, Dec 11, 2014 at 4:17 PM, Steve Murphy <murf at parsetree.com>
> wrote:
> >> > Hello, fellow zeromq devs!
> >> >
> >> > Some months ago, I posted a problem I was having,
> >> > that was quite vexing. Since then, I figured it out, and
> >> > thought I should share before it completely gets forgotten.
> >> >
> >> > The problem appeared at first blush, to be an incompatibility
> >> > between Ubuntu and CentOS. My home node is running
> >> > Ubuntu, and all my other nodes were mostly CentOS. All
> >> > the CentoOS nodes were behaving normally, with CURVE
> >> > encryption between them. But on my home Ubuntu machine,
> >> > the same code would not establish an encrypted connection.
> >> >
> >> > At last, after wiresharking the back and forth protocol of CURVE
> >> > encryption, I saw that the protocol seemed to get to a certain
> >> > stage, and then just quit. I delved deeper and deeper into the code
> >> > underneath, and still, no particular failure point!
> >> >
> >> > Then it hit me: My home is connected to the internet via a wireless
> >> > connection. Could it be my connection? I did an MTR betwen my home
> >> > machine and the other centOS mechines, and sure enough, I was
> >> > seeing a 50% packet loss! I had not noticed any performance drop
> >> > in my connection; no slowdowns. Normally mtr between my home and
> >> > the internet is pretty clean, but that week, it was a bit shaky.
> >> >
> >> > Moved the testing off my machine and no problem.
> >> >
> >> > So, I think I may have a found a packet loss percentage at which
> >> > CURVE encryption will no longer operate (but unencrypted connections
> >> > will),
> >> > but, to be fair, the connection is via Motorola Canopy hardware, and
> the
> >> > other end of the link is somewhere near 6 miles away. Packet losses
> >> > in that environment could get somewhat selective as to size or timing.
> >> >
> >> > Just a heads-up to the other newbies on this mailing list, of a
> possible
> >> > pitfall, and how to detect it.
> >> >
> >> > murf
> >> >
> >
> > --
> >
> > Steve Murphy
> > ParseTree Corporation
> > 57 Lane 17
> > Cody, WY 82414
> > ✉  murf at parsetree dot com
> > ☎ 307-899-5535
> >
> >
> >
> > _______________________________________________
> > 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
>



-- 

Steve Murphy
ParseTree Corporation
57 Lane 17
Cody, WY 82414
✉  murf at parsetree dot com
☎ 307-899-5535
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20141215/2da8082c/attachment.htm>


More information about the zeromq-dev mailing list