[C++, SFML] Czy warto zastosować "bezpieczny" UDP
Panel użytkownika
Nazwa użytkownika:
Hasło:
Nie masz jeszcze konta?
Zarejestruj się!

[C++, SFML] Czy warto zastosować "bezpieczny" UDP

AutorWiadomość
Temat założony przez niniejszego użytkownika
[C++, SFML] Czy warto zastosować "bezpieczny" UDP
» 2014-05-28 15:25:04
Witam. Od pewnego czasu kodzę gierkę w sieci. Korzystam z SFML-Network i protokołu UDP.
Gierka ma być dynamiczna, więc będzie w ruchu dużo pakietów. Dlatego wybrałem UDP, bo z tego co wiem, jest szybsze, choć pakiety mogą się zgubić. I teraz nie wiem, czy warto zastosować coś, co zwiększy prawdopodobieństwo odebrania pakietu.

Myślałem nad takim rozwiązaniem:
Podczas wysyłania pakietu, do vectora dodaję obiekt. Jeśli w ciągu x sekund nie dostanę od adresata potwierdzenia odebrania pakietu, to wysyłam pakiet jeszcze raz i dodaję do obiektu vectora stosowną informację. Jeśli jednak np. za drugim razem sytuacja się powtórzy, to nadawca stwierdza, że połączenie zostaje zerwane. A jeśli pakiet zostanie odebrany i adresat wyśle potwierdzenie, to usuwam z vectora obiekt i stwierdzam, że połączenie jest, a adresat dostał swój pakiet.

Myślę, że to dobry pomysł, ale z drugiej strony... Czy nie będzie to zbyt wielkie obciążenie? Może lepszym rozwiązaniem byłoby wysyłać częściej pakiety tak, żeby utrata jednego nic nie zmieniła?

Z góry dziękuję za pomoc.
P-111010
» 2014-05-28 15:29:06
Prawdopodobnie wyjdzie to wolniej niż TCP. Zaprojektuj komunikację sieciową tak, by zgubienie się pojedynczych pakietów nie miało wpływu na rozgrywkę.
P-111011
» 2014-05-28 16:26:59
Słabe rozwiązanie. Jeżeli dane są 'ważne' to powinieneś użyć protokołu TCP. Jeżeli dane szybko się dezaktualizują (kilka/kilkanaście ms) to wówczas zastosowanie protokołu UDP ma sens. Innymi słowy: protokół UDP ma sens wtedy, gdy jesteś w stanie poradzić sobie w sytuacji, gdy jakiś pakiet 'zaginie' bo i tak nowszą wersję danych dostaniesz w nowszym pakiecie (np. pozycja gracza w grze FPP). Jeżeli musisz mieć wszystkie wysyłane dane, to użycie UDP nie ma większego sensu, bo będziesz musiał całą masę kodu napisać po to, aby w ostateczności uzyskać to, co daje z automatu SZYBKI protokół TCP.

Protokół TCP nie jest wolny. Generuje po prostu większe opóźnienia w przypadku, gdy pakiety są gubione, bo musi je ponowić po to, aby wszelkie dane wysłane z punktu A dotarły do punktu B w tej samej kolejności, w jakiej były nadawane.

(...) w ciągu x sekund nie dostanę od adresata potwierdzenia odebrania pakietu, to wysyłam pakiet jeszcze raz i dodaję do obiektu vectora stosowną informację
Takie założenie komunikacji z definicji mówi, że ta gra nie może być dynamiczna. Taki model komunikacji można sobie stosować do gry planszowej, a TCP będzie n-set razy szybsze i lepsze niż Twoje założenia, które zastosowałbyś w oparciu o protokół UDP.
P-111016
» 2014-05-28 17:54:50
TCP nie jest zbyt wolne, nawet w przypadku gry w czasie rzeczywistym, aczkolwiek nie tak szybkie jak UDP. Implementacja "reliable UDP" ma sens, zwłaszcza wtedy, gdy potrzebne są pakiety mieszane - np. wysyłanie pozycji graczy w czasie rzeczywistym jako niezaufane UDP, ale wysyłanie informacji o jakimś istotnym wydarzeniu jako zaufane. Implementacja dobrego, zaufanego UDP nie jest łatwa. Jedno z gotowych rozwiązań to http://enet.bespin.org/ - League of Legends z niego korzysta.
P-111023
Temat założony przez niniejszego użytkownika
» 2014-05-28 18:28:44
Ah, czyli to tak... Już rozumiem. :)
P-111024
« 1 »
 Strona 1 z 1