Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's Always TCP_NODELAY

brooker.co.za

Post reply on HN
Print view View original

161–170 of 186 posts

Re: It's Always TCP_NODELAY

#161

Post by immibis »

josefx wrote: post #139
readmodifywrite wrote: post #133

Earlier quoted context omitted.

If you were using TCP, then this is absolutely normal and expected behavior. It is a stream protocol, not packet/message based.

At the application layer you would not see the reordered bytes. However on the network you have IP beneath both UDP and TCP and network hardware is normally free to slice and reorder those IP packages however it wants.

It's not. Routers are expected to be allowed to slice IPv4 packets above 576 bytes. They can't slice IPv6 and they can't slice TCP.

However, malicious middleboxes insert themselves into your TCP connections, terminating a separate TCP connection on each side of the spyware and therefore completely rewriting TCP segment boundaries.

In less common scenarios, the same may be done by non malicious middleboxes - but it's almost always malicious ones. The party that attacked xmpp.is/jabber.ru terminated not only TCP but also TLS and issued itself a Let's Encrypt certificate.

Re: It's Always TCP_NODELAY

#162

Post by kayfox »

mikestorrent wrote: post #64
Hikikomori wrote: post #23

Earlier quoted context omitted.

Just to add, ethernet uses csma/cd, WiFi uses csma/ca. Upgraded our DC switches to new ones around 2014 and needed to keep a few old ones because the new ones didn't support 10Mbit half duplex.

What did you still need to connect with 10mbit half duplex in 2014? I had gigabit to the desktop for a relatively small company in 2007, by 2014 10mb was pretty dead unless you had something Really Interesting connected....

Things I have found that only do 10mbit:

Old CNC equipment.

Older Zebra label printers.

Some older Motorola radio stuff.

That SGI Indy we keep around for Jurassic Park jokes.

The LaserJet 5 thats still going after 30 years or something.

Some modern embedded stuff that does not have enough chooch to deal with 100mbit.

Re: It's Always TCP_NODELAY

#163

Post by nomel »

CamperBob2 wrote: post #155
sundbry wrote: post #146

Earlier quoted context omitted.

If only there was some sort of User Datagram Protocol where you could send specifically tuned packets like this.

Those who do not understand TCP are doomed to reimplement it with UDP. The same is true of those who do understand it.

That first time you do sure is fun though.

Re: It's Always TCP_NODELAY

#164

Post by [deleted] »

switchbak wrote: post #45
gerdesj wrote: post #42

Earlier quoted context omitted.

Sorry? Ethernet has had the concept of full duplex for several decades and I have no idea what you mean by: "hybrid on each end allows the use of the same channel at the same time." The physical electrical connections between a series of ethernet network ports (switch or end point - it doesn't matter) are mediated by CSMA. No idea why you are mentioning radios. That's another medium.

My understanding is that no one used hubs anymore, so your collision domain goes from a number of machines on a hub to a dedicated channel between the switch and the machine. There obviously won’t be collisions if you’re the only one talking and you’re able to do full duplex communications without issue.

[deleted]

Re: It's Always TCP_NODELAY

#165

Post by nomel »

switchbak wrote: post #45
gerdesj wrote: post #42

Earlier quoted context omitted.

Sorry? Ethernet has had the concept of full duplex for several decades and I have no idea what you mean by: "hybrid on each end allows the use of the same channel at the same time." The physical electrical connections between a series of ethernet network ports (switch or end point - it doesn't matter) are mediated by CSMA. No idea why you are mentioning radios. That's another medium.

My understanding is that no one used hubs anymore, so your collision domain goes from a number of machines on a hub to a dedicated channel between the switch and the machine. There obviously won’t be collisions if you’re the only one talking and you’re able to do full duplex communications without issue.

> My understanding is that no one used hubs anymore

this is absolutely hilarious.

Re: It's Always TCP_NODELAY

#166

Post by myself248 »

mikestorrent wrote: post #64
Hikikomori wrote: post #23

Earlier quoted context omitted.

Just to add, ethernet uses csma/cd, WiFi uses csma/ca. Upgraded our DC switches to new ones around 2014 and needed to keep a few old ones because the new ones didn't support 10Mbit half duplex.

What did you still need to connect with 10mbit half duplex in 2014? I had gigabit to the desktop for a relatively small company in 2007, by 2014 10mb was pretty dead unless you had something Really Interesting connected....

APC UPS SmartSlot network monitoring cards. Only the very newest support 100Mbps....

Re: It's Always TCP_NODELAY

#167

Post by hylaride »

switchbak wrote: post #45
gerdesj wrote: post #42

Earlier quoted context omitted.

Sorry? Ethernet has had the concept of full duplex for several decades and I have no idea what you mean by: "hybrid on each end allows the use of the same channel at the same time." The physical electrical connections between a series of ethernet network ports (switch or end point - it doesn't matter) are mediated by CSMA. No idea why you are mentioning radios. That's another medium.

My understanding is that no one used hubs anymore, so your collision domain goes from a number of machines on a hub to a dedicated channel between the switch and the machine. There obviously won’t be collisions if you’re the only one talking and you’re able to do full duplex communications without issue.

Hubs still exist(ed), but nobody implemented half-duplex or CSMA from gigabit ethernet on up (I can't remember if it was technically part of the gig-e spec or not)

Re: It's Always TCP_NODELAY

#168

Post by eieio »

dan-robertson wrote: post #160
eieio wrote: post #61

Earlier quoted context omitted.

I've been playing with multiplayer games that run over SSH; right now I'm trying to push the framerate on the games as high as I can, which is what got me thinking about my networking stack. I mostly use go these days for the backend for my multiplayer games, and in this case there's also some good tooling for terminal rendering and SSH stuff in go, so it's a nice choice. (my games are often pretty weird, I understan…

Two things that can have a big impact on SSH throughput are cipher choice and the hardcoded receive buffer size. These are described in the fork https://github.com/rapier1/hpn-ssh Maybe that will be useful for thinking about workarounds or maybe you can just use hpn-ssh.

ah this is great, thanks dan!

Re: It's Always TCP_NODELAY

#170

Post by tptacek »

teach wrote: post #169
tptacek wrote: post #145

Earlier quoted context omitted.

Funner trivia is why he's named "Animats".

I've been on HN a long time and this comment was the one to finally make me realize that "animats" is "stamina" spelled backward.

See, I didn't even realize that --- wasn't what I was referring to! :)
Post reply on HN