B.net Index Server 2 <8K · 4K>

All traffic, including passwords, is sent in plaintext (or trivial XOR "encryption"). Anyone on your network can sniff credentials. Do not reuse passwords on these servers.

Understanding the packet flow demystifies many connection issues. Legacy Blizzard games used a three-step handshake:

Crucially, the Index Server 2 did not act as a relay. Once the client received the host’s IP, all further communication (joining, chatting in-game, combat logic) occurred directly between peers. This architecture is why classic Battle.net games were so vulnerable to "IP pulling"—a direct consequence of Index Server 2’s design.

Because IS2 is no longer sold or supported, this section describes the typical environment for version 2.x: B.net Index Server 2

The command line is still there for purists. But BIS2 ships with a new web-based dashboard called The Lens. It’s minimal, dark-themed, and blindingly fast. Type a query. Get instant typeahead suggestions from the network. Filter by node trust score, file age, or even geographic proximity (if nodes opt into location hints).

One beta tester, a sysop for a retro Macintosh archive, told me: “I used to maintain my index manually. BIS2 does it live. I added a folder of old HyperCard stacks, and within 30 seconds, three people had downloaded them. That never happened before.”

Blizzard has shown no intent to resurrect the classic Index Server infrastructure. However, the open-source community is thriving. Projects such as: All traffic, including passwords, is sent in plaintext

...all rely on the original B.net Index Server 2 logic. As of 2026, the most active implementation is found in PVPGN 1.8.5+, which includes a fully compliant Index Server 2 with IPv6 support and optional TLS encryption (a dramatic improvement over the original).

For enthusiasts: running your own Index Server 2 is surprisingly accessible. With a Linux VPS, 256MB of RAM, and PVPGN compiled with --enable-war3 and --enable-d2cs, you can host game listings for a hundred concurrent players.

The B.net Index Server 2 was not a single machine but a specific service role within Blizzard’s server cluster. It worked in tandem with the Chat Server (which handled the lobby "channels") and the Game Server. Crucially, the Index Server 2 did not act as a relay

1. The Distributed Directory Unlike a modern centralized cloud database, early Battle.net relied on a sharded architecture. Index Server 2 instances were responsible for specific geographic regions or server "gateways" (such as USWest, USEast, Asia, and Europe). When a player logged in, the client communicated with the Index Server to download the list of active games. This prevented a single point of failure; if the USWest Index Server went down, Europe remained unaffected.

2. Latency Management The "Index 2" architecture introduced more sophisticated latency filtering. In the days of dial-up, finding a server with a low ping was critical. The Index Server facilitated the "ping" display next to game names by either relaying ICMP data or calculating the hop distance between the host and the client, allowing players to make informed decisions before joining a laggy session.

3. Binary Protocols To save bandwidth—a precious commodity in the era of 56k modems—Index Server 2 utilized highly optimized binary protocols. It didn't send heavy HTML or text data; it sent compact packets containing only the essential hex data required to render the game list. This efficiency allowed the server to transmit thousands of game listings to a client in a fraction of a second.