8 ms·

I started my coding career in the early 90s and at that time there were a buttload of non-TCP network protocols running on small computers (Macs, PCs, etc.) Net

I started my coding career in the early 90s and at that time there were a buttload of non-TCP network protocols running on small computers (Macs, PCs, etc.) Netware, LANtastic, AppleTalk, Netbios stuff... Even though they all had something going for them I'm glad they have been steamrollered by TCP/IP

kuon 4y ago
IPX worked very well for LAN games, it required no configuration. Compared to how difficult it is to play together now (steam friends. xbox...), it was much better. Of course it had drawbacks, but for that it was great.
- jandrese 4y ago
  That's just LAN play dying off in favor of (routeable) Internet play. If developers wanted to they could add IP LAN play to games, but there's just not enough demand.
  - bombcar 4y ago
    The assumption is that if you're on an IP network, you already have addresses, etc (because you're routable to the internet). 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.
    - jandrese 4y ago
      You could also do it over multicast. 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.
      - bombcar 4y ago
        Yeah, anything actually doing it today will do something like multicast/bonjour and then do direct links. Though I have seen games that apparently use an internet service to coordinate direct links ...
        eklavya 4y ago
        I seem to have never had a reliable and working mDNS on any OS. Would not recommend.
        MobiusHorizons 4y ago
        Is it possible your network disables multicast? 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.
        bombcar 4y ago
        Only problem I've ever observed is not letting it "calm down" as some mDNS implementations (maybe no more) used to try to cache/answer for other machines.
      - WorldMaker 4y ago
        That's all IPX/SPX was was link local multicast. I see all the "no configuration" required love for it in surrounding comments, but I suppose few remember the failure states when it didn't work as expected, including drowning an entire switch (or worse token ring) in multicast noise. I know I hit IPX/SPX config hell a few times over the years in home LAN gaming, and I can't believe I was that alone in it, so I'm assuming the nostalgia goggles are in play in some of these "it just worked" memories. > 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.
  - contravariant 4y ago
    I can see why it died off. There were preciously few ways to have LAN play over a distance without weird connection issues. At some point I recall that Hamachi did work fairly well, but that meant you still had to rely on a third party in the end. 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.
    - Thlom 4y ago
      I remember back in the 90’s and early 00’s my cousin and his neighbors had a neighborhood LAN going. They had stretched I believe Ethernet cables across the street and from house to house. It might actually have been coax cables in a ring network of some sorts. Anyway. They had an IRC server going and shared files and played games. Seemed like good times.
  - Karrot_Kream 4y ago
    It all comes down to NAT and dynamic IPs. Let's say Anu and Bob and Chen are trying to play a game. Anu runs the server and wants Bob and Chen to connect to her server. Anu follows some guide to get her IP and gives it to the others, but it's not routable publicly because of some form of NAT, or her IP is dynamic and changes and so packets become unroutable to Anu. Now all Anu needs to do is press "Start Game", where a remote server either hosts the game metadata or just acts as a glorified STUN/TURN server and the remote server gets a friendly name that Bob and Chen can use to connect to the game. 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.
  - jbverschoor 4y ago
    Bonjour / mDNS / broadcasting doesn’t play nice on all routers. 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
- Wohlf 4y ago
  TCP LAN games were also easy to set up.
- bluedino 4y ago
  Way back when I first started working for a small networking outfit, we were informally split into 'Team Red' and 'Team Blue'. Everyone agreed that Novell was on the way out, and the younger guys with their MCSE's made up most of Team Blue. I had un-officially started 'Team Yellow' and was sticking Linux boxes in when I could. 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.
- EamonnMR 4y ago
  The difference between then and now is less protocol and more pervasive authentication.
didgetmaster 4y ago
I worked at Novell in the late 80s, early 90s. In the LAN world, IPX/SPX worked pretty well but it was certainly steamrolled by TCP/IP. 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.
- zwieback 4y ago
  Yup, I worked on a PC-to-Mac networking server product and we tested with TokenRing as well. Massive hardware but good performance. We also had a lot of coax wire in those days. To this day I still look down on twisted pair and the garbage Ethernet connectors we use now.
  - anyfoo 4y ago
    Electrically, there's not much reason to look down on Twisted Pair. It is an ingenuous way to achieve what coax does as an unbalanced transmission line with, well, a twisted pair of wires that form a balanced (differential) transmission line. You might need to add some shielding in some situations, but that's just a piece of foil. 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.
    - cesarb 4y ago
      > Electrically, there's not much reason to look down on Twisted Pair. 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.
rjsw 4y ago
I have AppleTalk compiled into the kernel on the machine I'm using to type this, have also done some work on adding CHAOSNET to it.
pavon 4y ago
I'm glad IP took over everything, but I wish that TCP hadn't become practically mandatory. There are some other really useful transport layer protocols, like SCTP that are great to use on a LAN, but good luck getting them to work on the internet. The only way to do anything other than TCP is to layer/tunnel it over UDP, and even that has less support than TCP.
- rjsw 4y ago
  I'm part way through adding support for SCTP to the NetBSD firewall. Have done the basic filtering stuff, still working on doing NAT for it.
- jeffparsons 4y ago
  Fortunately that era is coming to an end. With QUIC (layered on top of UDP) being the basis for HTTP/3, very few networks will outright block QUIC traffic as many have done with UDP. 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.
  - Karrot_Kream 4y ago
    I hope so. QUIC gives us so much of what SCTP should have given us. But we'll see how the middleboxes deal with things. If they want to block QUIC, like they block UDP, they can.
  - dicknuckle 4y ago
    Wait, who blocks UDP? I've worked many different angles of the technology world and never heard of anyone blocking something so ubiquitous.
    - obscurette 4y ago
      Many network owners block UDP at borders. It helps a lot in case of amplification DDOS attacks.
    - p_l 4y ago
johngalt 4y ago
To this day I think ATM was an interesting approach. Virtual circuit switching with quality of service capabilities designed into the protocol. If nothing else, it is a great example of a complex and optimized protocol losing vs a ubiquitous and simple protocol.
- kstrauser 4y ago
  It was "interesting", all right. For instance, its packet payloads were 48 bytes long. Why? Because 32 was too short for large streams (with a 5 byte header representing a 13% overhead), and 64 was "too long" (!!!) for real-time voice connections. 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.
  - Spooky23 4y ago
    The hardware was garbage too. I ripped that crap out of a place that went all in with some IBM/Lucent ATM solution. 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.
msla 4y ago
Not to mention the Real Person All Grown Up Protocol Stack, OSI, which of course was going to displace this ARPANET childishness with protocols like the X.212 data link layer that, like all data link layer protocols, provides checksumming and resending and distinguishes between connection-oriented and connectionless communication, plus X.400 email which, naturally, uses the simple, comprehensible, easy-to-implement X.500 directory service, for email addressing inherently tied to your employer and physical address. 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. https://www.rfc-editor.org/rfc/rfc3439 https://www.rfc-editor.org/rfc/rfc3439
- anyfoo 4y ago
  Heh, I remember attending trade shows in a time when X.400 and X.500 were all the rage. 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.)

kuon 4y ago

IPX worked very well for LAN games, it required no configuration. Compared to how difficult it is to play together now (steam friends. xbox...), it was much better. Of course it had drawbacks, but for that it was great.

jandrese 4y ago
That's just LAN play dying off in favor of (routeable) Internet play. If developers wanted to they could add IP LAN play to games, but there's just not enough demand.
- bombcar 4y ago
  The assumption is that if you're on an IP network, you already have addresses, etc (because you're routable to the internet). 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.
  - jandrese 4y ago
    You could also do it over multicast. 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.
    - bombcar 4y ago
      Yeah, anything actually doing it today will do something like multicast/bonjour and then do direct links. Though I have seen games that apparently use an internet service to coordinate direct links ...
      - eklavya 4y ago
        I seem to have never had a reliable and working mDNS on any OS. Would not recommend.
        MobiusHorizons 4y ago
        Is it possible your network disables multicast? 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.
        bombcar 4y ago
        Only problem I've ever observed is not letting it "calm down" as some mDNS implementations (maybe no more) used to try to cache/answer for other machines.
    - WorldMaker 4y ago
      That's all IPX/SPX was was link local multicast. I see all the "no configuration" required love for it in surrounding comments, but I suppose few remember the failure states when it didn't work as expected, including drowning an entire switch (or worse token ring) in multicast noise. I know I hit IPX/SPX config hell a few times over the years in home LAN gaming, and I can't believe I was that alone in it, so I'm assuming the nostalgia goggles are in play in some of these "it just worked" memories. > 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.
- contravariant 4y ago
  I can see why it died off. There were preciously few ways to have LAN play over a distance without weird connection issues. At some point I recall that Hamachi did work fairly well, but that meant you still had to rely on a third party in the end. 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.
  - Thlom 4y ago
    I remember back in the 90’s and early 00’s my cousin and his neighbors had a neighborhood LAN going. They had stretched I believe Ethernet cables across the street and from house to house. It might actually have been coax cables in a ring network of some sorts. Anyway. They had an IRC server going and shared files and played games. Seemed like good times.
- Karrot_Kream 4y ago
  It all comes down to NAT and dynamic IPs. Let's say Anu and Bob and Chen are trying to play a game. Anu runs the server and wants Bob and Chen to connect to her server. Anu follows some guide to get her IP and gives it to the others, but it's not routable publicly because of some form of NAT, or her IP is dynamic and changes and so packets become unroutable to Anu. Now all Anu needs to do is press "Start Game", where a remote server either hosts the game metadata or just acts as a glorified STUN/TURN server and the remote server gets a friendly name that Bob and Chen can use to connect to the game. 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.
- jbverschoor 4y ago
  Bonjour / mDNS / broadcasting doesn’t play nice on all routers. 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
Wohlf 4y ago
TCP LAN games were also easy to set up.
bluedino 4y ago
Way back when I first started working for a small networking outfit, we were informally split into 'Team Red' and 'Team Blue'. Everyone agreed that Novell was on the way out, and the younger guys with their MCSE's made up most of Team Blue. I had un-officially started 'Team Yellow' and was sticking Linux boxes in when I could. 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.
EamonnMR 4y ago
The difference between then and now is less protocol and more pervasive authentication.

didgetmaster 4y ago

I worked at Novell in the late 80s, early 90s. In the LAN world, IPX/SPX worked pretty well but it was certainly steamrolled by TCP/IP. 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.

zwieback 4y ago
Yup, I worked on a PC-to-Mac networking server product and we tested with TokenRing as well. Massive hardware but good performance. We also had a lot of coax wire in those days. To this day I still look down on twisted pair and the garbage Ethernet connectors we use now.
- anyfoo 4y ago
  Electrically, there's not much reason to look down on Twisted Pair. It is an ingenuous way to achieve what coax does as an unbalanced transmission line with, well, a twisted pair of wires that form a balanced (differential) transmission line. You might need to add some shielding in some situations, but that's just a piece of foil. 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.
  - cesarb 4y ago
    > Electrically, there's not much reason to look down on Twisted Pair. 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.

rjsw 4y ago

I have AppleTalk compiled into the kernel on the machine I'm using to type this, have also done some work on adding CHAOSNET to it.

pavon 4y ago

I'm glad IP took over everything, but I wish that TCP hadn't become practically mandatory. There are some other really useful transport layer protocols, like SCTP that are great to use on a LAN, but good luck getting them to work on the internet. The only way to do anything other than TCP is to layer/tunnel it over UDP, and even that has less support than TCP.

rjsw 4y ago
I'm part way through adding support for SCTP to the NetBSD firewall. Have done the basic filtering stuff, still working on doing NAT for it.
jeffparsons 4y ago
Fortunately that era is coming to an end. With QUIC (layered on top of UDP) being the basis for HTTP/3, very few networks will outright block QUIC traffic as many have done with UDP. 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.
- Karrot_Kream 4y ago
  I hope so. QUIC gives us so much of what SCTP should have given us. But we'll see how the middleboxes deal with things. If they want to block QUIC, like they block UDP, they can.
- dicknuckle 4y ago
  Wait, who blocks UDP? I've worked many different angles of the technology world and never heard of anyone blocking something so ubiquitous.
  - obscurette 4y ago
    Many network owners block UDP at borders. It helps a lot in case of amplification DDOS attacks.
  - p_l 4y ago

johngalt 4y ago

To this day I think ATM was an interesting approach. Virtual circuit switching with quality of service capabilities designed into the protocol. If nothing else, it is a great example of a complex and optimized protocol losing vs a ubiquitous and simple protocol.

kstrauser 4y ago
It was "interesting", all right. For instance, its packet payloads were 48 bytes long. Why? Because 32 was too short for large streams (with a 5 byte header representing a 13% overhead), and 64 was "too long" (!!!) for real-time voice connections. 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.
- Spooky23 4y ago
  The hardware was garbage too. I ripped that crap out of a place that went all in with some IBM/Lucent ATM solution. 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.

msla 4y ago

Not to mention the Real Person All Grown Up Protocol Stack, OSI, which of course was going to displace this ARPANET childishness with protocols like the X.212 data link layer that, like all data link layer protocols, provides checksumming and resending and distinguishes between connection-oriented and connectionless communication, plus X.400 email which, naturally, uses the simple, comprehensible, easy-to-implement X.500 directory service, for email addressing inherently tied to your employer and physical address. 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. https://www.rfc-editor.org/rfc/rfc3439 https://www.rfc-editor.org/rfc/rfc3439

anyfoo 4y ago
Heh, I remember attending trade shows in a time when X.400 and X.500 were all the rage. 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.)