Wo hast du das her? Wenn das der vollständige Quellcode ist, macht er definitiv keinen Sinn. Ohne ein else ist die erste Version volkommen sinnfrei, da man das if einfach streichen könnte ( ; am Ende der Zeile) und immer versucht wird zu lesen. Der zweite Ausschnitt ist auch nicht ganz korrekt, wenn man aber == 0 durch != 0 ersetzen würde, hätte man zumindest einen logisch funktionierendes Grundgerüst.
ich habe den code aus dem buch "Java als erste Programmiersprache", allerdings schon verändert. ursprünglich hieß es
Code:
while(input.available() == 0)
. Vielleicht habe ich auch nur nicht genau verstanden, was input.available heißen soll.
Ich dachte das bedeutet: Solange etwas vom clienten geschickt wird!
und deswegen habe ich darum eine while(true) schleife gemacht, die überprüft ob etwas gesendet wird, aber danach noch weiter läuft, damit der server auch was schicken kann.
Das ist da gar nicht gut erklärt! Und im Internet finde ich auch nichts gutes. Immer nur von server zu client oder andersrum.
Nein available() gibt zurueck wieviele Bytes verfuegbar sind. das heist available ==0 ist true wenn nichts verfuegbar ist.
in deiner zweiten If bedingung wird nur hineingegangen wenn keine Bytes vorhanden sind die gelesen werden koennen.
ich nehme mal an , dass deine wihle schleife vorher so aus gesehen hat
[c]while(input.available()==0) ;[/c]
das Semikolon zum schluss ist hier wichtig. Das Codesegment bedeutet naehmlich, dass der Server an der whileschleife solange haengt bis eine input available ist. (Peroenlich gefaellt mir so eine Loesung nicht, aber sie funktioniert)
vielen dank!
Ich habe das Semikolon so verstanden, dass alles was danachkommt in quasi in der while-Schleife ist!
Deswegen habe ich mich auch schon gewundert, warum das 0 sein muss! Will natürlich auch keinen Mist lernen, was wäre denn deiner Meinung nach eine bessere Möglichkeit?
Das muesstest du ja durch ausprobieren schon herausgefunden haben.
Aber dadurch kannst du nur einmal etwas von deinem Socket lesen. da danach der socket geschlossen wird und du die run methode verlaesst.
ich wuerde nicht auf available warten, sondern einfach die read methode aufrufen, da diesen den Thread solange blockiert bis eine Input vorhanden ist.
JavaDoc hat gesagt.:
Reads some number of bytes from the input stream and stores them into the buffer array b. The number of bytes actually read is returned as an integer. This method blocks until input data is available, end of file is detected, or an exception is thrown.
muss ich die/den socket denn schließen? was passiert denn wenn ich es nicht mache. warum überhaupt schließen, ich will doch die verbindung nicht trennen!
achso: Wäre es dann nicht sinnvoll Client auch von Thread erben zu lassen? Weil durch eine while(true) schleife ließen sich ja keine anderen methoden, zum senden, mehr aufrufen.
Ich würde einen Thread zum Lesen und einen für das Hauptprogramm verwenden.
Aber du musst bedenken, dass du mehr Speicher bereitstellst als du für vermutlich benötigst:
Code:
Länge im Stream geschrieben: 10
Länge vom Stream gelesen: 128
Da du einen Speicher mit 128 Bytes erzeugst und die bytes des Streams darüber hinein schreibst, wird zuerst der "Haupttext" und danach nur noch nullen als Chars im String stehen.Das könntest du mit einen trim lösen der die Null-Chars entfernt. Ich würde dir als Anfänger aber empfehlen auf BufferedReader zu setzen. Diese können von Haus aus den Text bis zum nächsten Zeilenumbruch lesen und zurückgeben.
Außerdem kannst du nur 128 Zeichen auf einmal lesen, das kannst du mit einer Schleife lösen.
habe ich das dann richtig verstanden, dass die ausgegebenen Strings die nullen beinhalten?
bei mir werden nämlich keine ausgegeben. Oder ist es eher ein Problem was man nicht sieht. Was ist denn der Nachteil wenn ich es nicht mache.
Ich muss jetzt leider los, aber danke für die Antowrten bisher! Spätestens morgen melde ich mich nochmal und probiere das mit dem Buffered Reader, falls das besser ist!
Da der Lesende nicht weiß, wie viele Daten ankommen kannst du die Länge mitübertragen, eine bestimmte Anzahl von Zeichen lesen, bis zu einen bestimmten Zeichen lesen oder dich direkt auf ein bestimmtes Protokoll einigen.
Der BufferedReader übernimmt das "Bis zu einen bestimmten Zeichen lesen" für einen.
So habe jetzt mein Programm erweitert und umgeschrieben. Vom Server zum Client kann ich super senden, nur andersrum leider nicht. Fehlermeldung anfangs:
Code:
java.lang.NullPointerException
at server.WorkerThread.run(Server.java:102)
Wüsste gerne, was nicht funktioniert. Der Fehler liegt ja anscheinend in der Klasse WorkerThread. Und ich habe auch dieses hier
Code:
while (input.available() == 0);
wieder eingebaut, heißt der wartet doch so lange bis etwas ankommt und warum kann er das dann nicht lesen? Und warum gibts schon eine Fehlermeldung bevor überhaupt was geschickt wurde?
Aber ich muss den doch übergeben oder nicht? Oder muss ein neuer erstellt werden?
Ich dachte senden und empfangen über den gleichen. und pro client ein socket?
Aber du speicherst nichts. Du schreibst die Socket-Variable die sowieso null ist in die selbe Socket-Variable. Und null + null ergibt leider nicht != null. :joke:
Ich habe das beim client im workerthread jetzt so gemacht, dass ein boolean namens read so lange true ist bis eine 0 geschickt wird und dann auf false.
wenn ich das richtig verstanden habe gestern, müsste das programm doch so lange in der while-schleife hängen, bis read nicht mehr erfüllt ist. Genauso wie beim 1. code, der funktionoiert.
Warum klappt es nicht so? So wie es funktioniert sieht es nämlich nicht sehr elegant aus! Achso und dass klappt auch nicht wenn da nicht system.out.print(""); drin steht! Die schleife müsste doch trotzdem ausgeführt werden oder nicht?