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?

  • 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. Feb 2, 2022 at 0:04

3 Answers 3


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.

  • 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

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!


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

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