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

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.

Prawdopodobnie wyjdzie to wolniej niż TCP. Zaprojektuj komunikację sieciową tak, by zgubienie się pojedynczych pakietów nie miało wpływu na rozgrywkę.

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.

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.

Ah, czyli to tak... Już rozumiem. :)