Jest jakiś język programowania co dobrze radzi sobie z siecią? tzn wiele połaczeń na raz i pakiety nie są dzielone przy wysłaniu i przychodzeniu ale są Od razu całe tzn tak mają być widoczne od strony programu. Chodzi mi głównie żeby był dosyć wydajny przy małych pakietach i mógł obsłuzyć wiele połączeń na raz oraz żeby był kompilator pod linuxa, najlepiej darmowy.
0
0
Java jak w mordę strzelił :]
0
A może jeszcze jakieś propozycje? Myślałem nad JAVĄ ale chyba jest troche mniej wydajna bo jest tłumaczona a nie Od razu wykonywana no nie?
Może dam pare rzeczy które bym chciał mieć:
-Obsługa wielu połaczeń i ich utrzymywanie i łatwe przełączanie siię między nimi
-Otwieranie plików i wpisywanie ich do tablicy
-Obsługa dużych tablic :P
-Wielowątkowość tzn żeby było można utworzyć ze 4 współbierzne wątki
-Licznik milisekund
0
C++ (poczytaj sobie o programowaniu gniazd) jest chyba cos w dziale downloads na tej stronie :D
0
Mi zależy głównie o języku gdzie nie bede musiał sadzić tyle kodu co w C żeby odebrać lub wysłać dane itp. Jak jest w C++ ? o gniazdach czytałem przy C i dużo tego :P
Niechciał bym np żeby były takie perełki że pół pakietu poszło i trzeba czekac żeby wysłać druga część, chce żeby tym zajął się program sam w sobie nie programista. Leniwy jestem no nie? Moge pisać nawet dużo kodu ale później się gubię jak wszyscy zresztą :)
Co myśłicie o TCL ? wiem ze niezbyt to język jak C czy C++ ale jako tako jest :P
Wracając do Javy to skąd mogę ściągnąć darmowy "kompilator"?
0
C++ z jakąkolwiek klasą do obsługi socków...
Nie wiem gdzie masz problem z ilością kodu...
I w tym rozwiązaniu jest spora przenośność kodu (np. dla Unix->Windows wystarczy napisać drugą (czytaj: zmienić troche pierwszą) klasę do socketów)
A jak pisze lofix: jave tez mozna skompilowac, a kod jest za**scie przenośny...
0
Tak, tylko skompilowana Java i tak jest nadal duuużo wolniejsza niż C++ (proste benchmarki kłamią). Tzn. nie jest wiele szybsza niż java puszczona normalnie przy włączonym JIT.
Co do sieci - może spróbujesz MPI w C/C++. Jeśli piszesz system rozproszony lub liczysz coś w klastrze, to wymiata. I nie spotkałem nic o większej wydajności.
0
Pisze gre sieciową która ma obsłużyć 500 graczy, śrenio na jednego gracza przypadają 4 pakiety wysłane i 2 odebrane przez serwer w ciągu sekundy
0
No jeśli piszesz grę, to o Javie raczej zapomnij. Nie chodzi nawet o samą wydajność, która najgorsza w końcu nie jest, ale o brak przewidywalności wydajności. Java słabo idzie do aplikacji interaktywnych*, a do czasu rzeczywistego to w ogóle się nie nadaje**. A na początku aplikacja musi się rozpędzić tj. skompilować do kodu maszynowego (JIT).
C++ jest tu chyba najlepszym rozwiązaniem. Jako protokół lepiej wybrać UDP, bo TCP w przypadku zgubienia pakietu wprowadza bardzo duże opóźnienia. Na ogół w grach sieciowych używa się właśnie UDP. UDP może wprawdzie gubić pakiety, ale rzadko i można sobie jakoś z tym poradzić. Interfejs do wysyłania UDP jest bardzo prosty - zwykłe sockety BSD mogą bardzo dużo i naprawdę nie jest to wcale takie niewygodne jak Ci się wydaje (może kwestia wprawy?). W każdym razie nie jest trudniejsze ani żmudniejsze niż w Javie.
// Jeszcze jedno: problem gubienia pakietów możesz albo rozwiązać sam DOBRZE, albo zdać się na TCP, które zrobi to w sposób BEZNADZIEJNY dla gier. Po prostu zgubienie pakietu w TCP powoduje znaczne opóźnienie WSZYSTKICH wysłanych pozostałych pakietów łącznie z tym zgubionym. Nie wiem, jaką grę piszesz, ale w grach czasu rzeczywistego (np. strzelanki, strategie itp.) takie opóźnienie jest czymś dużo gorszym niż zgubienie przypadkowego pakietu.
- Klikasz menu i cała aplikacja zamiera na parę sekund, bo akurat włączył się odśmiecacz. Odśmiecacz zawsze jakoś włącza się po kliknięciu w menu. Ciekawe czemu? Prawa Murphyego?
- Dobra, da się. Jak ktoś ma dużo samozaparcia to śrubokrętem też wywierci dziurę na wylot w żelbetonowej ścianie.
0
Powyzszy fragment o Javie to prawda, lecz fragment o udp i tcp to powiedzmy lagodnie wielkie nieporozumienie. WIekszosc gier online ze niby wykorzystuje udp ? Jasnneeee. I ze zaaplikowanie wlasnego systemu rozpoznawania klonowania paczek, gubienia ich, retransmisji i zatorow w drodze jest sprawa prosta to w ogole jest stwierdzenie nie na miejscu.
Najpierw radze zapoznac sie dokladnie z tcp i tym protokolem a potem wydawac takie opinienie. Zwykle gry wlasnie wymagaja aby paczki nie byly gubione, i szybko aby ta paczka jednak dotarla, wtedy jesli sie nie jest szpecem od zagadnien sieciowych tcp to jedyne sensowne wyjscie.
0
Miałem na myśli gry multiplayer czasu rzeczywistego takie jak America's Army, Quake, Starcraft, Warcraft itp. Takie rzeczy robi się na UDP, bo na TCP po prostu nie sposób zrobić tego dobrze. TCP ma wbudowane na sztywno timeouty i nie zmienisz zachowania, że jak zgubi paczkę, to wstrzyma pozostałe na czas retransmisji (tzn. przez sieć przejdą, ale aplikacja nie będzie ich mogła zobaczyć). Wtedy będziesz mieć takiego laga, że Cie zdążą zabić.
Piszesz, że ciężko zrobić retransmisje, kontrolę przepływu, szeregowanie pakietów itp. Owszem. Tylko po co? Właśnie po to używa się UDP, żeby nie implementować za jego pomocą TCP. Nawet takie rzeczy jak RPC czy RMI implementuje się na UDP, bo TCP jest za ciężkie. Grę można tak zaprojektować, że zgubienie pakietu nie zaszkodzi BEZ koniecznosci retransmisji. A ważne pakiety kontrolne (np. zakończenie gry, przesyłanie wiadomości miedzy graczami) można przecież przesyłać po TCP.