# Netzwerkprobleme bei mehreren Clients



## dweiner (5. Nov 2008)

Hallo, 

ich habe mir über Sockets, Streams etc. (TCP/IP) ein Netzwerk aufgebaut. Über dieses Netzwerk soll ein Experiment laufen, welches ca. 1 Stunde dauert. Ich habe das Programm bei mir auf dem Rechner mehrfach getestet (also Clients und Server auf localhost) - da lief alles reibungslos. Wenn mein Programm allerdings auf verschiedenen Rechnern abgespielt wird (z.B. Netzwerk mit 8 Clientrechnern), dann schmiert mein Programm irgendwann immer ab (also es werden z.B. beim Client irgendwelche Dinge angezeigt, die zu diesem Zeitpunkt gar nicht angezeigt werden sollen oder ein Client hängt sich auf und nix geht mehr). Auffällig ist, dass mein Programm immer zu unregelmäßigen Zeitpunkten ins Stocken gerät, so dass es schwierig ist einen Fehler im Programmcode zu lokalisieren. Mein Programm ist eigentlich auch relativ simpel aufgebaut: Die Clients schicken zu bestimmten Zeiten Nachrichten an den Server und dieser speichert die Daten in eine Datenbank ab. Also rein von der Logik in meinem Programm kann eigentlich nicht viel falsch sein (auf localhost funktioniert ja auch alles). 
Was ist denn wahrscheinlicher: Fehler oder schlechte Performance/Programmierstil in meinem Programmcode als Ursache des Übels oder ist es einfach generell schwierig ein Netzwerk mit 8 Clients reibungslos zu koordinieren? Ich habe auch das Gefühl, dass die Wahrscheinlichkeit eines Absturzes eklatant steigt je mehr Clients angebunden sind und je mehr Daten hin-und hergeschickt werden. Habt ihr schon derartige Erfahrungen gemacht? Gibt es irgendwelche Geheimtipps (z.B. zur Verbesserung des Programmcodes) um die Performance der Netzwerkkommunikation zu verbessern?

Bitte um eure Einschätzungen dazu und zahlreiche Rückantworten!

Danke im voraus!


Gruß
Dominik


----------



## tuxedo (5. Nov 2008)

Weißt du was mich ärgert?

Dass man den Leuten immer alles aus der Nase ziehen muss ;-)

Wenn irgendwas abstürzt, dann kommt eine Exception. Das ist nix magisches, unerklärliches und auch nix "von der dunklen Seite der Macht". Nein, das ist in den meisten Fällen das Ding, das dich zum Fehler und damit auch zur Lösung bringt.

Wenn die Anwendung stillschweigend stirbt, dann hast du entweder in diversen catch-Blöcken keinen Stacktrace ausgebenen und auch nicht geloggt, oder die JVM ist auf der nativen Seite abgeraucht. Aber dann hast du ein "hs_err-irgendwas" Log im Arbeitsverzeichnis der Anwendung liegen.

Letzteres ist aber sehr selten wenn man nicht gerade mit JNI Dingen rumspielt.

Wenn sich die Anwendung aufhängt, also nicht gleich terminiert, dann hast du vermutlich eien Deadlock gebastelt. Da kommt man mit "jconsole" oder allgemein mit Profilern dahinter wo der Hund begraben ist.

- Alex


----------



## FArt (5. Nov 2008)

Die Wahrscheinlichkeit ist hoch, dass es sich um Programmierfehler handelt.

Die Wahrscheinlichkeit ist auch hoch, dass es um Synchronisationsprobleme geht, möglich ist auch der unsaubere Umgang mit Ressourcen (z.B. Sockets).

Was hilft:
* mit Verstand den Code anschauen, besonders die Stellen wo konkurrierene Zugriffe zu erwaten sind
* sinnvolles Logging einbauen und die Logfiles auswerten


----------



## dweiner (5. Nov 2008)

Danke schon mal für diese ersten Einschätzungen! Sinnvolles Logging würde in diesem Fall z.B. bedeuten den Befehl "synchronized" an heiklen Stellen einzubauen, oder?

Gruß
Dominik


----------



## tuxedo (5. Nov 2008)

Logging hat nix mit "synchronized" zu tun. Wozu gibts Log4J und Java.util.logging ?!

Unbedachter einsatz von "synchronized" schadet mehr als dass es hilft: Codeteile werden unnötig oder fälschlicherweise so blockiert, dass andere Codeteile warten müssen bis sie zugriff haben.

Wie FArt schon schrieb:

- Anständigen Logoutput produzieren
- Diesen analysieren
- ggf. Profiler oder JConsole verwenden um Deadlocks aufzuspüren

gruß
Alex


----------

