Permainan Kartu Server-Klien Berbasis Giliran - Unicast (TCP) atau Multicast (UDP)


8

Saat ini saya berencana untuk membuat proyek permainan kartu di mana klien akan berkomunikasi dengan server secara turn-based dan sinkron menggunakan pesan yang dikirim melalui soket. Masalah yang saya miliki adalah bagaimana menangani skenario berikut:

(Klien mengubahnya dan mengirimkan aksinya ke server)

  1. Klien mengirim pesan yang memberi tahu server langkahnya untuk belokan (mis. Memainkan kartu 5 dari tangannya yang perlu diletakkan di atas meja)

  2. Server menerima pesan dan memperbarui status permainan (server akan menampung semua status permainan).

  3. Server beralih melalui daftar klien yang terhubung dan mengirim pesan untuk memberi tahu mereka perubahan status

  4. Klien menyegarkan semua untuk menampilkan negara

Ini semua didasarkan pada penggunaan TCP, dan melihatnya sekarang sepertinya sedikit seperti pola Pengamat. Alasan mengapa hal ini menjadi masalah bagi saya adalah pesan ini sepertinya tidak point-to-point seperti yang lain karena saya ingin mengirimnya ke semua klien, dan sepertinya tidak efisien mengirim pesan yang sama di seperti itu.

Saya sedang berpikir tentang menggunakan multicasting dengan UDP karena saya bisa mengirim pesan ke semua klien, tetapi tidakkah ini berarti bahwa klien secara teori akan dapat saling mengirim pesan? Tentu saja ada aspek sinkron, meskipun ini bisa diletakkan di atas UDP, saya kira.

Pada dasarnya, saya ingin tahu apa yang akan menjadi praktik yang baik karena proyek ini benar-benar semua tentang pembelajaran, dan meskipun itu tidak akan cukup besar untuk menghadapi masalah kinerja dari ini, saya ingin mempertimbangkannya juga.

Namun, harap dicatat saya tidak tertarik menggunakan middleware berorientasi pesan sebagai solusi (saya punya pengalaman menggunakan MOM dan saya tertarik mempertimbangkan opsi lain selain MOM jika soket TCP adalah ide yang buruk!).

Jawaban:


11

Jangan optimalkan secara prematur. Tetap sederhana. Menggunakan TCP dalam hal ini OK, dan saya tidak melihat masalah dengan skema Anda saat ini.

UDP biasanya digunakan untuk skenario kritis kinerja seperti dalam game aksi online, karena memungkinkan kontrol eksplisit atas paket individu sebagai lawan bekerja di atas lapisan abstraksi aliran seperti TCP. Namun, meskipun Anda memiliki beberapa peningkatan kecepatan dengan mengendalikan dengan tepat bagaimana Anda ingin data dikirim, UDP tidak menangani kehilangan paket atau pemesanan paket seperti TCP, dalam hal ini Anda harus mengkodekannya sendiri. Jadi, karena ini adalah permainan kartu berbasis giliran, saya ragu Anda ingin mengorbankan keandalan melebihi kecepatan, jadi gunakan TCP.


Terima kasih atas jawaban Anda, jelas dan tampaknya menjawab semua yang saya minta.
LDM91

3

Bahkan banyak MMO besar yang populer menggunakan TCP secara eksklusif. Ini akan melakukan semua yang Anda butuhkan dengan semua karakteristik efisiensi yang Anda butuhkan.

UDP membutuhkan banyak kompleksitas ekstra, multicast bahkan membutuhkan lebih banyak kompleksitas, dan Anda tidak akan mendapatkan apa pun darinya. Jika Anda hanya tertarik untuk belajar, tentu saja buatlah demo teknologi untuk Anda sendiri, tetapi jangan berpikir bahwa proyek itu sendiri akan lebih baik karena itu.

Jika Anda tertarik menggunakan UDP sama sekali, tugas pertama Anda pada dasarnya adalah mengimplementasikan ulang TCP di atas UDP, hanya untuk memastikan bahwa Anda benar-benar mengerti bagaimana menangani semua masalah yang dipecahkan oleh TCP untuk Anda: kemacetan kontrol, pengiriman paket yang hilang, penanganan duplikat tertunda, pemesanan paket, jabat tangan koneksi yang andal, urutan pemutusan andal, dll.

Ini tidak selalu sulit untuk menyelesaikan semua itu, tetapi membutuhkan pemahaman yang mendalam tentang jaringan, protokol IP, dan bagaimana masalah-masalah tersebut diselesaikan.

Dari sana, membangun perpustakaan untuk menawarkan fitur-fitur yang tidak dimiliki TCP adalah tempat kesenangan dimulai. Menggunakan aliran pesan multipleks melalui aliran paket, kontrol kemacetan yang lebih efisien, penanganan batas laju, multi saluran, konfigurasi saluran (apakah saluran membutuhkan pesan yang dipesan atau tidak, apakah paket yang dijatuhkan diizinkan, dll.), Dan sebagainya.

Saya sarankan Anda membaca seri artikel berikut. Itu tidak sempurna, dan membuat beberapa klaim yang sangat dipertanyakan (dimulai dengan omong kosong "tidak pernah menggunakan TCP dalam permainan"), tetapi rincian teknisnya membantu programmer jaringan baru: http://gafferongames.com/networking-for-game- programmer / udp-vs-tcp /


1
Dalam pengantar artikel itu penulis menyatakan: "Pilihan yang Anda buat sepenuhnya tergantung pada jenis permainan yang ingin Anda jadikan jaringan. Jadi sejak saat ini, dan untuk sisa seri artikel ini, saya akan menganggap Anda ingin untuk membuat jaringan game aksi. Anda tahu game seperti Halo, Battlefield 1942, Quake, Unreal, CounterStrke, Team Fortress dan sebagainya. "
XiaoChuan Yu

Ah, aku merindukan itu ketika aku membukanya untuk memastikan itu sebaik yang kuingat. Saya buruk, maaf
Sean Middleditch

-1 untuk "Jika Anda tertarik menggunakan UDP sama sekali, tugas pertama Anda pada dasarnya adalah mengimplementasikan ulang TCP di atas UDP" itu adalah IMO yang sangat salah. Jauh lebih berguna untuk mempelajari UDP sebenarnya melakukan hal-hal yang dipilih UDP.
o0 '.

@ Lohoris: Itu tidak membantu dan bahkan tidak benar. Anda HARUS memiliki kemampuan untuk mengirim pesan yang dijamin pesanan bahkan dengan UDP. Anda harus dapat mengirim pesan tanpa jaminan dengan pesanan. Anda harus dapat mengirim pesan tidak sesuai pesanan. Ini paling sederhana untuk memulai dengan perilaku seperti TCP karena memerlukan penerapan semua fitur yang diperlukan dan paling mudah untuk diuji, dan bahkan dengan sendirinya masih memberikan fitur yang berguna seperti kontrol langsung penggunaan bandwidth dan latensi.
Sean Middleditch

@ seanmiddleditch salah. Tidak ada yang salah dengan menggunakan UDP dan TCP di game yang sama, jadi Anda tidak diharuskan untuk menerapkan pengiriman yang dijamin melalui UDP.
o0 '.
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.