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).
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.
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 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.