Lordis Opublikowano 24 Września 2012 Udostępnij Opublikowano 24 Września 2012 Witam ;) Planuje juz od jakiegos czasu gre online (serwer i klient). Czytalem troche o 39dll jak go stosowac itd ale nie wiem czym w sumie sie roznia protokoły TCP i UDP. Znaczy ogolnie wiem ale chcial bym poznac wasze zdanie ktory lepiej uzyc w takiej grze jakie sa zalety, wady jednego i drugiego, w jakiej sytuacji lepiej uzyc tcp a w jakiej udp itd. Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
getStringFromObject Opublikowano 24 Września 2012 Udostępnij Opublikowano 24 Września 2012 Podstawowa roznica jest w predkosci - TCP gwarantuje dotarcie wszystkich pakietow, ale robi to kosztem wolniejszego dzialania (np. wyumusza retransmisje pakietow ktore moga byc uszkodzone). W przypadku gier online zwykle wykorzystuje sie protokoly takie jak UDP, ktore nie gwarantuja dotarcia danych ani ich poprawnosci za to sa szybsze co ma duze znaczenie. Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
Lordis Opublikowano 24 Września 2012 Autor Udostępnij Opublikowano 24 Września 2012 hmm a czy ta roznica miedzy tymi predkosciami jest duza? w takiej prostej grze w ktorej beda przesypane współrzedne, zycie, dmg itd bedzie musialo byc wysylane przez UDP? wydaje mi sie ze lepiej miec pewnosc ze nie utracimy nagle polaczenia a gra bedzie chodzila 0.5s wolniej no chyba ze wiecej trwa opuznienie w TCP Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
getStringFromObject Opublikowano 24 Września 2012 Udostępnij Opublikowano 24 Września 2012 *opoznienie Musisz potestowac, moze akurat dla twoich zastosowan wystarczy. UDP wymaga troche innego myslenia przy pisaniu kodu ale jest to do zrobienia. Z TCP tez mozesz miec problem, zwlaszcza kiedy bedziesz chcial aby kazdy pakiet doszedl. Oczekiwanie na retransmisje moze pwoodowac dosc wyrazne lagi. Lepiej od razu jechac z UDP, i przeladowywac wszystko na biezaco. Generalnie duzo zalezy od tego jak bardzo chcesz aby gra byla "fair" - pamietam historie goscia ktorego sie pytali jak zrobil synchronizacje skomplikowanej eksplozji, odpowiedzial ze nie zrobil jej wcale :P Odpalal jedynie kod na wybuch i na kazdej maszynie wygladalo to odrobine inaczej. Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
Lordis Opublikowano 24 Września 2012 Autor Udostępnij Opublikowano 24 Września 2012 Bo wlasnie nie wiem czy ta roznica czasu jest duza miedzy tcp a udp bo w sumie te pakiety nie beda takie duze a wyczytalem tez ze udp wymaga odblokowania portow u klienta a tcp nie wiec tez jest to pewnym utrudnieniem. Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
ediepl Opublikowano 25 Września 2012 Udostępnij Opublikowano 25 Września 2012 Zawsze możesz zrobić tak że jeśli ktoś nie ma odblokowanych portów to używa tylko TCP, albo użyć UDP hole punching. Jeśli gra nie jest dynamiczna( gra karciana, strategia, etc. ) to możesz użyć samego TCP. Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
Administratorzy gnysek Opublikowano 25 Września 2012 Administratorzy Udostępnij Opublikowano 25 Września 2012 Wejdź na wikipedię i zobacz ile bajtów ma nagłówek TCP a ile UDP i policz ile danych wysyłasz. Proste dodawanie. Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
Lordis Opublikowano 25 Września 2012 Autor Udostępnij Opublikowano 25 Września 2012 okok dzieki ;D gra bedziw turowa wiec tcp styknie chyba ale przyda mi sie na przyszlosc ;) Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
kriso99 Opublikowano 25 Września 2012 Udostępnij Opublikowano 25 Września 2012 nie czaje tego, mógłby mi ktoś to szerzej wytłumaczyć, przyda mi się to niedługo konkretnie chodzi mi o rozmiar nagółwka tcp i udp Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
getStringFromObject Opublikowano 25 Września 2012 Udostępnij Opublikowano 25 Września 2012 W skrocie - poniewaz tcp gwarantuje poprawnosc danych naglowek pakietu zawiera wiecej informacji, np. checksum i itp. czego nie ma w udp bo tam pakiety po prostu leca i nikt sie nie troszczy o to czy kiedykolwiek dotra i w jakiej formie. Do tego, tak jak wspominalem, w TCP dochodzi narzut zwiazany z liczeniem sum, sprawdzaniem poprawnosci danych i ew. retransmisja. Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
Utermiko Opublikowano 25 Września 2012 Udostępnij Opublikowano 25 Września 2012 TCP jest protokołem połączeniowym. Kiedy klient się rozłączy dostajesz o tym informację. TCP jest wolne, ponieważ pakiety zawsze są sprawdzane i jeśli nie dotrą to wysyła je jeszcze raz. Zawsze docierają w kolejności w jakiej je wysłałeś. Wymaga otwarcia portów tylko na serwerze. UDP jest protokołem bezpołączeniowym. Kiedy wysyłasz wiadomość, za każdym razem podajesz ip i port na jaki ma być wysłany pakiet. Wysyła i go później nie interesują dalsze losy pakietu, dzięki czemu jest dość szybki. Musisz sam to sprawdzać. Pakiety mogą dotrzeć, dotrzeć w innej kolejności, dotrzeć 2 razy lub nie dotrzeć wcale. Nie ma czegoś takiego, że dotrze część pakietu lub nie poprawne dane. Do gry dynamicznej jest to dobre rozwiązanie, ponieważ jeśli pakiet jest wysyłany 10x na sekundę to w razie jeśli poprzedni pakiet nie dojdzie to następny zrobi poprawkę. UDP wymaga otwarcia portów na serwerze, jak i u klienta, chyba że użyjesz UDP Hole Punching to wtedy nie musisz ani na serwerze ani na kliencie. Częstym sposobem jest używanie TCP i UDP razem. TCP do wiadomości które muszą dotrzeć, jak np. chat, informacja o statach etc., a UDP to np. ruch. Do gry turowej TCP będzie idealne. Nie pomyśl sobie czasem, że TCP jest tak wolne, że pakiet leci ze dwie sekundy. Przy małej ilości pakietów wysyłanych na raz, tak jak w grach turowych to, czy pakiet leci 100 ms czy 200 ms to nie będzie różnica. Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
Lordis Opublikowano 25 Września 2012 Autor Udostępnij Opublikowano 25 Września 2012 ooo i takiej wypowiedzi mi brakowało ;) prosto i jasno objasnione co i jak ;D wielkie dzieki teraz mi zostaje doczytac o wysyłaniu i odbiorze pakietów u kientq i przez serwer i zabieram sie do roboty ;D jeszcze raz dzieki wszystkim ;) Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
kriso99 Opublikowano 25 Września 2012 Udostępnij Opublikowano 25 Września 2012 ok, ale np. jak bym chciał obliczyć ile bajtów wysyła, a ile odbiera, to jak to obliczyć? Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
Utermiko Opublikowano 25 Września 2012 Udostępnij Opublikowano 25 Września 2012 @kriso99 GML var size; while(true) { size = receivemessage(global.otherplayer);//SIZE TO WIELKOSC W BAJTACH WIADOMOSCI if(size < 0) break;//jesli wielkosc jest mniejsza od 0 to znaczy ze nic nie odebralismy if(size == 0)//jesli wielkosc jest rowna 0 to znaczy ze klient sie rozlaczyl { show_message("The other player left the game"); game_end(); } messageid = readbyte(); switch(messageid) { //... } } Obliczanie wysłanych bajtów? Sprawdzasz wielkość bufora przed wysłaniem(nie wiem jaka jest funkcja, nie robię już w GM), lub sam sobie obliczasz. Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
Administratorzy gnysek Opublikowano 25 Września 2012 Administratorzy Udostępnij Opublikowano 25 Września 2012 Wejdź na wikipedię i tam masz rozmiary pakietów podane dla TCP jak i UDP. Z tym, że jak TCP nie dotrze będzie wysyłany raz jeszcze i tego już nie przewidzisz - jak są lagi w sieci to może być wysyłane 2-3x wiecej danych niż gdyby 100% pakietów dotarło do celu. Odnośnik do komentarza Udostępnij na innych stronach Więcej opcji udostępniania...
Rekomendowane odpowiedzi
Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto
Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.
Zarejestruj nowe konto
Załóż nowe konto. To bardzo proste!
Zarejestruj sięZaloguj się
Posiadasz już konto? Zaloguj się poniżej.
Zaloguj się