Autor Wątek: Teoretyczne zagadnienia związane z siecią  (Przeczytany 1602 razy)

Offline Budzik94

  • Użytkownik

# Październik 25, 2015, 14:40:34
Rozpocząłem prace nad swoją grą sieciową wczoraj testowałem i działa połączenie i aktualizowanie obiektów przy wielu graczach. Gra musi dawać sobie rade z czasem rzeczywistym i szybkim odświeżaniem obiektów dlatego zdecydowałem się na UDP.  Chciałbym ją udoskonalić obecnie wszystko wykonuje na protokole UDP lecz chciałbym początkowe ustawienia przy dołączaniu do gry oraz czat zrobić po TCP aby zapewnić sobie retransmisje. Czy to dobry pomysł używać dwóch protokołów ? Może zamiast stosować TCP zrobić coś własnego i obudować protokół UDP?

Gdybym chciał zrobić multicast i zgrupować połączenie UDP to skąd się bierze adres IP multicastu? Jest on obojętny i po prostu muszę się zdecydować na obojętnie który z zakresu adresów multicastu?

Czy opłaca się tworzenie multicastu? ma to jakieś wady?

Czy transmisja TCP może być na takim samym porcie co UDP ?

Czy wszystkie porty mają taką samą przepustowość? Na który najlepiej się decydować?

Z góry dzięki za wszelkie odpowiedzi :)

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Karol

  • Użytkownik

# Październik 25, 2015, 16:15:30
Czy transmisja TCP może być na takim samym porcie co UDP ?
Tak.

Czy wszystkie porty mają taką samą przepustowość? Na który najlepiej się decydować?
Tak. Port obojętnie, najlepiej taki, którego nikt nie używa ;) Dwa, że serwery korzystające z portów <1024 wymagają uprawnień roota na linuxie.

Offline Xion

  • Redaktor
    • xion.log

  • +2
# Październik 25, 2015, 19:05:29
Cytuj
Czy to dobry pomysł używać dwóch protokołów ? Może zamiast stosować TCP zrobić coś własnego i obudować protokół UDP?
Nie wydaje mi się, żeby ograniczenia TCP cię ruszały w tym przypadku, więc IMHO spokojnie możesz z niego korzystać. Prostsze to niż dodawanie własnych ACKów do UDP.

Cytuj
Gdybym chciał zrobić multicast i zgrupować połączenie UDP to skąd się bierze adres IP multicastu? Jest on obojętny i po prostu muszę się zdecydować na obojętnie który z zakresu adresów multicastu?
Multicast wymaga współpracy infrastruktury sieciowej po stronie odbiorców. Innymi słowy, nie możesz sobie po prostu nagle stwierdzić, że do losowych X hostów w ogólnym Internecie będziesz słał pakiety multicastem, bo tych X hostów musiało by się najpierw samemu zarejestrować jako multicastowa grupa pod danym IP/portem (poprzez protokół IGMP) w swojej bramce sieciowej. Oczywiście żadna taka wspólna bramka nie istnieje, jeśli hosty są rozproszone po świecie.

Cytuj
Czy opłaca się tworzenie multicastu? ma to jakieś wady?
Poza tym, że jak wspomniałem, jest niemożliwe w twoim przypadku, raczej nie :)

Cytuj
Czy wszystkie porty mają taką samą przepustowość? Na który najlepiej się decydować?
O ile routery po drodze nie robią jakiegoś throttlingu albo QoSa na konkretnych portach, to nie ma to znaczenia. Oczywiście mówimy tu o portach które wysyłasz w pakietach (tzw. portach zdalnych), a nie portach lokalnych do których bindowane są sockety (i które mogą, choć nie muszą, być różne niż odpowiadające im porty zdalne).

Cytuj
Dwa, że serwery korzystające z portów <1024 wymagają uprawnień roota na linuxie.
Precyzując, bind() do portu < 1024 wymaga superusera. Samo nasłuchiwanie połączeń i ich akceptowanie już nie, dlatego procesy serwerowe zwykle pozbywają się uprawnień roota po otwarciu słuchającego socketa.

Offline Budzik94

  • Użytkownik

# Październik 25, 2015, 21:52:34
Nie wydaje mi się, żeby ograniczenia TCP cię ruszały w tym przypadku, więc IMHO spokojnie możesz z niego korzystać. Prostsze to niż dodawanie własnych ACKów do UDP.

Ale jednak UDP zostawić do danych które gdy utracę nic się nie stanie ? Bo spotkałem się już z opiniami ze wszystko po TCP najlepiej zrobić lecz tego nie widzę bo gdy wysyłam pozycje X i Y to nawet jeśli stracę jakiś pakiet to następny pakiet to naprawi przesuwając obiekt od razu dalej pomijając jedną "klatkę" która się zgubiła.

Offline Kurak

  • Użytkownik

  • +1
# Październik 25, 2015, 22:31:05
Dziadek Glenn wyjaśni, czemu nie "wszystko po TCP": http://gafferongames.com/networking-for-game-programmers/

Offline Xion

  • Redaktor
    • xion.log

  • +1
# Październik 25, 2015, 22:53:13
Ale jednak UDP zostawić do danych które gdy utracę nic się nie stanie ? Bo spotkałem się już z opiniami ze wszystko po TCP najlepiej zrobić lecz tego nie widzę bo gdy wysyłam pozycje X i Y to nawet jeśli stracę jakiś pakiet to następny pakiet to naprawi przesuwając obiekt od razu dalej pomijając jedną "klatkę" która się zgubiła.
Tak, nie ma sensu pytać o potwierdzenie przesłania danych które mają dużą szansę się zdezaktualizować zanim rzeczone potwierdzenie przyjdzie.