Oyun Auth Server: Login ve Game Server Ayrımı

Bir online oyunun ölçeklenir bir mimariye geçtiği ilk an genellikle şudur: oyun auth server ile oyun dünyasını yöneten sunucunun ayrılması. Tek bir süreç hem giriş yapan oyuncuların şifresini doğrulayıp hem de aynı anda binlerce karakterin hareketini, savaşını ve envanterini işlemeye çalıştığında, en küçük bir trafik dalgalanması bütün dünyayı düşürür. Çözüm, kimlik doğrulamayı ayrı bir login server'a, oyun mantığını ise bir veya birden çok game server'a taşımaktır.

Auth server tam olarak ne yapar

Auth server (login server), oyuncunun kimliğini doğrulayan ve ona bir oyun dünyasına girme yetkisi veren kapı bekçisidir. Tipik bir akışta görevleri şunlardır:

• Kimlik doğrulama: kullanıcı adı ve şifreyi (hash'lenmiş hâliyle) veritabanından kontrol eder.
• Hesap durumu: ban, ödeme/abonelik, yaş kısıtı, IP/donanım kara listesi gibi kontrolleri yapar.
• Sunucu listesi: oyuncuya hangi dünyaların (realm/kanal) açık ve dolu olduğunu gösterir.
• Oturum jetonu üretimi: başarılı girişte tek kullanımlık, kısa ömürlü bir session token üretir ve game server'a aktarır.

Burada kritik nokta: auth server giriş işini bitirir bitirmez devreden çıkar. Oyuncu artık oyun dünyasındayken auth server ile konuşmaz; tüm gerçek zamanlı trafik game server'a gider.

Neden ayırmak gerekir: tek sunucunun sorunları

Login ve oyun mantığını aynı süreçte tutmak ilk başta basit görünür, ama birkaç temel sorunu beraberinde getirir:

• Yük profili çok farklı: login işlemi kısa ama yoğun CPU (şifre hash doğrulama) ve veritabanı ister; oyun döngüsü ise sürekli, düşük gecikmeli ağ trafiği ister. Bunları aynı thread havuzuna koymak, bir akşam giriş dalgasının tüm oyuncularda lag yaratması demektir.
• Güvenlik yüzeyi: şifre ve hesap verisi en hassas varlıktır. Onu oyun mantığından ayrı, daha sıkı güvenlik kurallarına sahip ayrı bir süreçte tutmak saldırı yüzeyini küçültür.
• Tek hata noktası: game server çökerse sadece o dünya etkilenir; ama her şey tek süreçteyse bir crash bütün oyuncuları, hatta giriş yapamayanları da kapı dışında bırakır.
• Ölçeklenme: tek bir auth server, arkasında onlarca game server'ı besleyebilir. Oyuncu sayısı arttığında game server eklersiniz, login altyapısını çoğaltmanız gerekmez.

Token tabanlı el sıkışma (handshake)

Login ve game server'ın güvenli konuşması bir oturum jetonu üzerinden yürür. Klasik akış şöyledir: oyuncu auth server'a giriş yapar, auth server kısa ömürlü bir token üretip hem oyuncuya hem (paylaşılan DB ya da iç ağ üzerinden) game server'a verir, oyuncu bu token ile game server'a bağlanır, game server token'ı doğrular.

// Auth server: başarılı girişte token üret
Token issueSession(uint32_t accountId) {
    Token t;
    t.value   = randomBytes(32);        // tahmin edilemez
    t.account = accountId;
    t.expires = now() + seconds(30);    // kısa ömür
    t.used    = false;
    db.storeSession(t);                 // paylaşılan tabloya yaz
    return t;
}

// Game server: oyuncu bağlanınca token'ı doğrula
bool verifySession(const std::string& token, uint32_t accountId) {
    auto s = db.loadSession(token);
    if (!s || s.used || s.account != accountId) return false;
    if (now() > s.expires) return false;   // süresi geçmiş
    db.markUsed(token);                     // tek kullanımlık
    return true;
}

Püf noktaları: token tahmin edilemez (kriptografik rastgele), kısa ömürlü (saniyeler) ve tek kullanımlık olmalı. Böylece ele geçirilse bile pencere çok dar olur. Şifre game server'a hiçbir zaman gitmez; game server kimseyle parola konuşmaz, yalnızca jeton doğrular.

Veritabanı ve paylaşılan durum

İki sunucu nasıl haberleşir? En yaygın yaklaşım paylaşılan bir veritabanıdır (genelde MySQL): hesaplar, oturumlar ve karakter verileri merkezi tabloda durur. Auth server hesap tablosunu okur ve oturum tablosuna yazar; game server oturum tablosunu doğrular ve karakter/oyun verilerini yönetir.

Daha büyük kurulumlarda araya bir Redis gibi hızlı bellek deposu konur: kısa ömürlü oturum jetonları kalıcı diske yazmaya değmeyecek kadar geçicidir; bunları RAM'de tutmak hem hızlı hem de otomatik süre dolumu (TTL) ile temizliği kolaydır. Bazı mimariler doğrudan jeton paylaşmak yerine iç ağda bir RPC/mesaj kanalı kullanır: auth server "şu account şu token'la geliyor" diye game server'a doğrudan haber verir.

Hangi yöntem olursa olsun değişmeyen kural: iki sunucu arasındaki kanal iç ağda ve güvenli olmalı. Token doğrulaması ya da RPC trafiği internete açık olmamalı; oyuncu istemcisi bu kanala asla erişmemeli.

Çok dünyalı (multi-realm) yapıya geçiş

Asıl güç, bir login server'ın arkasına birden çok game server koyabilmenizdir. Oyuncu giriş yapar, auth server ona bir dünya listesi gösterir, oyuncu birini seçer ve auth server o dünyanın game server'ına yönlendiren token'ı üretir.

• Yatay ölçeklenme: popülerlik arttıkça yeni dünyalar (kanallar) eklersiniz; her biri ayrı bir game server süreci.
• Yük dengeleme: auth server dolu dünyaları gizleyebilir ya da yeni oyuncuları daha boş kanallara yönlendirebilir.
• Bakım kolaylığı: bir dünyayı güncellemek için sadece o game server'ı kapatırsınız; oyuncular diğer dünyalarda oynamaya devam eder, login hizmeti hiç kesilmez.

Metin2, WoW türevleri ve birçok MMO altyapısı tam da bu modeli kullanır: tek bir auth/account katmanı, arkasında channel veya realm olarak ayrılmış oyun çekirdekleri.

Sık Sorulan Sorular

Küçük bir oyun için auth server'ı ayırmaya değer mi?

İlk günden ayrı süreç şart değildir, ama mantığı baştan ayırmak çok değerlidir. Kimlik doğrulama kodunu oyun döngüsünden bağımsız bir modül olarak yazarsanız, oyuncu sayısı artınca onu ayrı bir sürece taşımak basit bir refactor olur; iç içe geçmişse pahalı bir yeniden yazım olur.

Token yerine her pakette şifre göndermek olmaz mı?

Olmaz. Şifreyi tekrar tekrar ağda taşımak hem güvenlik riskidir hem de her doğrulamada pahalı bir hash hesabı demektir. Kısa ömürlü tek kullanımlık token, hem güvenli hem de doğrulaması ucuzdur; şifre yalnızca bir kez, sadece auth server'da işlenir.

Auth server çökerse oyundakiler atılır mı?

Hayır, doğru tasarımda atılmazlar. Auth server yalnızca girişte devrededir; oyundaki oyuncular game server'a bağlıdır. Auth server düşerse sadece yeni girişler durur, mevcut oturumlar etkilenmez — bu da ayrımın en büyük dayanıklılık avantajıdır.

Oyununuz için sağlam bir auth/login mimarisi mi kurmak istiyorsunuz? Login server ayrımı, token tabanlı oturum yönetimi ve çok dünyalı ölçeklenme konusunda yardıma ihtiyacınız varsa benimle iletişime geçin.