Metin2 channel yapısı: core dağılımı ve port mantığı

Bir Metin2 sunucusunu ilk kez kurarken en çok kafa karıştıran konu Metin2 channel yapısıdır: oyuncunun gördüğü "Kanal 1, Kanal 2, Kanal 3" listesi aslında arka planda kaç tane process ile karşılanıyor, hangi harita hangi core üzerinde çalışıyor ve portlar nasıl dağıtılıyor? Bu yazıda kanal ile core arasındaki farkı, auth ve db sunucularının rolünü ve klasik bir çok kanallı sunucunun port mantığını pratik örneklerle açıklıyorum.

Kanal (channel) ile core arasındaki fark

Çoğu kişi "kanal" ile "core"u aynı şey sanır, ama bunlar farklı katmanlardır. Channel, oyuncunun seçim ekranında gördüğü mantıksal bir bölümdür: yükü dağıtmak için aynı dünyanın birden fazla kopyası gibi düşünebilirsin. Her kanalda haritaların tamamı (köyler, av alanları, zindanlar) bulunur.

Bir kanalın içindeki core ise haritaların bir alt kümesini çalıştıran ayrı bir process'tir. Tek bir game process'i tüm haritaları taşımaz; haritalar core'lar arasında paylaştırılır. Örneğin bir kanalda dört core varsa, başlangıç köyleri core1'de, orta seviye av alanları core2'de, üst seviye haritalar ve zindanlar core3 ile core4'te çalışabilir. Oyuncu haritalar arası geçtiğinde core'lar arası bir devir-teslim olur ama oyuncu bunu fark etmez.

Auth ve db sunucusunun rolü

Çok kanallı bir kurulumda iki merkezi parça vardır:

• auth: Hesap girişini doğrulayan sunucu. İstemci önce buraya bağlanır, kullanıcı adı/şifre kontrol edilir ve oturum bilgisi üretilir. Auth genellikle ayrı bir port üzerinde, kendi CONFIG dosyasıyla çalışan özel bir game process'idir.
• db: Tüm core'ların ortak bağlandığı veritabanı önbellek sunucusudur. Karakter, envanter, lonca gibi veriler MySQL'de tutulur ama core'lar doğrudan değil, db process'i üzerinden konuşur. Bu sayede veriler senkron kalır ve oyuncu bir core'dan diğerine geçerken karakteri tutarlı olur.

Yani bağlantı zinciri şöyledir: istemci → auth (giriş) → seçilen kanalın core'u → ve tüm core'lar arka planda → db → MySQL. Auth ve db sunucusu sadece birer adet çalışır; çoğaltılan kısım core'lardır.

Port mantığı ve CONFIG

Her core, kendi klasöründeki bir CONFIG dosyasıyla başlatılır ve burada hangi porttan dinleyeceği, hangi kanala ait olduğu ve core'lar arası iletişim için kullanacağı P2P portu tanımlanır. Tutarlı bir port şeması işleri çok kolaylaştırır. Yaygın bir kural şöyledir:

• Kanal 1 core'ları: 13001, 13002, 13003, 13004
• Kanal 2 core'ları: 13011, 13012, 13013, 13014
• Kanal 3 core'ları: 13021, 13022, 13023, 13024
• auth: 11002 gibi ayrı bir port — db: 15000 gibi ayrı bir port

Önemli olan şemanın çakışmaması ve mantıklı olmasıdır; rakamların kendisi keyfîdir. Tipik bir core CONFIG dosyası kabaca şöyle görünür:

HOSTNAME: channel1
CHANNEL: 1
BIND_IP: 0.0.0.0
PORT: 13001
P2P_PORT: 13991
PLAYER_SQL: localhost player root parola
COMMON_SQL: localhost common root parola
LOG_SQL: localhost log root parola
TABLEPOSTFIX: _
DB_ADDR: 127.0.0.1
DB_PORT: 15000

Burada PORT oyuncunun bağlandığı oyun portu, P2P_PORT ise aynı kanaldaki diğer core'larla konuşmak için kullanılan porttur. DB_ADDR ve DB_PORT ise core'un db process'ine nasıl ulaşacağını söyler. Auth process'inin CONFIG'inde ek olarak onun bir kimlik doğrulama sunucusu olduğunu belirten ayar bulunur ve genellikle özel bir kanal numarasıyla (örneğin 99) çalıştırılır.

Haritaların core'lara dağıtılması

Bir core'un hangi haritaları yükleyeceği, sunucu tarafındaki harita listesiyle belirlenir. Her core sadece kendisine atanan harita klasörlerini hafızaya alır; atanmamış haritalar o core için "uzak" kabul edilir. Oyuncu, bir core'da bulunmayan bir haritaya yürüdüğünde, P2P bağlantısı üzerinden o haritayı barındıran core'a aktarılır. Dağıtımı yaparken iki şeye dikkat etmek gerekir:

• Yük dengesi: En kalabalık av alanlarını tek bir core'a yığma; oyuncu yoğunluğunu core'lar arasında dağıt.
• Tutarlılık: Aynı haritayı iki farklı core'a atama. Her harita tek bir core'da çalışmalıdır, yoksa devir-teslim hatalı olur.

Pratikte başlangıç köyleri ve sürekli kalabalık olan ana meydanlar genelde ayrı bir core'a alınır, böylece bir av alanındaki yoğunluk şehir performansını etkilemez.

Başlatma sırası ve süreç yönetimi

Sunucu süreçlerinin başlatma sırası önemlidir, çünkü core'lar açılırken db'ye bağlanmaya çalışır. Doğru sıra şöyledir:

1. MySQL servisi (veritabanı) çalışır durumda olmalı.
2. db process'i başlatılır.
3. auth process'i başlatılır.
4. Kanalların core'ları sırayla başlatılır.

Süreçleri elle takip etmek yorucu olduğu için çoğu yönetici basit bir başlatma scripti kullanır. Örnek bir kontrol scripti yaklaşımı:

#!/bin/sh
# her core kendi klasöründen baslatilir
for dir in db auth ch1_core1 ch1_core2 ch1_core3 ch1_core4; do
    cd "/usr/metin2/$dir" && ./game &
done

Bir core çökerse genellikle bir çekirdek dökümü (core dosyası) bırakır; bunu gdb ile inceleyerek hangi fonksiyonda patladığını görebilirsin. Bu yüzden core'ları screen ya da bir servis yöneticisi altında çalıştırıp logları ayrı tutmak, sorun çıktığında hayat kurtarır.

Kaç core gerekir?

Bunun sabit bir cevabı yok; oyuncu sayısına ve donanıma bağlıdır. Her game process'i tek çekirdekli (single-thread ağırlıklı) çalıştığı için, çok çekirdekli bir sunucuda core sayısını artırmak CPU'yu daha iyi kullanmanı sağlar. Genel bir başlangıç noktası: küçük bir sunucu için kanal başına 2 core yeterliyken, kalabalık bir sunucuda kanal başına 4 core ve birden fazla kanal mantıklıdır. Önce 1 kanal + 2 core ile başla, oyuncu arttıkça kanal ve core ekle.

Sık Sorulan Sorular

Kanal sayısını sonradan artırabilir miyim?

Evet. Yeni kanal eklemek, o kanalın core'ları için CONFIG dosyaları oluşturup çakışmayan portlar atamak ve istemcinin gördüğü sunucu listesini güncellemekten ibarettir. Veritabanı ortak kaldığı için karakterler tüm kanallarda aynıdır.

Oyuncular hangi kanalda olduklarını seçebilir mi?

Evet, oyuncu giriş yaptıktan sonra kanal listesinden seçim yapar. Kanallar aynı dünyayı paylaştığı için karakter ve eşyalar değişmez; sadece o anda hangi sunucu kopyasında oynadığın değişir. Bu, kalabalık saatlerde yükü dağıtmanın temel yoludur.

auth ve db'yi tek process'te birleştirebilir miyim?

Mimari olarak ayrı tutmak doğrudur ve önerilir. db tüm core'ların ortak veri katmanıdır, auth ise yalnızca girişle ilgilenir; ikisini ayrı tutmak hem güvenlik hem de hata ayıklama açısından çok daha yönetilebilir bir yapı sağlar.

Çok kanallı bir Metin2 sunucusunun mimarisini sağlam kurmak ister misin? Core dağılımı, port şeması ve kararlı bir başlatma düzeni için benimle iletişime geç — kurulumunu birlikte planlayalım.