Do you see the same for any other tcp traffic? On 15 Dec 2014 19:40, "Steve Murphy" <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> 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 >> > [email protected] >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> 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 > > > > _______________________________________________ > 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
