Menjalankan server dan klien dalam proses yang sama


9

Pertanyaan

Saya baru saja mulai bekerja dengan Lidgren dan jaringan untuk pertama kalinya, dan saya menyadari bahwa adalah mungkin untuk menjalankan server dan klien dalam proses yang sama .

Apakah praktik ini tidak disarankan karena alasan apa pun?

Konteks

Alasan saya bertanya adalah karena saya berteori bahwa konsep ini memungkinkan saya untuk memperlakukan mode singleplayer dan multiplayer sebagai satu dan sama, yang akan sangat membantu.

Mengikuti garis pemikiran saya, ini adalah distribusi yang ada dalam pikiran saya:

  • Singleplayer - 1 server + 1 klien dalam proses yang sama. Seberapa cepat komunikasi?
  • Multiplayer - Sama seperti singleplayer untuk host + 1 klien tambahan untuk setiap pemain lainnya .

Alur eksekusi yang saya bayangkan adalah untuk klien menerima input pengguna dan mengirim pemberitahuan ke server. Kemudian server memvalidasinya, dan menyiarkan tindakan yang akan dieksekusi oleh semua klien. Seharusnya tidak masalah jika hanya ada satu klien (yaitu singleplayer) atau banyak klien (yaitu multiplayer).

Jawaban:


7

Ini pada dasarnya adalah proses versus pertanyaan utas, keduanya tidak terlalu berbeda, terkadang utas disebut proses ringan. Perbedaan terbesar adalah bahwa proses terpisah memiliki ruang alamat sendiri tetapi ada perbedaan lain (1):

Per proses

  • ruang alamat
  • Variabel global
  • Buka file
  • Proses anak
  • Alarm yang tertunda, interupsi dan penangan sinyal

Per utas

  • Penghitung program
  • Daftar
  • Tumpukan
  • Negara

Berdasarkan perbedaan-perbedaan ini, mungkin berguna untuk memiliki server dan utas klien dalam proses yang sama sehingga Anda dapat berbagi menangani file dan variabel global. Ini akan menjadi argumen untuk pendekatan 'dalam proses yang sama', argumen lain (kecil) adalah bahwa Anda hanya mendapatkan satu pop-up 'Windows Firewall' per proses. Argumen untuk pendekatan 'proses berbeda' adalah bahwa seseorang dapat menjalankan beberapa server tanpa harus menjalankan banyak klien. Ini akan ideal untuk tuan rumah yang berdedikasi seperti pengaturan dan merupakan pendekatan yang biasa kita lihat pada penembak orang pertama.

Sekarang sebagai ide untuk memiliki proses server atau utas bahkan untuk bermain off-line (dan mungkin bahkan untuk pemain tunggal) ini adalah ide bagus yang banyak digunakan dalam praktek. Anda bisa mengatakan banyak game melakukan ini dengan melihat layar pemuatan, petunjuk kecil seperti 'menerima' akan memberikannya. Masuk akal untuk melakukan ini karena jika Anda ingin membuat multi-pemain, sebagian besar aturan permainan akan diatur oleh server, jadi mengapa tidak mengaturnya untuk pemain tunggal? Ini mengurangi kode yang harus Anda tulis dan memberikan pemisahan yang lebih jelas antara klien dan 'permainan' yang akan meningkatkan kualitas kode Anda.

Sekarang bagaimana dengan berkomunikasi antara proses dan utas? Komunikasi lintas proses dapat dilakukan dalam banyak cara, (bernama-) pipa, memori bersama, COM, itu benar-benar tergantung pada teknologi yang Anda gunakan. Namun, jika Anda membuat server, Anda mungkin ingin menggunakan varian jaringan menggunakan soket dan semacam TCP, ini tentu saja di mana LIDGREN akan berguna.

Banyak dari teknik ini juga berlaku untuk komunikasi lintas thread. Tetapi ini bahkan lebih tergantung pada teknik yang Anda gunakan. Anda bisa lagi menggunakan TCP, tetapi mungkin sistem yang lebih sederhana adalah event dan beberapa marshalling, meskipun ini bisa membuat loop game Anda tidak deterministik (2).

Sumber

  1. Desain dan implementasi sistem operasi (buku MINIX), edisi ke-3 oleh Andrew S. Tanenbaum
  2. Perbaiki cap waktu Anda oleh Glenn Fiedler: http://gafferongames.com/game-physics/fix-your-timestep/

1
Satu-satunya tambahan saya adalah jika Anda ingin klien lokal bekerja dengan server lokal menggunakan kode yang sama dengan klien jarak jauh, dan Anda ingin klien ini menggunakan kode yang sama lagi untuk terhubung ke server jarak jauh yang akan Anda kunjungi. 1) menggunakan proses untuk server, dan 2) menggunakan jaringan karena ini adalah penyebut yang umum. Kecuali Anda merasa ingin menulis dua versi kode transportasi Anda, lagian =)
Patrick Hughes
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.