• 15/12/2005 20:46
• 

• Git! 0

  Kit! 0

A co do wybierania to fakt, że po prostu nie mam czasu, żeby to napisać w C++, więc wybrałem Javę :)

• 15/12/2005 20:52
• 

• Git! 0

  Kit! 0

no masz alignacje.
masz parowanie.
dzieki paralernemu wykonywaniu instrukcji procesor moze ich kilka wykonac w jednym cyklu.
masz agi stall zwiazany z korzystaniem np. z tego samego rejestru.
w koncu madre korzystanie z cachu.
instrukcje skokow warunkowych potrafia nabruzdzic..

zreszta ja specjalnie sie nie znam na optymalizacji typowo na predkosc, ale za to wiem cos o optymalizacji na wielkosc kodu; >
co zreszta nie idzie w parze..

zreszta nie to grono :P

--
peace!

• 20/12/2005 14:39
• 

• Git! 0

  Kit! 0

Wykryc zerwanie polaczenia mozesz tez przez odczyt danych z socketu, kiedy read zwraca -1 to polaczenie zerwane.

Możesz rownież użyć socketów nieblokujących i wtedy nie musisz sie martwic timeoutami bo read albo cos odczyta do bufora albo zwroci -1 jesli jest problem z polaczeniem.
No i takie sockety pozwalaja jednemu wątkowi obsługiwać wielu klientów równocześnie. Ale to już inna bajka :)

• 20/12/2005 17:03
• 

• Git! 0

  Kit! 0

No dobra.. ale wiesz jak to zrobić w Javie? (bo my przesyłamy sobie obiekty, więc nie możemy po prostu czytać "coś"... musimy mieć już kompletny obiekt w buforze..:|)

• 21/12/2005 09:14
• 

• Git! 0

  Kit! 0

nie koniecznie,
dane mozesz wczytywać do tablicy bajtow a pozniej uzywajac ByteArrayOutputStream tworzyc z nich zbuforowany strumien.

mozna rownież napisac wlasną implementacje serializacji klasy

rozwiązań jest sporo i trzeba poprostu pokombinować.