Skocz do zawartości

Pieter

Użytkownicy
  • Postów

    1 990
  • Dołączył

  • Ostatnia wizyta

Treść opublikowana przez Pieter

  1. wiesz, że można to zrobić nawet bez dll'i :>?
  2. Pieter

    AmpliTube

    wcale nie... chyba punk rocka...
  3. w takim razie rozwiązaniem będzie tworzyć wątek dla każdego klienta ;] ale to już przy multum klientów nie jest takie wydaje i straaaaasznie niewygodne w operowaniu na danych. Poza tym, skoro nie tak jak opisałem, to jak :)? po prostu dodać kolejny warunek... "if len == 1 recv bla bla bla pfff. Dobre sa takie dyskusje, bo nie wszystko można wykryć podczas "testów". Wszystko o czym tu mówimy to "co by było gdyby". Nie ma aplikacji idealnej, ani silniku idealnego ;]
  4. prawie cos typu "szyfr cezara". najprostszy z szyfrów
  5. C++ + linux YES. klient nie może nie wczytać pierwszych 2 lini buffora ponieważ to nie jest UDP a TCP. TCP jest liniowy, pakiety nie przychodzą pomieszane ORAZ mają swój protokołowy hash który zapewnia że pakiet dotrze w całości (choć może być niby podzielony na części) to jednak dotrze "cały". Dopisanie procedury, która sprawdziła by czy pakiety nie są połączone jest równie łatwe co to co napisałem wyżej. Jeżeli nie podoba się silnik to go nie używaj. Sprawdź sobie źródła 39dll i zobacz, że nie ma tam zabezpieczeń. Proste... konstruktywna krytyka swoją drogą ale narzekać ciągle każdy może :) edit: poza tym można ustalić wartość ILE bitów ma być odebranych np zamiast recv(Clients->Client[i].Sock, temp, MAX_CLIENT_BUFFER, 0); można recv(Clients->Client[i].Sock, temp, ILOSC_BYTE_POZOSTALYCH_W_PAKIECIE, 0);
  6. Pieter

    Minecraft plugin

    bez sensu... to by była totalna debalansacja...
  7. omg... 2 pierwsze bajty w Cbuffor, to długość pakietu jaki został wysłany (takie zabezpieczenie), wystarczy po 1 recv sprawdzić czy ilość bajtów odebranych jest zgodna z wartością U16 (2 pierwsze bajty) i jeżeli nie to zrobić pętle recv aż będzie zgodne... coś w deseń: GML // thread PARSER wlasciwy void TCPThread::ExecuteParser() { int len, i, j, trueLength, readedLength; char buffer[MAX_CLIENT_BUFFER], temp[MAX_CLIENT_BUFFER]; printf("[TCPThread] Parser thread executed!\n"); memset((char *)buffer, 0, MAX_CLIENT_BUFFER); while (1) { for ( i = 0; i < MAX_CLIENTS; i++ ) { if (Clients->Client.Sock != 0) { len = recv(Clients->Client.Sock, buffer, MAX_CLIENT_BUFFER, 0); if (len == 0) // klient sie rozlaczyl { printf("[TCPThread] Client %s disconnected (by peer)\n", Clients->Client.IP.c_str()); pthread_mutex_lock(&new_connection_mutex); // blokujemy dostep do danych Clients->Delete(i); // usuwamy klienta ktory sie rozlaczyl pthread_mutex_unlock(&new_connection_mutex); // inne thready moga juz korzystac z danych } else if (len < 0) // blad polaczenia czy cos. Klient traci polaczenie. { if(errno != EAGAIN) // to nie jest blad braku odbioru { printf("[TCPThread] Client %s disconnected (by server & ERRNO: %d)\n", Clients->Client.IP.c_str(), errno); pthread_mutex_lock(&new_connection_mutex); // blokujemy dostep do danych Clients->Delete(i); // usuwamy klienta ktory sie rozlaczyl pthread_mutex_unlock(&new_connection_mutex); // inne thready moga juz korzystac z danych } } else // przyszedl pakiet i mozemy przetwarzac! { trueLength = (buffer[0] | (buffer[1] << 8)); // rzeczywista długość (2 pierwsze bajty buffora) readedLength = len; // trzeba ustalic wartosc ile odczytalismy while (readedLength < trueLength) { memset((char *)temp, 0, MAX_CLIENT_BUFFER); // resetujemy tymczasowy buffor len = recv(Clients->Client.Sock, temp, MAX_CLIENT_BUFFER, 0); // staramy sie czytac reszte for (j = 0; j < len; j++) { buffer[readedLength + j] = temp[j]; // mozna pewnie to szybciej zrobic za pomoca memcpy ale nie chce mi sie zaglebiac } readedLength += len; // dodajemy to co odczytalismy } ParsePacket(i, buffer, len); // przetwarzamy pakiet } memset((char *)buffer, 0, MAX_CLIENT_BUFFER); // resetujemy buffor } } } } kodu nie sprawdzałem, ale w teorii powinien dać pozytywny skutek ;) co ty na to sz... (rym dopowiedz sobie sam szerloku ;)
  8. to, że Snake ma racje i ja dobrze o tym wiem, więc nie musisz docinać ;) multi-threading na skale masową nie jest zbyt wydajny... są testy, które jasno mówią, że przy 300+ klientach są znacznie bardziej zamulone niż 2/3 threadów obsługujących wszystkich. Co prawda, większa ilość tych threadów dobrze sprawuje się przy MMO, ja jednak nie projektowałem tego dla masowych połączeń ;) Musimy tu zrozumieć, że projektowanie na czytaniu a select to zupełnie inna struktura (nie zawsze lepsza) aplikacji. Co do dzielenia pakietów, jestem tego świadom... ale nie spodziewam się by ktoś wysyłał 16000 bajtów za 1 razem. Reszta należy do "reszty", to bardzo uproszczony "silniczek".
  9. koniec offtopu. zamykam.
  10. dobra... po prostu zamiast czytać pakietID to czytał długość pakietu... po prostu pod trzeba dodać całość: (lol) https://gmclan.org/up44_3_almora_serwer.html
  11. bo zrobiłem to na kopi mojego serwerka który pisze dla VoIP, tamten już jest daleeeeeeeeko przed tym co tu dałem, poza wstawieniem buffora od 39dll... Już mówiłem, że silnik sieciowy sam w sobie działa, trzeba tylko poprawić czytanie pakietów (ustawić kursor na odpowiedniej pozycji) ;) edit: jak ktoś mi wytłumaczy dlaczego bufforki są odwrócone, to pogadamy ;)
  12. to dlatego, że nie miałem czasu przetestować buffora od 39dll, ale sama zasada zostaje... wystarczy znaleźć błąd...
  13. Myślałem nad pomocą w robieniu serwerka w C++ dla Almory, miałem pomarańczowe światło od Gnyska i zrobiłem silnik sieciowy oparty na threadach + konsole + liste klientów w C++ dla linuxa. Po paru poprawkach łatwo go odpalić także pod Windows. Silnik korzysta z buffora 39dll dzięki czemu możecie przesyłać dane pomiędzy waszymi grami a tym serwerkiem. Projekt zrobiony w Code::Blocks, nie proście o nic bo nie mam zamiaru tego poprawiać/przepisywać itd... wszystkie pliki potrzebne do dalszego kodzenia są udostępnione w paczce. powtarzam... kod jest pod LINUX'a by mógł być uruchamiany na dedykach albo vps'ach. Róbcie co chcecie, tylko nie podpisujcie się pod moim kodem... Troszkę szacunku do czyjejś pracy. Creditsy mile widziane. https://gmclan.org/up44_3_almora_serwer.html edit: dla tych co nie wiedzą, serwery pod linux najbardziej są przydatne dla gier MMO lub serwerow które mają być otwarte 24/7.
  14. Pieter

    MiniWeb Studios

    mógł bym teraz pojechać po tej stronie, co zwykle mam w zwyczaju bo widzę tu duuuużo rzeczy, które duuuzo o was mówią, ale by nie dostać warna powiem grzecznie. Powodzenia ;) lol
  15. bo serwer teraz nie stoi...
  16. Pieter

    Gmclanowe sny

    miałem sen... to był cudowny sen... to był sen o GMClanie wolnym od takich tematów, wolnym od trolli, noobów i pełnym produkujących 24/7 soft małp potrafiących napisać poprawnie słowo "mój".
  17. tyle o tym gadasz a ciekawe czy w ogóle masz cos z tym wspólnego ;] psy, które głośno szczekają itd ;)
  18. malboro smakują gorzej niż L&M, ale to tylko moje odczucie bo się do nich przyzwyczaiłem. Czemu? nie nas się pytaj... sprawdzaj sobie zawartość co jakiś czas. Smak zależy od tego kiedy myłeś zęby, co jadłeś itd. Nie podoba się smak papierosa to zacznij pykać fajki ;)
  19. C# to język kompilowany? buhaha bardzo śmieszne ;) to tak samo język interpretowany jak każdy inny wysokopoziomowy np java.
  20. Pieter

    Qt

    http://doc.trolltech.com/main-snapshot/dem...es-qtbox-h.html
  21. Pieter

    Fallin Starship

    daj nuty albo taby na bass ;>
  22. Pieter

    [Praca] PHP Programista

    ja jestem ze śląska i mam 18+ lat ;x
  23. znajdę atomówkę i go zniszczę! nie ogra mnie do 0!
  24. to to o czym Ci na gg powiedziałem tak? otóż wystarczyło się zapytać jeszcze raz... każdy NAT ma indywidualny czas do zakończenia czekania na pakiet (może to być 30/50/120 sekund [nie ma standardu] ale średnia to 20 sekund) dlatego można wysyłać ping co 5 sekund (który może przepaść) lub zrobić funkcje która będzie wykrywała czy dziura już jest zamknięta i otworzy ją ponownie... Drugie... 200 graczy... Tak, każdy z każdym i do każdego pod warunkiem, że są na widoku (np GM), oszczędzając wtedy łącze... To jest wykorzystywane w grach multi typu l4d2, tf2 itd, serwer główny działa głównie jako informator o ip i portach. Kiedy chcemy grać na przykład za 1 NAT'em a nie dwoma, dobrze jest wysyłać ip wewnętrzne razem z ip zewnętrznym i próbować robić dziury na obu IP. Rozwiązuje to wiele problemów. Może jak będę miał czas pomiędzy kodzeniem dla Ciebie serwerka Almory (na który nadal czekam na specyfikacje pakietów) a moim programem VoIP (być może napiszę taką bibliotekę dla GM by można było się komunikować podczas gier) to napiszę przykład :) Open Source C++/Delphi jak kto będzie chciał. Co do TCP... w TCP także istnieje Hole Punching, trudniejszy do zaimplementowania ale działa :) Miej na względzie, że oprócz NAT trzeba także przejść obok firewalla od antywirusa lub zapory sieciowej (ale to może już wyłączyć użytkownik). na UDP H-P trafiłem kiedy przesyłanie dużej ilości pakietów voice przez serwer spaliło na panewce ;p
×
×
  • Dodaj nową pozycję...