Haruskah server soket dan server game menjadi proses yang terpisah?

Asumsikan permainan klien / server standar sederhana. Untuk server, apakah ada gunanya memiliki proses terpisah yang mendengarkan koneksi dan pesan dari klien dan mengirimkan data melalui soket lokal atau stdin ke proses lain yang menjalankan server permainan yang sebenarnya?

Pilihan lain adalah membuat kedua hal itu dilakukan dalam satu proses tunggal. Mengantri pesan masuk dan menjalankannya dalam urutan yang benar seharusnya tidak ada masalah penghentian.

Saya bertanya-tanya apakah sumber daya tambahan untuk memisahkan dua "kegiatan" ini benar-benar sepadan. Bagaimana saya harus memutuskan? Saya ingin mendengar pro / kontra.

Dari perspektif desain API, ketika memutuskan apakah akan membuat beberapa program komunikasi yang terpisah atau hanya satu, pertanyaannya adalah: dapatkah masing-masing program berfungsi secara bermakna tanpa yang lain? Jawabannya akan bervariasi berdasarkan proyek dan preferensi Anda.

Jika mereka tidak bisa , itu tidak layak untuk dipikirkan. Jelas mereka sangat terkait sehingga mereka tidak benar-benar proses yang terpisah.

Jika mereka bisa , dan Anda dapat melihat diri Anda ingin memasukkan komponen yang berbeda untuk menggantinya di masa mendatang, maka abstraksi proses yang disediakan OS mungkin membantu.

Berapa banyak membantu tergantung pada sisa tumpukan teknologi Anda. Sebagai contoh Erlang secara internal memodelkan berbagai hal sebagai proses, sehingga Anda tidak akan mendapatkan banyak manfaat konseptual dari memecahnya menjadi proses-OS juga. Kecuali Anda berpikir mungkin menulis ulang bagian-bagian server dalam bahasa yang berbeda. Komponen internal program C ++ biasanya digabungkan lebih ketat dan karenanya lebih sulit untuk ditukar, karenanya memecahnya menjadi berbagai proses OS dapat menghemat kerja Anda nanti jika Anda dapat melihat pengaturan ulang seperti itu.

apakah ada gunanya memiliki proses terpisah yang mendengarkan koneksi dan pesan dari klien dan mengirimkan data melalui soket lokal atau stdin ke proses lain yang menjalankan server permainan yang sebenarnya?

Untuk menjawab apakah itu bermanfaat, Anda harus bertanya pada diri sendiri, apa masalah yang Anda coba selesaikan dengan menambahkan layanan antrian khusus. Jika itu memecahkan masalah itu, maka itu bermanfaat; jika itu tidak menyelesaikan masalah atau jika Anda tidak memiliki masalah untuk dipecahkan untuk memulai, maka mungkin tidak.

Mari kita lihat beberapa alasan mengapa beberapa server menggunakan arsitektur multi-tier:

1. Load balancing - load balancing masuk akal jika Anda ingin menyebarkan beban kerja Anda ke beberapa mesin pekerja. Jika program Anda memiliki kemacetan yang ingin Anda selesaikan hanya dengan memiliki beberapa proses pekerja serentak pada mesin yang sama, maka yang terbaik dalam jangka panjang untuk benar-benar menyelesaikan kemacetan, tetapi sebagai solusi jangka pendek, proses pekerja pemijahan bisa menjadi praktis.
2. Pemisahan hak istimewa - Mungkin Anda tidak ingin pelanggaran keamanan ke server obrolan Anda untuk secara otomatis mendapatkan akses ke server permainan Anda atau sebaliknya. Jika server game Anda terpisah dari server obrolan dalam gim Anda, Anda dapat mengonfigurasi server gim dan server obrolan Anda untuk hidup dalam domain keamanan yang terpisah (mis. Jalankan sebagai pengguna yang berbeda, dengan hak akses yang berbeda, batas proses yang berbeda, dll).
3. Peningkatan downtime nol - jika Anda ingin mencapai peningkatan downtime nol, Anda harus memiliki beberapa tingkatan dan mengonfigurasi sistem sedemikian rupa sehingga saat Anda menurunkan server untuk diservis, permintaannya akan dialihkan ke server lain di tingkat yang sama untuk memastikan kontinu layanan.
4. Breaking limit - jika Anda mencapai batas soket, batas deskriptor file, kunci juru bahasa global, dll., Anda mungkin dapat mengatasi batas itu dengan menjalankan beberapa proses. Cara lain untuk mengatasi ini adalah dengan mengubah batas, tetapi itu tidak selalu mudah karena Anda mungkin harus mengkompilasi ulang kernel, atau mungkin ada implikasi keamanan atau kinerja.
5. Membatasi kebocoran sumber daya - Anda ingin menulis perangkat lunak yang tidak membocorkan sumber daya, tetapi bahkan dalam bahasa yang dikelola sepenuhnya sampah ini sangat sulit dalam proses yang tahan lama, dan lebih buruk lagi ini sulit untuk ditiru dalam lingkungan pengembangan. Arsitektur multitier memungkinkan Anda untuk membunuh dan respawn server game setelah sejumlah waktu atau jumlah permintaan untuk membatasi kerusakan dari kebocoran sumber daya, tanpa mengganggu layanan.

Saya setuju dengan ratchet freak. Selama Anda memiliki satu gim, tidak ada masalah.

Namun, arsitektur ini mungkin terbukti bermanfaat ketika Anda perlu meningkatkan secara horizontal. Ketika satu server gim tidak lagi cukup dan Anda perlu mendistribusikan gim Anda di beberapa gim server karena alasan kinerja, arsitektur "server soket" dapat dengan mudah disesuaikan untuk mengubah server soket menjadi penyeimbang beban yang secara otomatis merutekan koneksi ke salah satu dari banyak backend server.

Tetapi ketika Anda tidak yakin Anda akan membutuhkan ini, kemungkinan besar untuk mengembangkan dua aplikasi server terpisah pada saat ini.

Mungkin tidak, sebagian besar bahasa memiliki soket asinkron yang memungkinkan Anda untuk menggunakan beberapa koneksi sekaligus tanpa memblokir sementara data menunggu. Ini menggeser bagian "server socket" ke OS / kernel.

Dengan server soket eksplisit, Anda akan dikenai biaya beberapa salinan tambahan saat Anda meneruskan data melalui soket lokal; satu hal yang akan membunuh skalabilitas adalah salinan tambahan di mana Anda tidak membutuhkannya.