17

In 1997, there was this service called Wireplay in the UK.

Instead of using the Internet, you used it by directly phoning their servers with your modem from your PC, and the point of this was that it was "much faster and more reliable" than an Internet connection would be which talks to their server with the IP.

But why is this? If they still use the same modem, and the same telephone wires, why is "not using the Internet" faster and more reliable for playing (supported) games "online"? With a dial-up ISP, you would call a local telephone number, so surely that's the same thing? In fact, it sounds to me that if anything, this "Wireplay" technology would be slower unless you were lucky enough to happen to live close to their server(s).

How can this be explained? Why was this "non-Internet" Wireplay technology (which intrigues me) faster and more reliable than the Internet when you used the same infrastructure and hardware?

Improve this question
3
  • 6
    This is a guess since I'm not familiar with the service - but if everyone's dialed up to the same physical server over a fixed wire, rather than connecting to "the internet" possibly several hops away, the protocol overheads and latency may be significantly lower.
    – another-dave
    Feb 2, 2022 at 0:04
  • 1
    TCP/IP overhead I suppose. If my memory is ok it was around 10% bandwidth that is lost to IP packeting (IP header is 64 byte, add 10 for PPP and you have 74 bytes of not very useful data on your modem link if you're point to point anyway for rach packet).
    – Patrick Schlüter
    Oct 19 at 13:10
  • It was all down to reducing / removing packet overhead, particularly as games tended to exchange very small packets eg: both the Build engine [Duke Nukem 3D] and Doom sent packets well under 100 bytes long, often under 10 bytes. At this payload size, every byte you can save in the headers is worth it, hence Wireplay creating it's own network protocol to do this.
    – Phil Ashby
    Oct 21 at 12:02

4 Answers 4

Reset to default
27

This article from British Telecom says Wireplay launched in June 1996 as a way to host multiplayer games over a closed dial-up network. This is why it was "non-Internet": All players were directly connected to BT's in-house hosts, and not transmitting packets over the routed public Internet.

The (purported) lag of 105 milliseconds appears to be due to several technical factors:

  1. Wireplay required "the Intel Pentium 486 processor [???]"
  2. Subscribers had to use a BT phone line and a high-speed modem
  3. All players were connected to the same server hosted by BT via their own internal mesh

By controlling the hardware and connectivity from PC to server, BT was in a better position not to oversubscribe resources and reduce delays and latency. Teleconferencing companies in the 1990s did much the same by requiring their systems be connected via the then-promising ISDN.

The downside of this approach is that games had to be Wireplay-compatible via licensed technology. I suspect (without evidence) this technology merely ensured only paying subscribers used the service, but it's possible it had other roles, such as monitoring and reporting bandwidth issues back to BT's servers.

Wireplay also supported features treated as common today, such as matchmaking, lobbies, clubs/teams, and so on. It hosted and promoted major comps, such as the Quakedelica tournament in 1998, now infamous due to the exhibition deathmatch between Thresh (US) and Billox (UK). In this sense, Wireplay was an early force in the realm of e-sports.

After being sold off and suffering financially, Wireplay was shut down in 2014.

Improve this answer
4
  • 5
    The modern buzzword term for this approach would be Edge Computing
    – tofro
    Feb 2, 2022 at 9:00
  • 2
    I last remember hearing about Wireplay sometime in ~1999 so I'm surprised to hear they lasted until 2014 - I'd like to know what were they doing for those 15 years after they ceased being relevant.
    – Dai
    Feb 5, 2022 at 20:25
  • In practice you didn't need a BT line to access it. Also I'm not sure that games had to do anything special to become Wireplay-compatible - though maybe that's referring to in-game server browser support. (I used to play Quakeworld via Wireplay back in the late '90s - we would connect to servers by bringing down the console and using /connect)
    – Aaron F
    Jun 12 at 21:47
  • "The downside of this approach is that games had to be Wireplay-compatible via licensed technology." @jim-nelson this wasn't true for all games, as Wireplay was able to support both the Build engine (Duke3D) and idTech1 (Doom) engine and all IPX based games without modification to the game itself, by emulating the network below them. That said, we encouraged developers to use the API as they had better integration with the service (matchmaking, chat, etc.) in-game.
    – Phil Ashby
    Oct 21 at 12:07
21

I was the architect for BT Wireplay from 1995-2000 and am one of the co-authors of the patented network protocol. Essentially @hobbs answer is correct, in that 90s Internet links were often highly contended and suffered from large latency variations (jitter) which games of that time did not tolerate, having been designed and tested only on LANs. We thus built our own access network directly in to the server farm, created a more efficient network protocol and optimised modem settings to reduce jitter, sometimes at the expense of some latency, as jitter is far more disruptive.

I wrote a blog article with some history and technical info here: https://dev.to/phlash/wireplay-creating-the-first-online-gaming-platform-in-the-uk-1k3i for those interested in how it came to be.

Improve this answer
2
  • It's always fun to read stories like this, and the patent it links to is a good resource. Thanks for joining in. I take it the Ascend MAX4000 is quite a similar device to the Livingston (later Lucent) PortMaster 3?
    – hobbs
    Oct 18 at 23:30
  • @hobbs, indeed the Ascend MAX4000 product is very similar to the Livingstone Portmaster - terminating both ISDN and analogue connections to Ethernet backhaul. We abused ours (and had to have custom firmware!) such that it made direct connection to the network server over TCP, and folks couldn't explore our internet network from it!
    – Phil Ashby
    Oct 21 at 11:36
19

If they still use the same modem, and the same telephone wires, why is "not using the Internet" faster and more reliable for playing (supported) games "online"?

The internet is a random collection of other people's networks duct-taped end-to-end and carrying other people's traffic. Latency can vary dramatically and unpredictably depending on the amount of traffic going over those links — perhaps one player's ISP doesn't have enough backhaul for all of its customers, or perhaps one link on the path between ISP A and ISP B is also on the path between two other networks who can largely monopolize it because they're using something much faster than dialup.

Telephone lines, on the other hand, have very predictable latency (necessary for voice to actually work properly) and while a longer line does have a higher latency, that's dominated more by the speed of light than anything else; packets don't get queued at intermediate hops. And the UK isn't a terribly big place — only around 5 light-milliseconds from one end to the other.

According to the WirePlay white paper, not only did they terminate all of their phone calls digitally at a single point of presence (avoiding any internet links), they also used a custom protocol (rather than IP over PPP) over the phone lines, which had lower overhead — since only one machine can be dialed in on a given phone call, and a machine can only be playing one game at a time, there's no real question of where a packet is coming from (the subscriber who dialed in) or where it's going to (the server for the game they joined, or the lobby they're in), and there are no intermediate routers, so a lot of header information is entirely unnecessary. At a 28,800 bps line rate, every four bytes or so you shave off of a packet takes 1ms off of the time to send it one way, and 2ms off of the round-trip latency!

Improve this answer
9
  • That's an interesting aspect: ~4bytes=1ms. But it is not bandwidth that matters for games, instead latency is the key. Sending less bytes does not affect latency.
    – Dercsár
    Oct 19 at 9:40
  • @Dercsár V34 (28.8 or 33.6K) modems had lousy latencies when compared to ISDN for example as there were several OSI layers (HDLC notably) that were necessary to make the transmission reliable. If you add PPP, IP, TCP or UDP on top of it, it will not make things better.
    – Patrick Schlüter
    Oct 19 at 13:21
  • @PatrickSchlüter: Could such modems be usefully employed with their "hardware" error detection and retransmission logic disabled if software logic handled such things, or would the relationship between audio defects on the line and serial port bits be sufficiently "scrambled" to make that unworkable?
    – supercat
    Oct 19 at 14:43
  • @Dercsár if you assume the whole packet has to be received before it's processed (which is usually true), then sending less bytes per packet absolutely does affect latency.
    – hobbs
    Oct 19 at 18:22
  • @supercar afaicr it was not possible to disable the error detection and retransmission logic in these advanced protocols. The advanced modulations (QAM, QSPK) used made it impraticable to remove the error correction. We should not forget that more than 2400 baud was physically not possible on POTS. If you wanted to transmit more than 2400 bps you had to encode more than 1 bit for each modulation. With 33600 bps it was considered the hard physical limit of transmission. That's why the 56K modems were received with skepticism at first as they seemed to violate Shannon's law.
    – Patrick Schlüter
    Oct 20 at 9:11
1

If they still use the same modem, and the same telephone wires, why is "not using the Internet" faster and more reliable

I can't speak to the "reliable" part, but the second thing I noticed after getting dial-up Internet (using PPP) was that downloading files was significantly slower than dialing into a BBS: above and beyond the multiple hops mentioned in @hobbs' answer, the PPP, IP and TCP proocols add a noticeable amount of overhead to each packet being transferred

Improve this answer
1
  • 2
    A related issue is that once an internet protocol starts sending a packet, over a connection, it won't be able to send anything else over that connection until the packet has been fully transmitted. At 28,800 bits/second, sending sending a 576-byte packet would take about 200ms. If a program wants to send a packet, even if it manages to have that packet be the next one in the queue, it may have to wait 200ms before the system could even start transmitting its packet. Similar issues add another 200ms on the remote end.
    – supercat
    May 10 at 20:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .