Many games played over the Internet today use a client-server model, where the server has a full copy of the game state, and distributes appropriate pieces to the connected clients. Due to the technology available in 1994, XBAND couldn't work this way.
When the user wanted to play a game online, the modem called the server through a local dial-up point-of-presence, and requested a match for the currently-installed cartridge. The server either told the modem to wait for a connection, at which point it would sit and wait for the phone to ring, or told it to dial the other player's phone number. Once connected, the game consoles communicated directly, removing client-server communication latency from the equation.
The games ran in lockstep on each console. The cartridges had to be exactly the same, as any difference in logic could throw the systems out of sync. Once (In a couple of cases, publishers quietly released an updated version of a cartridge.) All game state, including the random number generator seed, had to be synchronized at the start. Once game startedplay began, the consoles simply exchanged controller reads. At 1200bps2400bps, there was just enough time to send a bitmap of currently-pressed buttons and some ECC/EDC bitserror-correction redundancy at 30 fps.
While 2400bpsfaster modems were inexpensiveavailable at thatthe time, a 1200bps modem was used instead. Itthe slower modems were less expensive, had sufficient throughput, and itshad better latency characteristics were better. Features like data compression and error correction were disabled to avoid introducing additional latency.
An attempt to reduce the latency even further was attempted but never shipped. By changing video modes on the Genesis, the television's VSYNC phase could be altered, potentially allowing two independent televisions to be brought (temporarily) into sync with each other.
An hour-long documentary on Catapult and XBAND can be found on youtube.