Bir soket sunucusu ve oyun sunucusu ayrı işlemler olmalı mı?

Basit bir standart istemci / sunucu oyunu varsayalım. Sunucu için, istemcilerden gelen bağlantıları ve mesajları dinleyen ve verileri yerel soketler veya stdin aracılığıyla gerçek oyun sunucusunu çalıştıran başka bir işleme gönderen ayrı bir işleme sahip olmaya değer mi?

Diğer seçenek, her iki şeyin de tek bir işlemde yapılmasıdır. Gelen iletileri sıraya koymak ve bunları doğru sırada yürütmek, durma sorunu olmamalıdır.

Ben iki "faaliyetleri" ayırmak için ekstra kaynaklar aslında buna değer olup olmadığını merak ediyorum. Nasıl karar vermeliyim? Artılarını / eksilerini duymak istiyorum.

Bir API tasarım perspektifinden bakıldığında, birden fazla ayrı iletişim programı mı yoksa sadece bir tane mi yapılacağına karar verirken, soru şudur: her program diğerleri olmadan anlamlı bir şekilde çalışabilir mi? Cevap, projenize ve tercihlerinize göre değişecektir.

Eğer yapamazlarsa, düşünmeye değmez. Açıkçası o kadar fazla bağlantı kuruyorlar ki, gerçekten ayrı süreçler değiller.

Eğer yapabilirlerse ve kendinizi gelecekte değiştirmek için farklı bileşenlere düşmek istediğinizi görebilirsiniz, o zaman OS tarafından sağlanan bir süreç soyutlama yardımcı olabilir.

Ne kadar yardımcı olur, yine de teknoloji yığınınızın geri kalanına bağlıdır. Örneğin Erlang, işleri zaten süreçler olarak modellemektedir, bu yüzden onu OS işlemlerine bölmekten kavramsal bir fayda elde edemezsiniz. Sunucunun bu bölümlerini farklı bir dilde yeniden yazmayı düşünmüyorsanız. Bir C ++ programının dahili bileşenleri genellikle daha sıkı bir şekilde birleştirilir ve bu nedenle değiştirilmeleri daha zor olur, bu nedenle bunları farklı işletim sistemi işlemlerine bölmek, bu tür yeniden düzenlemeleri öngörürseniz daha sonra çalışmanızı kurtarabilir.

istemcilerden gelen bağlantıları ve mesajları dinleyen ve verileri yerel soketler veya stdin aracılığıyla gerçek oyun sunucusunu çalıştıran başka bir işleme gönderen ayrı bir işlem olması faydalı mıdır?

Değerli olup olmadığını cevaplamak için önce kendinize, özel bir kuyruk hizmeti ekleyerek çözmeye çalıştığınız sorunun ne olduğunu sormanız gerekiyordu. Eğer bu sorunu çözerse, o zaman değerlidir; eğer bir problemi çözmezse veya başlamak için bir probleminiz yoksa, muhtemelen değil.

Bazı sunucuların çok katmanlı bir mimari kullanmasının bazı nedenlerini görelim:

1. Yük dengeleme - iş yükünüzü birden çok çalışan makineye yaymak istiyorsanız yük dengeleme mantıklıdır. Programınızın aynı makinede birden fazla eşzamanlı işçi işlemi gerçekleştirerek çözmek istediğiniz darboğazlar varsa, o zaman darboğazı gerçekten çözmek uzun vadede en iyisidir, ancak kısa vadeli bir çözüm olarak, yumurtlama işçi süreçleri pratik olabilir.
2. Ayrıcalık ayırma - Belki de oyun sunucunuza otomatik olarak erişim sağlamak için sohbet sunucunuza bir güvenlik ihlali istemezsiniz ya da tam tersi. Oyun sunucunuz oyun içi sohbet sunucunuzdan ayrıysa, oyun sunucunuzu ve sohbet sunucunuzu ayrı bir güvenlik alanında yaşayacak şekilde yapılandırabilirsiniz (örn. Farklı kullanıcı ayrıcalıkları, farklı erişim ayrıcalıkları, farklı işlem sınırları vb. İle çalışacak şekilde).
3. Sıfır kesinti süresi yükseltmesi - sıfır kesinti süresi yükseltmesi elde etmek istiyorsanız, birden fazla katmana sahip olmanız ve sistemi, hizmet için bir sunucuyu kapattığınızda isteklerinin aynı katmandaki diğer sunuculara sürekli olarak sağlanacak şekilde yönlendirileceği şekilde yapılandırmanız gerekir. hizmet.
4. Sınır aşma - soket sınırına, dosya tanımlayıcı sınırına, genel bir yorumlayıcı kilidine vb. Ulaşırsanız, birden çok işlem çalıştırarak bu sınırın üstesinden gelebilirsiniz. Bunu çözmenin başka bir yolu, sınırı değiştirmek, ancak çekirdeği yeniden derlemeniz gerekebileceği veya güvenlik veya performans sonuçları olabileceği için bu her zaman kolay değildir.
5. Kaynak sızıntısını sınırlama - kaynak sızdırmayan bir yazılım yazmak istiyorsunuz, ancak tamamen çöp yönetimli dillerde bile bu uzun ömürlü süreçlerde son derece zor ve daha da kötüsü bir geliştirme ortamında çoğaltılması zor. Çok katmanlı bir mimari, hizmet sunucularını kesintiye uğratmadan belirli bir süre veya kaynak sızıntılarından kaynaklanan zararları sınırlamak için yapılan isteklerden sonra oyun sunucularını öldürmenize ve yeniden doğmanıza olanak tanır.

Mandal ucube ile aynı fikirdeyim. Tek bir oyun sunucunuz olduğu sürece, zahmete değmez.

Ancak, yatay olarak ölçeklendirmeniz gerektiğinde bu mimari yararlı olabilir. Bir oyun sunucusu artık yeterli olmadığında ve oyununuzu performans nedenleriyle birden fazla oyun sunucusuna dağıtmanız gerektiğinde, "soket sunucusu" mimarisi, soket sunucusunu bağlantıları birçok arka uçtan birine otomatik olarak yönlendiren bir yük dengeleyiciye dönüştürmek için kolayca uyarlanabilir sunucusu.

Ancak buna ihtiyaç duyacağınızdan emin olmadığınız zaman, bu noktada iki ayrı sunucu uygulaması geliştirmek büyük olasılıkla aşırı mühendislik yapıyor.

Muhtemelen hayır, çoğu dilde veri beklerken engellemeden bir kerede birden fazla bağlantı kullanmanıza izin veren asenkron soketler vardır. Bu, "soket sunucusu" bölümünü OS / çekirdeğe kaydırır.

Açık bir soket sunucusu ile, verileri yerel soketten geçirirken birkaç ekstra kopya maliyetine maruz kalacaksınız; ölçeklenebilirliği öldürecek bir şey, onlara ihtiyacınız olmayan ekstra kopyalar.