Czy ma sens jednoczesne używanie zarówno TCP, jak i UDP?


10

Po przeczytaniu Czy UDP wciąż jest lepszy niż TCP w przypadku gier z dużą ilością danych? , Zastanawiam się, czy sensowne jest jednoczesne używanie zarówno TCP, jak i UDP, ale do różnych celów:

  • TCP do wysyłania informacji wysyłanych rzadko, ale należy zagwarantować, że dotrą one niezawodnie.
    Na przykład aktualizacje wyników, imię gracza, a nawet stan włączenia / wyłączenia światła w świecie gry.

  • UDP do przesyłania informacji, które są stale aktualizowane i mogą być czasami tracone, ponieważ nowsze informacje są zawsze w drodze.
    Takie jak pozycja, obrót itp.

Czy to rozsądny pomysł? Jakie są możliwe wady?
Czy są lepsze sposoby na poradzenie sobie z tym?


Przeczytaj pozostałe wątki na tej stronie dotyczące udp i tcp. Znajdziesz kilka szczegółów, które zasadniczo dotyczą twoich pytań. Jako hipoteza: podejrzewam, że istnieją protokoły hybrydowe nad UDP, które próbują wydobyć to, co najlepsze z obu światów, tj. Mniejsze opóźnienia, strategię rywalizacji, równoważenie obciążenia i gwarancje dostawy. Jak sugerowano, wyszukaj pokrewne pytania na ten temat i zawęź swoje pytanie do czegoś, co Twoim zdaniem nie zostało jeszcze rozwiązane.
teodron,

@teodron Nie musisz podejrzewać. Jak stwierdzono w mojej odpowiedzi, jest to fakt.
Inżynier

Odpowiedzi:


8

Powoduje to utratę pakietów dla UDP z powodu sprzeczności między dwoma protokołami - pamiętaj, że UDP nie gwarantuje dostarczenia, podczas gdy TCP. Przejdzie więcej pakietów TCP, podczas gdy UDP cierpi - TCP powoduje utratę pakietów UDP . Pojawił się również (historyczny) pomysł, że infrastruktura routerów faworyzuje TCP zamiast UDP, choć wątpię, aby do tej pory tak było.

Myślę, że lepiej byłoby znaleźć jeden z protokołów UDP zorientowanych na połączenie, który jest dostępny do gier i tym podobnych, który oferuje niektóre zalety TCP bez żadnych jego wad. Jest kilka takich, zwykle z oficjalnym dokumentem opisującym każdą koncepcję.

Przykładem tego jest biblioteka Enet typu open source , której podstawową funkcją jest opcjonalne niezawodne dostarczanie pakietów w kolejności przez UDP.


1
Aby odpowiedź była nieco bardziej „mięsista”, czy mógłbyś podać krótką (bardzo krótką) listę opcji / referencji dla bibliotek transportowych opartych na UDP? (być może ENET, RakNet, zeroMQ, UDT?). Jak wynika z powyższego komentarza, jestem pewien, że widziałem dyskusję na ten temat gdzieś na tej stronie, ale warto powtórzyć fragment tej informacji.
teodron 19.04.16

1
@Arcane Engineer Co zrobić, jeśli gniazda UDP i TCP działają na różnych portach?
KaareZ 19.04.16

@KaareZ Nie powinno mieć żadnego znaczenia. Badania, które zostały wykonane (patrz link w edycji) nie byłyby ważne, gdyby chodziło tylko o podział na porty. Pod koniec dnia port to tylko port oprogramowania. Tak naprawdę nie wpływa to na charakterystykę sieci, do czego to sprowadza się.
Inżynier

To, co mówisz, ma sens, ale nie mogę przestać się zastanawiać, czy nadal dotyczy to tam, gdzie ruch TCP jest bardzo mały. Jeśli tylko niewielkie ilości informacji są przesyłane za pośrednictwem protokołu TCP, powiedzmy średnio raz lub dwa razy co ~ 10 sekund, czy to naprawdę wpłynie zauważalnie na ruch UDP?
gandalf3

2
Papier „TCP powoduje utratę pakietów UDP” nie ma daty. Najnowsze referencje pochodzą z 1996 roku. Od kiedy to jest papier? Czy wnioski są nadal aktualne?
Andreas,

4

Oto cytat Sama Jansena z komentarza na gafferongames.com :

Mówiąc jako badacz sieci, a nie twórca gier, wniosek, aby nigdy nie używać jednocześnie TCP i UDP, wydaje się nieco mocny. TCP może utracić pakiet tylko wtedy, gdy wysyła zbyt dużo danych; w pewien sposób, podobnie jak wysyłane dane UDP. Różnica polega na tym, że nie masz bezpośredniej kontroli nad prędkością wysyłania TCP, jest to dla ciebie ukryte.

Jeśli po prostu potrzebujesz wysłać pewne wiarygodne dane i nie chcesz się martwić retransmisją i wdrożeniem niezawodnego protokołu, a wiesz, że szybkość będzie niska, nie będzie żadnych problemów z używaniem zarówno TCP, jak i UDP.

Relacja między tymi dwoma nie jest tak naprawdę złożona: TCP po prostu zwiększa szybkość wysyłania (jeśli są dane do wysłania), dopóki nie utraci pakietu, w którym to przypadku ponownie wybiera swoją szybkość, a następnie zaczyna ponownie zwiększać szybkość (to czas wolniej). Gdy jego wzrost powoduje utratę pakietów, istnieje duże prawdopodobieństwo, że trafi również na inne strumienie danych, w tym na pakiety UDP.

Artykuł Charakterystyka utraty pakietów UDP: Wpływ ruchu TCP uzyskał swoje wyniki, otwierając wiele połączeń TCP jednocześnie i zalewając sieć danymi. Prowadzi to do przeciążenia, po którym następuje globalna synchronizacja , które powodują odrzucanie pakietów. Oczywiście klient gry nie otworzy jednocześnie kilkunastu połączeń i zalej sieć danymi, więc Twoje wyniki będą inne.

Odpowiedzieć na Twoje pytanie:

Zastanawiam się, czy ma sens jednoczesne używanie zarówno TCP, jak i UDP, ale do różnych rzeczy [...]

Tak, jest to do przyjęcia, zakładając, że nie przekraczasz limitów przepustowości.

  • TCP do wysyłania informacji wysyłanych rzadko, ale należy zagwarantować, że dotrą one niezawodnie. Na przykład aktualizacje wyników, imię gracza, a nawet stan włączenia / wyłączenia światła w świecie gry.

Korzystając zarówno z protokołu TCP, jak i UDP, zawsze powinieneś preferować wysyłanie jak największej ilości danych przez UDP, a możliwie jak najmniej przez TCP.

Teraz pytam: czy naprawdę konieczne jest przesłanie partytury, nazwy gracza i stanu światła przez TCP? Chociaż prawdą jest, że w końcu musisz otrzymać te dane, czy to prawda, że ​​musisz otrzymywać te dane ściśle w kolejności i dokładnie raz?

Prawdopodobnie nie.

UDP działa dobrze w tych przypadkach, a Quake 3 jest dobrym przykładem tego, jak to zrobić.

Więc jaki jest dobry przykład TCP obok UDP? Pomyśl o czacie gry. Aktualizacje tego czatu (to znaczy nowe wiersze tekstu) muszą być przesyłane zarówno niezawodnie, jak i ściśle w kolejności. Tak więc TCP jest dobrym dopasowaniem.


3

Czy to rozsądny pomysł?

  • tak

Jakie są możliwe wady?

  • Utrata pakietów, większa złożoność kodu, kolejne połączenie do zarządzania == większa szansa na rozłączenie, przekroczenie limitu czasu, wyjątki, cokolwiek ...

Czy są lepsze sposoby na poradzenie sobie z tym?

  • Użyj istniejącej niezawodnej biblioteki UDP. Dwa najbardziej popularne to: Lidgren Network (C #), RakNet (C ++). Z doświadczenia mogę powiedzieć, że Lidgren jest bardzo łatwy w użyciu, szybki i niezawodny.

1

Należy wziąć pod uwagę dodatkowe ograniczenie zasobów. Większość wdrożeń (Wierzę wszystkim, ale nie ma odniesienia) TCP na serwerze ma ograniczenia dotyczące liczby jednoczesnych połączeń TCP, które serwer może otworzyć jednocześnie. Ograniczyłoby to liczbę graczy, których możesz otworzyć jednocześnie, jeśli każdy gracz potrzebuje własnego połączenia.

Limity są określone przez ustawienia w systemie sieciowym. Dodatkowo każde połączenie zużywa trochę pamięci, która musi pochodzić skądś na serwerze.

Jednym z rozwiązań jest otwarcie tymczasowego połączenia TCP podczas przesyłania danych i natychmiastowe zamknięcie. Spowoduje to spowolnienie transakcji, otwarcie połączenia TCP jest raczej „drogim” procesem. Jak zawsze, od samego początku chodzi o zaprojektowanie solidnego systemu, aby umożliwić duży rozwój.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.