“I survived the TCP transition” (2013)
blog.google
blog.google
Of course it had drawbacks, but for that it was great.
IPX/SPX worked without that assumption; it was bog simple to find some IPX cards, shove them in the computers, connect them, and go, even if you knew nothing.
The closest for TCP/IP would be to support gaming over link-local links (those 169.* addresses) but everything is assumed to be on the internet now.
And if you have TCP/IP for the internet, rarely do you care or need anything else for local comms.
The big downside is that if some people are on WiFi then they'll be reduced down to 802.11b speed.
A better solution would be to do server/player discovery via multicast and then stitch up unicast links for the actual gameplay.
Though I have seen games that apparently use an internet service to coordinate direct links ...
On a typical home network I've never really had any issues with mDNS. It works great on Mac and I've got it running fine on various bsd's and linux. I found mdnsd worked surprisingly well on FreeBSD, and took less configuration that Avahi. I will admit that windows doesn't seem to play that well with it.
I'm curious what you tried that didn't work.
> A better solution would be to do server/player discovery via multicast and then stitch up unicast links for the actual gameplay.
That's basically what most mDNS applications do today (the modern standards compliant name for used to be called Bonjour): use .local multicast for service discovery and then often use that to bootstrap to unicast links. It's not a bad way to go, with the only caveats that to get good mDNS support in Windows I believe that you still have to dig into WinRT components rather than old school Win32 sockets APIs and that especially seems to cramp many games from even trying to use it for LAN discovery today despite it being a mostly reliable standard in 2022.
Few people actually built IPX networks, let alone routed them, etc.
The complications most people associate with Bonjour/Avahi and its "points of failure" are most often issues with optional add-on standards such as DNS-SD [1] UPnP [2], and other related add-on standards on top of mDNS that make up so called "zero-conf networking". You don't need DNS-SD or UPnP to use mDNS for basic hostname discovery.
[0] https://en.wikipedia.org/wiki/Multicast_DNS
[1] https://en.wikipedia.org/wiki/Zero-configuration_networking#...
>The first version of the Doom IPX network code transmitted its data as broadcast data. As a result of this, all machines on a network where a game of Doom was being played would receive the data, even if the machine was not involved in the game. The degrading effect on network performance forced the system administrators for many office networks to ban Doom.
Even now it's only somewhat doable to do it without relying on 3rd parties by using wireguard. So I can see why relying on a third party became the default.
If IPv6 and NAT was not a thing then IP LAN games would have probably had no trouble. Factorio still does multiplayer through direct UDP/IP, so you can definitely play it online purely IP P2P. I've played Factorio games served using ZeroTier before with no issue and it's allowed me to host Factorio on my laptop from both home and a hotel.
Scanning your/24 network works, but many people are on 10.x.x.x these days
And I don’t know how this works on ipv6
Anyway...one afternoon I was at a law office installing some legal library software (or something), and one of the younger lawyers asked me into his office. He had a couple copies of Warcraft and Command & Conquer, he had installed them on a couple of the office computers but couldn't get network play going.
Not really knowing what I was doing, I opened up the properties dialog for the network adapter, added the IPX/SPX protocol, and started the game up on two computers.
It worked! It was that simple. I remember the guy pulling a $50 out of his wallet and handing it to me. And, since they were within walking distance of our office, I got invited back over a couple times and we played a lot of games (and drank a lot of beer) over there.
Since I started out in the testing department, I not only had to deal with a bunch of protocols (IPX, NetBios, etc.) but I also had to deal with a bunch of stuff at the physical layer. Instead of everything being Ethernet, we had Token-ring and ArcNet cables running everywhere.
Most importantly, the two wires that make up the pair really just are common single-ended wires, not elaborate coax or anything else.
A single coax transmission line supporting 10Gbps Ethernet would likely be much more expensive than the little bundle of twisted pairs we typically use nowadays.
In many ways, for its applications, twisted pair and RJ45 connections are better than coax wiring with BNC.
Yeah, but mechanically, the RJ45 plug with its finicky easily breakable plastic tab can be an annoyance. And it's easy to see that the pin ordering is not ideal, with the pair in the middle splitting another pair. AFAIK, there exists a more robust connector (the M12 connector), but it doesn't seem to be that common.
Maybe M12 is that, but it looks way more expensive at first glance. Possibly more laborious to connect/disconnect, too, with its screw-locking? Seems to be better for applications where a secured connection is more important (transportation is mentioned).
And yeah, the 1000base-T pin ordering seems unusual. I'm curious about the history there, because even 10base-T (where I thought Ethernet for Twisted Pair begun) had this really weird pinout, which does not support my initial theory that it was because Ethernet kept progressively adding more differential pairs: https://www.arcelect.com/10baset.htm It may well be because they added the original two pairs to a pinout that already carried something else, but the diagrams don't say what those other lines were for, so if anyone knows...
According to those same diagrams, though, it seems to be more common to split up the pairs than not, which now makes me wonder if there is any benefit to that?
Telephones. Telephones are why. Those other two pairs were often used for voice communication. If you had four-pair station cabling, the pairs were provisioned on the modular jack from the inside out. So line one was the blue/blue-white pair on the inner pins, line two was the orange/orange-white pair on the next two pins, and so on.
Ethernet comes along and lots of places where you'd want a network connection already had a phone jack with two pairs unused, so for signal integrity reasons those are moved to the outside and used for data, leaving the inner two pairs where they were to be used for voice.
But why 4 pairs in the first place?
Just about the time that Ethernet was transitioning from coax to twisted pair, the digital PBX was taking over from key systems (1A2) and reduced the number of wires required for a business telephone from 25 pairs (or more ... secretarial sets often had 100 or more pairs) per station down to 4 (for HORIZON[0]) and later two pairs (DIMENSION and eventually Merlin, Definity, etc.). So if you're wiring a new building, you can just run one CAT-3[1] cable to each desk and use the first two pairs for voice and the second two for data[2].
[0] OK, for the pedants out there, HORIZON wasn't ever very popular and really pre-dated Ethernet, but the telecom world moves kinda slow [1] Wasn't really CAT-3 until the early 90s [2] Not on the same jack, but by using pins 1, 2, 7, and 8 for data, you can plug the wrong cable in without risk of hurting the phone or your computer's network card
> so for signal integrity reasons those are moved to the outside and used for data
I'm not sure about that bit, though. Would keeping the pair together not help with signal integrity?
But 10BASE-T uses pins 1, 2, 3, 6, thus green and orange pair.
I've seen somewhere that a pair of the two outer lines didn't have sufficient performance, so the outer pairs needed to wired side by side instead, but I don't have a reference. Also, there's a reasonable question of why use one inner pair and one outer pair, and not both inners or both outers.
That is not really the fault of the RJ45 specifications. The choice is available between cheap breakable connectors or reliable well-designed connectors: it isn’t the fault of the specification that cheap is often chosen.
> the pin ordering is not ideal
A very minor nitpick. And designed that way for specific reasons.
I like that it works well, was backwards compatible, and the connectors, wiring, and tools are cheap, available, and abundant. 1000Base-T is amazing technology (even if we are blasé about it!)
1. https://community.fs.com/blog/what-is-multigig-ethernet.html
Do you know that reason? I was wondering in my other reply.
Nothing stops you from wiring connectors different way though, to the annoyance of anybody splicing that cable in the future :)
You can only swap the wires in a pair (eg swap solid orange and striped white/orange), or swap pairs (eg blue pair with orange pair).
You must keep each twisted pair matched, so that the electrical signal travels correctly, otherwise you run into problems at length. For very short runs I would guess you could ignore pairs, even though it would increase crosstalk (between signals within a cable) and interference (aerial like transmission or reception, especially with different cables run close together).
Great picture of different twists per centimetre comparing each pair within a cable (compare orange against blue in one cable), and also shows the different twists for different cats (less for cat5, more for cat6): https://store.chipkin.com/articles/differences-between-categ... — if the twist lengths of all pairs were exactly the same within a cable, there would be a lot more crosstalk between pairs.
And my experience with QUIC so far has been delightful — it's everything I've wanted for decades when TCP was too restrictive and UDP too anaemic.
I did a lot of funky things to get around the "drop all UDP" firewall at my first student dorm :)
In the world of virtual machines, UDP is always the first thing to die. Xen on Amazon, for example, would often (and almost always, if there was any load at all?) silently discard most UDP traffic, and this was true for years. VMWare (back when it was still being actively developed and supported) had fairly atrocious support for UDP as well, and the "atrocious support" level was only if you explicitly enabled it and carefully configured it in the first place. In one VM implementation (15+ years ago, so I can't remember which, but probably VMWare or Xen), we determined that the UDP buffer size was a total of one packet (~1500 bytes). So if you wrote a test that sent or received a burst of more than one packet, only one packet out of the entire burst would have greater than a 0% success rate and the rest were lost.
Back then, I was testing with UDP on EC2 before EC2 was open to the public. I was working with UDP-based server clustering tech (previously used by Amazon, since acquired by Oracle). Still have the scars.
It's been many years, so my guess is that reasonably decent UDP support has slowly crept into EC2 and other common cloud and virtualization environments, and may even be decently supported by now. It needs to be very good to support the transition to HTTP/3 (which coincidentally I'm currently working on).
The virtual circuit stuff looked very attractive if you worked for Ma Bell and wanted to charge by the connection, but thankfully lost out to packet-switched networking.
I remember they would have a failure a couple of times a week where some switches would freeze up. Someone would send an alert and a data center operator would plug a null modem cable into the switch and remove it. That would un-fubar the switch.
Or OSI will crash and burn and we'll all pretend it was just a model from day one, and insist that TCP/IP is best understood using precisely the kind of strict layering the IETF explicitly rejected in RFC 3439. Y'know, whatever reinforces the notion that we never lose.
Always a bad sign when another protocol comes along and calls itself "lightweight", as in LDAP, the "lightweight directory access protocol" merely based on X.500.
SMTP is also the "simple" mail transfer protocol, but it's not based on X.400 in any way and was apparently replacing... FTP! (Only for one particular use case obviously.)
The article was posted on January 1, 2013, the 30-year anniversary of the deadline for ARPANET nodes to switch over to TCP. The next New Year's Day will thus be the 40th anniversary.
I met Vint Cerf at a Keck Institute for Space Studies [1] workshop on computing infrastructure in deep space. He was knowledgeable, energetic, funny, and volunteered to take notes for an all-day working session. The goal was to lay out requirements and benefits of flying servers to orbit around distant bodies for on-site analysis. You can get a lot of data from cameras, but you can't send nearly any of it back, so do interactive data reduction on site, right?
He was at Google Loon at the time, working on their delay-tolerant networking & dynamic routing for their baloon-internet architecture. He's been super active in the NASA community working on their delay-tolerant networking architecture. The whole stack is really beautiful. In space, you know when nodes are coming over the horizon because they are in regular orbit, so you can plan routes for the future using "contact-graph routing", and use store-and-forward to massively increase throughput. (e.g., orbiters hold data automatically until they are in sight of the next hop). Nothing you can do about latency, with speed of light and all that though :) JPL has an open-source implementation maintained by Scott Burleigh, another really neat person, and I think JHU/APL does too. [2]
Anyway. The guy is smart, sure, but he's also immediately influential: You can't help but agree with him when he pushes these simple, effective ideas naturally.
Why do we take this for granted? I understand the laws of physics and all, but 120 years ago we didn't think humans could fly through the air, and now we have a million+ humans flying every day, and occasionally one goes to outer space.
Why do we consider communication faster than the speed of light so unbreakable?
This constant, c, is actually about how time (one of our four dimensions, often labelled t) is related to the three spatial dimensions (often x, y, z).
Light goes that fast (in a vacuum) because from the light's point of view that's how those dimensions are related, it's not really a "speed limit" it's up against, any more than you'd consider it a "time limit" that hours have sixty minutes in them. The light is just moving through time as well as space, and that's how it has to work.
So, because it's about the relationship between time and space, what you're talking about with "faster than light" is actually a time machine.
Now, you might notice that before the aeroplane there were birds (and bats, and insects, but lets focus on birds). Clearly flying is possible, a sparrow can do it. But you may have noticed from the lack of time travelling visitors that time travel does not seem to be possible.
While time travel may not be possible, maybe time traveling data is?
We have observed that we can generate a pair of particles and separate them, and when we look at the close one, we now know that the far one has the complementary property. You can't use that to send information. You could use it as a shared secret, but you still had to move the particle out where your recipient is for them to use it.
You can take a flashlight and shine it at the moon, and if you sweep the beam back and forth, you can make the notional front of illumination move faster than the speed of light -- but you can't modulate the signal faster than the propagation velocity c.
Time travel into the future is easy. Time travel into the past doesn't work in this universe.
Only the imaginary "wave function collapse" is faster than light. But collapse isn't actually part of quantum mechanics: there's no formula that would tell you when collapse is triggered. The many world interpretation doesn't have any wave function collapse at all; and it's a valid interpretation of the underlying maths. Any "wave function collapse" is merely an interpretation trick to map the quantum world back to the classical world as experienced by humans. You can't build technology out of imaginary physics.
You may try to come up with clever encodings for electron spins, but you’ll see that you end up having to know a priory what the other end had. It’s a long topic to discuss on a HN thread but a quick YouTube search will get you interesting videos.
Think of entanglement as pair of boots. You’ve got one boot with you and unwrapped it on the mars. Voila, you know that one left on Earth is left one. This analogy is wrong but good enough to understand why entanglement does not help with communication.
Proper operation of GPS requires a time correction [1] because the system's satellites are moving at significant speed from the perspective of ground observers. Their onboard clocks are therefore moving relatively faster through space, and thus relatively slower through time.
This is measurable at the nanosecond scale, and must be taken into account every time something uses GPS.
1. https://www.astronomy.ohio-state.edu/pogge.1/Ast162/Unit5/gp...
"Relativistic speed" doesn't mean some particular speed, like 0.1c or something, it just means any speed where your measurements don't make sense without accounting for relativity, if your measurements were good enough this just doesn't have to be that fast really.
However, do you remember simple school spring balance experiments which show Newtonian mechanics? Greg Egan's "Incandescence" is a novel about some people who live somewhere where those type of experiments need relativity to explain them, so, when they develop physics they go from "I dunno, it just always does that" straight to relativity because Newtonian mechanics don't explain what they already know about the world.
We still haven't seen anything in nature that even hints to the possibility of faster than light
Hot air balloons had been around since the 1700s, and gliders were developed in the 1800s. Those were the first "heavier than air" aircraft, and a manned glider was flown by the end of the 19th century. Powered flight was an extension of that model.
We have no model of faster than light communication (or travel) that holds up to scrutiny, let alone has been demonstrated.
FTL may or may not be possible via physics we don't understand. Until we have that physics and a system to exploit it FTL is a very real constraint to work around. Don't mistake "Nothing we can do" for "nothing we can ever do".
That would be physically impossible to see in the first place, wouldn't it?
As an aside to the aside - as I rewatch it I quickly notice how young he looks (and then note the date is 2015 on there - one of the early ones and the production is less refined).
You may also like The Geometry of Causality https://youtu.be/1YFrISfN7jo
Because it's the definition of the simulator we inhabit. c isn't some random thing to do with light that we observe and find curious, it's literally the nature of the universe. The universe is "a place where the speed you can propagate information is : c". The speed of light follows from that, not the other way around.
So if that's breakable, then we made some very big invalid assumptions over the past 200 years.
Also, it's questionable that "we didn't think humans could fly through the air". Obviously some people did think that was possible, otherwise they wouldn't have tried to do so. We had birds and bats as existence proofs too. And balloons.
pragmatism: our best current theories about the universe suggest that the speed of light is a constant. Until someone proposes a theory with more explanatory power that suggests otherwise, we might as well do our work with the assumption that it's correct.
Hubris: our best theories are clearly not complete (see dark matter, conflicts between general relativity and quantum mechanics, and similar), yet we mostly treat them not as provisional theories subject to change, but as ironclad laws by which we may live our lives. Humans don't do well with uncertainty.
(Disclaimer: not everyone lives that way. As far as I can tell most who do have something like this combination of ideas in their heads.)
On the other hand, we have never encountered anything in nature that goes faster than the speed of light. That's a pretty good hint that it's impossible to do so.
"At one of the quarterly meetings Vint Cerf came in and dropped a bombshell on us: he said TCP had become a standard. Our immediate reaction, or at least my reaction, was 'Wait: it's not done yet. We have this long list of things we still have to figure out'," Haverty recalled in his speech.
The technology was out of developers' hands before they felt ready to let it go.
Haverty said the teams he worked with always expected to fix and polish their work – not just build on top of what he referred to as an "experiment."
"There's all sorts of operational issues that we went through and developed but they haven't made it into the real world,” he said. [1]
[1] https://www.theregister.com/2022/03/01/the_internet_is_so_ha...
But the writing was already on the wall.
It sucked less than fooling around with Trumpet Winsock on Win3.1 though!
Part of the response was the IAHC which came up with the template for the fix: break up the monopoly by splitting registries and registrars, force Network Solutions to relinquish some of its TLDs, and create more TLDs.
https://en.m.wikipedia.org/wiki/IAHC
This was not immediately successful, until Postel (as IANA) instructed the root DNS operators (other than Network Solutions) to get the root zone from IANA instead of from NetSol. This caused an epic shitfest, as a result of which Postel reverted the root zone change, and the US NTIA got moving and started the foundation of ICANN.
The company now known as Verisign is the direct successor of NetSol, and they still control .com and .net, and feed the root zone to the other root server operators.
"Hello, would you like to have a TCP transition?"
"Yes, I'd like to have a TCP transition."
"OK, I'll get you a TCP transition."
"Ok, I will have a TCP transition."
"Are you ready to have a TCP transition?"
"Yes, I am ready to have a TCP transition."
Network Error (tcp_Error)
The only thing which surely will be replaced are the routing exchange protocols like BGP with all the shenanigans happening there.
If you believe in space colonialism then there will be some kind of message oriented layer on top to deal with the latencies (think universal SMTP or something).
The original tweet for any who want that link is https://twitter.com/webfoundation/status/1105425858913816576
(scroll, scroll... oh neat)
The back of the shirt is https://twitter.com/vgcerf/status/1105467776477679616
It will be easy to add support on the back end (at least for any software that already supports HTTP/2). So adoption will be limited by the front end. Adoption may come sooner, but only if telcos and phone makers both agree that it will help them. (Mobile currently represents ~75% of web usage, and still growing.)
Shortly after, I turned IPv4 back on and disabled the extra IPv6 support in my router. What I found was that everything in my house worked more or less fine, but that IPv6 to the outside was a problem because few websites support IPv4. So you need to be dual stack or run a proxy.