OutputStream kommt nicht an

Tueftler

Mitglied
Konstellation: Fritzbox, zwei Laptops, einer nur mit einem Clientprogramm, der andere mit einem Server- und einem Clientprogramm. Die Clientprogramme sind auf beiden Rechnern identisch.

Problem: Die Client-Server-Kommunikation läuft problemlos, wenn Client und Server auf unterschiedlichen Rechnern laufen. Rufe ich den Server aber vom Client auf dem Server-Laptop auf, so ist nur bis zum letzten Senden des Server-OutputStreams alles ok. Den OutputStream sendet der Server zwar, aber der Client empfängt nichts.

Meine Vermutung: Der Server streamt ins Nirwana (ohne Fehlermeldung). Aber warum?

Hier der der Servercode:
[CODE lang="java" title="Aufruf"]new Thread(){
public void run(){
new LogInServer();
}
}[/CODE]
Thread, da anschließend noch andere Server aufgerufen werden.

[CODE lang="java" title="LogInServer:"]try{
ServerSocket serverSocket= new ServerSocket(70);
while(true){
Socket clientSocket = serverSocket.accept();
new LogInThread(clientSocket);
}
}catch(IOException e){...}[/CODE]


LogInThread:
Java:
...
public void run(){
    try{
        String clientsLaptopName = "";
        InputStream in = clientSocket.getInputStream();
        OutputStream out = clientSocket.getOutputStream();
        byte[] buffer = new byte[in.available()]
        in.read(buffer)
        for(byte b:buffer){
            clientsLaptopName += (char)b;
        }

        // Es folgt Registrierungs-Check und Username ermitteln
        // Das Ergebnis wird in den String 'msg' gespeichert

        byte[] data = msg.getBytes();
        out.write(data);
        out.flush();

        in.close();
        out.close()
        clientSocket.close();

    }catch(IOException e){e.printStackTrace();}

Client:
Java:
    try{
        adrIn = InetAddress.getByName("ServerLaptop");
        localIn = InetAddress.getLocalHost();
        localStrIn = localIn.getHostName();
        sockIn = new Socket(adrIn,70);
        
        // Namen des Client-Laptop schicken
        byte[] data= localStrIn.getBytes();
        out.write(data);

        //Message vom Server empfangen - und das klappt nicht
        String msg="";
        int c;
        while(c = in.read() != -1){
            msg += (char)c;
        }

    }catch(IOException e){e.printStackTrace();}
 
K

kneitzel

Gast
Hast Du dem Server entsprechend mitgeloggt, dass der server die Nachricht vom Client richtig empfangen hat?
Java:
        byte[] buffer = new byte[in.available()]
        in.read(buffer)
        for(byte b:buffer){
            clientsLaptopName += (char)b;
        }
sieht mir nicht wirklich korrekt aus - wenn die Nachricht vom Client noch nicht (komplett) empfangen wurde, dann ist da evtl. auch noch nichts zu lesen. Das in.available() wäre also etwas, das ich da prüfen würde ...

Generell ist bei so Protokollen zu bedenken, dass die Bytes nach und nach ankommen können. Du hast da jetzt erst einmal kein wirkliches Erkennungszeichen, bis wohin eine Nachricht geht. Das könnte man z.B. zeilenorientiert machen. Dann musst Du da auch nicht von Hand dir die Bytes vom String holen und so, da der Reader / Writer das dann schon machen würden.
Trennzeichen wäre dann das Newline Zeichen und so Du eine ganze Zeile einliest, blockiert der Thread, bis das angekommen ist.

Dann fürchte ich, dass die Codierung von Bytes -> String so nicht korrekt ist. Ein Zeichen kann mit bis zu 4 Bytes codiert werden - abhängig vom Charset. Das getBytes() nutzt das default Charset vom System - da würde ich auf jeden Fall ein spezielles charset vorgeben.

Auf der Client-Seite ist es nicht ganz so wild. Da liest Du ja, bis der Stream geschlossen wurde. Da vermute ich jetzt erst einmal kein Problem.

Das wären so meine Auffälligkeiten.
 

fhoffmann

Top Contributor
In LogInThread schließt du die Verbindung zum Client clientSocket.close(); unmittelbar nach dem Senden out.write(data);. Möglicherweise ist der Server mit dem Senden der Nachricht noch gar nicht fertig, wenn du die Verbindung schließt.
 

Jw456

Top Contributor
wie es ausschaut benutzt du auf dem Client den localhost benutze die ip von der Netzwerkkarte. Die sie im netz hat.
Die benuzt auch der Server.

localIn = InetAddress.getLocalHost();
ist bestimmt 127.0.0.1
 
Zuletzt bearbeitet:
K

kneitzel

Gast
In LogInThread schließt du die Verbindung zum Client clientSocket.close(); unmittelbar nach dem Senden out.write(data);. Möglicherweise ist der Server mit dem Senden der Nachricht noch gar nicht fertig, wenn du die Verbindung schließt.
Nach meinem Verständnis sollten die Daten aber durch das flush() geschrieben worden sein.
 

Jw456

Top Contributor
Nach meinem Verständnis sollten die Daten aber durch das flush() geschrieben worden sein.
ja auf die IP die der Rechner im Netz hat. empfangen will er auf Localhost .


Kommt dann auf die Einstellung des Rechners an ob das weiter geleitet wird.

Der Code kann ja nicht direkt falsch sein wenn es auf unterschiedlichen Rechnen geht.
 
K

kneitzel

Gast
ja auf die IP die der Rechner im Netz hat. empfangen will er auf Localhost .


Kommt dann auf die Einstellung des Rechners an ob das weiter geleitet wird.

Der Code kann ja nicht direkt falsch sein wenn es auf unterschiedlichen Rechnen geht.
Nein, das ist so komplett falsch. Der Server bindet auf jeden Fall an die externe IP, denn von anderen Rechnern funktioniert es. Und selbstverständlich kann er sich selbst über die externe IP problemlos erreichen.

Und dann sind das TCP/IP Verbindungen und da ist eine Verbindung aufgebaut. Und wenn die Verbindung von externerIp zu externerIp geht, dann ist das auch in jedem Paket eben genau so abgebildet. Da wird dann bei einer bestehenden Verbindung nicht plötzlich an eine andere IP wie 127.0.0.1 etwas gesendet.

Und natürlich kann der Code falsch sein. Das muss er sogar, denn sonst würde er ja funktionieren. Und es gibt zwei Vermutungen in diesem Zusammenhang. Einmal meine, dass da Daten nicht wirklich korrekt übertragen wurden (incl. dem Hinweis zum Encoding) und von @fhoffmann die Überlegung, ob es am zu schnellen schließen liegt (unabhängig davon ob ich dies glaube oder nicht).

Meine Vermutung ist ersteres. Denn es läuft auf einem System, Client und Server teilen sich die vorhandenen Ressourcen und die Umschaltung zwischen Threads erfolgt immer in Scheiben (bzw. wenn der Thread blockiert).

Client baut Verbindung auf - blockiert weil Warten auf Server
Server nimmt an, ehe der Client da wieder Ausführung bekommt, schaut der Server nach empfangenen Zeichen. Diese sind 0. Er liest 0 Zeichen und geht dann die Nachricht bauen. Was da dann bei raus kommt: keine Ahnung ...
Client schickt dann natürlich früher oder später auch Daten ...

So ein Ablauf hört sich für mich durchaus plausibel an. Bestätigen kann man sowas durch ein Logging. Dann weiss man ja, was der Server vom Client empfangen hat...
 

Jw456

Top Contributor
Nein, das ist so komplett falsch. Der Server bindet auf jeden Fall an die externe IP, denn von anderen Rechnern funktioniert es. Und selbstverständlich kann er sich selbst über die externe IP problemlos erreichen.

Und dann sind das TCP/IP Verbindungen und da ist eine Verbindung aufgebaut. Und wenn die Verbindung von externerIp zu externerIp geht, dann ist das auch in jedem Paket eben genau so abgebildet. Da wird dann bei einer bestehenden Verbindung nicht plötzlich an eine andere IP wie 127.0.0.1 etwas gesendet.

Und natürlich kann der Code falsch sein. Das muss er sogar, denn sonst würde er ja funktionieren. Und es gibt zwei Vermutungen in diesem Zusammenhang. Einmal meine, dass da Daten nicht wirklich korrekt übertragen wurden (incl. dem Hinweis zum Encoding) und von @fhoffmann die Überlegung, ob es am zu schnellen schließen liegt (unabhängig davon ob ich dies glaube oder nicht).

Meine Vermutung ist ersteres. Denn es läuft auf einem System, Client und Server teilen sich die vorhandenen Ressourcen und die Umschaltung zwischen Threads erfolgt immer in Scheiben (bzw. wenn der Thread blockiert).

Client baut Verbindung auf - blockiert weil Warten auf Server
Server nimmt an, ehe der Client da wieder Ausführung bekommt, schaut der Server nach empfangenen Zeichen. Diese sind 0. Er liest 0 Zeichen und geht dann die Nachricht bauen. Was da dann bei raus kommt: keine Ahnung ...
Client schickt dann natürlich früher oder später auch Daten ...

So ein Ablauf hört sich für mich durchaus plausibel an. Bestätigen kann man sowas durch ein Logging. Dann weiss man ja, was der Server vom Client empfangen hat...
OK

adrIn = InetAddress.getByName("ServerLaptop");
sockIn = new Socket(adrIn,70);

er hat die adresse erfragt
wo nutzt er das bekomme socket?

wo hat er den in und out Steam erstellt mit den socket "sockln" ?
hoffe er benutzt nicht die in und out vom Server.
 

fhoffmann

Top Contributor
Denn es läuft auf einem System, Client und Server teilen sich die vorhandenen Ressourcen und die Umschaltung zwischen Threads erfolgt immer in Scheiben (bzw. wenn der Thread blockiert).
Aber das würde doch auch meine Idee unterstützen:
- Der Server sendet die Nachricht und beendet die Verbindung.
- Nun bekommt der Client Rechenzeit: Er kann die Nachricht vom Server nicht mehr lesen, weil die Verbindung schon geschlossen ist.
 
K

kneitzel

Gast
Aber das würde doch auch meine Idee unterstützen:
- Der Server sendet die Nachricht und beendet die Verbindung.
- Nun bekommt der Client Rechenzeit: Er kann die Nachricht vom Server nicht mehr lesen, weil die Verbindung schon geschlossen ist.
Hier bin ich jetzt nicht der Netzwerk Experte. Aber das läuft ja bereits auf Betriebssystem Ebene (oder teilweise sogar direkt in der Hardware - Die Netzwerkkarte macht schon sehr viel alleine).

Aber das kann man ja durchaus einmal austesten ... gib mir mal ein paar Minuten. Das Interessiert mich jetzt wirklich :)
 
K

kneitzel

Gast
Ok, das was ich testen wollte um sicher zu gehen: Selbst wenn der Server Stream und Socket geschlossen hat, hat der Client die Daten im Puffer.

Dazu habe ich einfach mal eine Testklasse geschrieben, die zwei Threads startet. Einmal Server und einmal Client.

Der Server öffnet einen Port, nimmt eine Verbindung an, schreibt ein "Hallo!" und macht sofort flush und close.
Der Client wartet kurz (So kann der Server sich aufbauen. Dann verbindet er sich, Schläft wieder (So kann der Server darauf reagieren!) Und dann liest er einmal alle Daten.

[CODE lang="java" title="TcpIpTest Klasse"]import java.io.IOException;
import java.io.InputStream;
import java.io_OutputStream;
import java.net.InetAddress;
import java.net.ServerSocket;
import java.net.Socket;
import java.nio.charset.StandardCharsets;

public class TcpIpTest {
public static void main(String[] args) {
Thread server = new Thread(TcpIpTest::serverWorker);
server.start();

Thread client = new Thread(TcpIpTest::clientWorker);
client.start();
}

private static void serverWorker() {
try {
System.out.println("Server: opening port!");
ServerSocket serverSocket = new ServerSocket(1234);
Socket client = serverSocket.accept();
System.out.println("Server: Client connected!");
OutputStream out = client.getOutputStream();
out.write("Hallo!".getBytes(StandardCharsets.UTF_8));
System.out.println("Server: 'Hallo!' written!");
out.flush();
System.out.println("Server: flushed!");
out.close();
System.out.println("Server: out closed!");
client.close();
System.out.println("Server: client closed!");
serverSocket.close();
System.out.println("Server: server socket closed!");
} catch (IOException ex) {
ex.printStackTrace();
}
}

private static void clientWorker() {
try {
System.out.println("Client: Sleeping...");
Thread.sleep(500);
System.out.println("Client: Connecting...!");
Socket socket = new Socket(InetAddress.getLocalHost(), 1234);
System.out.println("Client: Connected!");
InputStream in = socket.getInputStream();
System.out.println("Client: Sleeping...");
Thread.sleep(500);
System.out.println("Client: Reading Data ...");
System.out.println("Received: " + new String(in.readAllBytes(), StandardCharsets.UTF_8));
socket.close();
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
[/CODE]

Die Ausgabe zeigt, dass der Client das Hallo! noch lesen kann:
Code:
Server: opening port!
Client: Sleeping...
Client: Connecting...!
Client: Connected!
Client: Sleeping...
Server: Client connected!
Server: 'Hallo!' written!
Server: flushed!
Server: out closed!
Server: client closed!
Server: server socket closed!
Client: Reading Data ...
Received: Hallo!

Habe auch einmal das Sleep direkt hinter dem new Socket plaziert ... das ändert an der Problematik nichts. Also der InputStream spielt keine Rolle - das kann auch warten.

Hintergrund ist, dass die Socket Klasse in Java ja auch nur auf den Sockets vom Betriebssystem aufsetzt. Und da sind entsprechende Puffer.

Und was passiert denn, wenn man sich den Traffic anschaut?
Server sendet die Daten (durch das flush vom Stream geht es an den Socket).
Server macht das close() das bedeutet aber, dass die Verbindung abgebaut werden soll. Also schickt der Server an den Client: Hey - ich will die Verbindung schließen! Darüber unterhalten sich Server und Client ... es gibt also auch da ein Handshake für.

Ich habe diese Handshakes mal heraus gesucht:
Ich hatte mal eine bessere Seite, aber die finde ich nicht. Die hatte ich vor kurzem @Jw456 gegeben in einem anderen Thread wo ich geantwortet hatte ... aber da sieht man das auch, was da zum Verbindungsabbruch hin und her geht.
 

Tueftler

Mitglied
Was passiert in dem Programm überhaupt? Also: der Client baut die Verbindung zum Server auf und schickt ihm den Namen des Clientrechners. Der Server schaut in einer HashMap nach, ob der Clientrechner (key) registriert ist. Falls ja, liefert die Map als value den Usernamen. Diesen Namen soll der Server über den OutputStream an den Client zurückschicken.

Zu Euren Anregungen:
Stimmt, in.available ist zur Größenbestimmung des byte Arrays unsauber (werde ich noch ändern), aber beim debuggen mit Eclipse bekomme ich da immer den richtigen Namen des Clientrechners übermittelt und der Server ist bisher nie darüber gestolpert. Ist es ein Denkfehler, wenn ich annehme, dass der InputStream des Servers hängen bleiben würde, wenn der buffer zu klein wäre, würde dann nicht eine IndexOutOfBounds geworfen? Beides passiert nicht.

zum problematischen getBytes(). Ich verwende ja keine CharacterStreams sondern ausschließlich ByteStreams und hoffe, damit das Problem der charsets umgangen zu haben. Ist das falsch?

zum clientSocket.close(): Wenn ich clientseitig den Socket schließe, müsste eigentlich serverseitig der Thread für den Garbage Collector freigegeben werden. Ich bin aber unsicher, ob damit auch wirklich der Socket sauber geschlossen wird. Deshalb der close() im Server. Nehme ich die Zeile aus dem Code, empfängt der Client trotzdem nicht den OutputStream des Servers.

Zum LocalHost: Die InetAddress von LocalHost nutze ich ausschließlich clientseitig und da auch nur, weil ich zu faul bin, mir einen eleganteren Weg zu suchen, um an den Rechnernamen des Clients zu kommen. Den Server spreche ich über den Namen des Serverrechners an (getByName("ServerLaptop"))

Zu den Streams: Stimmt, die Zeilen für in und out fehlen im abgedruckten Code (Asche auf mein Haupt) aber nur hier, sonst würde ja gar nichts gehen.
 
K

kneitzel

Gast
Das Problem ist, dass die Daten ja noch nicht da sein müssen. Du liest genau ein mal. Und das was dann da ist, das bekommst Du. Aber du hast Keinerlei Kontrolle, dass dies die ganze Nachricht ist!

Wenn Der Text nicht in einem Paket untergebracht werden kann, dann ist evtl. erst ei Teil da. Daher brauchst Du ein sauberes Protokoll.

Meine Empfehlung ist daher, auf dem InputStream / OutputStream einen BufferedReader und ein PrintWriter.
Dann kannst Du einfach readLine bzw. println nutzen und du hast wirklich die Zeile, die gesendet wurde, am Stück.
Und dann kannst Du auch das Encoding festlegen:
BufferedReader inReader = new BufferedReader(new InputStreamReader(socket.getInputStream(), "UTF-8"));
PrintWriter writer = new PrintWriter(new OutputStreamWriter(socket.getOutputStream(), "UTF-8"));

Ob das schon Dein Problem behebt kann ich nicht sagen. Aber das wäre eine Verbesserung.
 

Barista

Top Contributor
Stimmt, in.available ist zur Größenbestimmung des byte Arrays unsauber
TCP-Streams sind prinzipiell endlos (ausser der Stream wird vom Partner geschlossen).

Also entweder bis zum Schliessen des Streams blockieren (macht die Methode int read() )

oder ein spezielles Endezeichen für den Client-Laptopnamen einfaühren, z. Bsp. newline.
 

Tueftler

Mitglied
Hast Du dem Server entsprechend mitgeloggt, dass der server die Nachricht vom Client richtig empfangen hat?
Was meint Ihr mit mitloggen? Was ich gemacht habe: Nach dem Auslesen des InputStreams habe ich System.out.println(clientsLaptopName) eingebaut. Ergebnis: alles korrekt angekommen (Vom Client zum Server). Part mit meiner Registrierung: einwandfrei. byte[] data für den OutputStream korrekt gefüllt. out.write(data) (vom Server zum Client) bringt keinerlei Fehlermeldung.
Hab jetzt aber den Rat befolgt und nicht die Bytes ausgelesen, sondern den BufferedReader eingesetzt und siehe da: Alles läuft. Vielen Dank für Eure Hilfe
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
L Socket Wie kann ich checken ob ein User eine Nachricht per Outputstream an den Server gesendet hat? Netzwerkprogrammierung 1
S FTP OutputStream Timed out Netzwerkprogrammierung 2
D Socket Socket OutputStream leeren? Netzwerkprogrammierung 3
Seikuassi Socket CipherInput/OutputStream empfängt nichts Netzwerkprogrammierung 23
C Inhalt einer .JPG Datei in einen OutputStream schreiben? Netzwerkprogrammierung 10
E Socket Outputstream - chunks groeße bestimmen. Netzwerkprogrammierung 3
T Socket ObjectIn/OutputStream Netzwerkprogrammierung 3
A Socket BufferedReader.readLine() blockiert bis ein im Socket OutputStream was gesendet wird ... Netzwerkprogrammierung 9
M Socket InputStream sendet ausgaben von OutputStream zurück Netzwerkprogrammierung 2
D Inputstream to Outputstream Netzwerkprogrammierung 3
T Outputstream Byte-Array senden Netzwerkprogrammierung 2
H Input-/OutputStream Frage Netzwerkprogrammierung 6
O Mehrere Datei per DataInput/OutputStream über Socket Netzwerkprogrammierung 12
P Probleme mit OutputStream Netzwerkprogrammierung 7
M Verbindung über Proxy// Problem mit Outputstream bei URLConn Netzwerkprogrammierung 5
PAX Outputstream von anderem Thread verwenden lassen Netzwerkprogrammierung 5
T Filter für Input UND OutputStream Netzwerkprogrammierung 4
Y Inhalt aus Textfield in OutputStream packen Netzwerkprogrammierung 4
bummerland Cookies über OutputStream senden Netzwerkprogrammierung 2
T String von Client zu Server kommt nicht an Netzwerkprogrammierung 92
Thallius JDBC getConnection kommt nicht zurück Netzwerkprogrammierung 1
M Byte Array kommt nicht an Netzwerkprogrammierung 0
M Nur die erste Nachricht kommt beim Server an Netzwerkprogrammierung 11
J Nachricht kommt erst nach beendigung der Anwendung an Netzwerkprogrammierung 4
C Über welchen Netzwerkadapter kommt mein receive? Netzwerkprogrammierung 15
K TrafficClass eines UDP Pakets kommt beim Empfänger nicht an Netzwerkprogrammierung 5
B Nachricht über Sockets kommt nicht an Netzwerkprogrammierung 8
B InetAddress.getHostAddress() wo kommt die IP Auslösung her? Netzwerkprogrammierung 6
O BufferedReader.readline kommt nicht zurück Netzwerkprogrammierung 7
K Chat: Verbindung kommt nicht zu stande Netzwerkprogrammierung 6
JavaDevOp Socket Status von UDP-Port prüfen (PortUnreachableException funktioniert nicht?) Netzwerkprogrammierung 32
A Bei FTP Übertragung wird Datei nicht komplett übertragen Netzwerkprogrammierung 2
B Multicast-Nachrichten-Empfang funktioniert nicht Netzwerkprogrammierung 5
M JAX-WS unter Java 17 plötzlich nicht mehr möglich Netzwerkprogrammierung 5
S BufferedStream funktioniert nicht immer Netzwerkprogrammierung 7
G UDP Packet empfangen funktioniert nicht. Netzwerkprogrammierung 16
L30nS RMI RMI-Server kann Dialog nicht volkommen anzeigen Netzwerkprogrammierung 2
L Server-Socket liest Input-Stream nicht Netzwerkprogrammierung 5
Tobero Java serversocket nicht nur zuganglich für localhost Netzwerkprogrammierung 6
S .jar läuft local, aber nicht remote (SSH/Terminal) Netzwerkprogrammierung 10
Z Kann nicht Daten vom Server lesen Socket Netzwerkprogrammierung 10
J SSL haut nicht hin Netzwerkprogrammierung 3
A Socket-Anwendung (BufferedWriter/Reader liest nicht aktuellen Wert) Netzwerkprogrammierung 6
platofan23 Socket Java Socket mit DynDns nicht erreichbar Netzwerkprogrammierung 6
J Wechsel auf Jdk13 , sfpt funktionier nicht mehr Netzwerkprogrammierung 2
Dann07 Proxy funktioniert nicht so wie gewünscht! Netzwerkprogrammierung 18
B RESTful API weiß nicht weiter Netzwerkprogrammierung 2
L Kann VM nicht ueber Host Name finden Netzwerkprogrammierung 0
V Ich finde den Fehler nicht... Netzwerkprogrammierung 2
H Einfacher Server funktioniert nicht Netzwerkprogrammierung 1
T HTTPS-Requests an Server: POST-Parameter kommen nicht an Netzwerkprogrammierung 5
S Socket Webserver mit SSLSocket geht nicht Netzwerkprogrammierung 1
P RMI stub wird nicht gefunden Netzwerkprogrammierung 8
N Test Servlet funktioniert nicht Netzwerkprogrammierung 11
M com.google.gson wird nicht erkannt Netzwerkprogrammierung 2
M Socket Server antwortet dem Client nicht Netzwerkprogrammierung 6
J FTP Upload über Proxy funktioniert nicht Netzwerkprogrammierung 1
C Mini Client-Server-Anwendung funktioniert nicht Netzwerkprogrammierung 8
D FTP ListNames() funktinoniert nicht richtig Netzwerkprogrammierung 2
KingSquizzi3 Website parsen mit Hilfe von jsoup funktioniert nicht Netzwerkprogrammierung 3
J Java Server empfängt php inhalt nicht Netzwerkprogrammierung 1
V TCP Client funktioniert auf Emulator aber nicht auf Smartphone Netzwerkprogrammierung 5
P RMI - Neue eigene Instanz für jeden Aufruf auf nicht serialisierbares Objekt - wie? Netzwerkprogrammierung 0
F FTP FTPClient Datei lässt sich nicht öffnen Netzwerkprogrammierung 4
F Reader/ Writer werden nicht geschlossen Netzwerkprogrammierung 2
Z Verbindung zwischen 2 Rechnern über ServerSockets nicht möglich Netzwerkprogrammierung 3
F Java Server Scanner oder InputStream kann nicht gelsesen werden! Netzwerkprogrammierung 6
R Socket bei server.accept(); gehts nicht weiter Netzwerkprogrammierung 2
K Server liest Daten nicht Netzwerkprogrammierung 6
N RMI "RMI über Lan funktioniert nicht" & "RMI-Server im Lan scannen" Netzwerkprogrammierung 13
G Mail senden funktioniert nicht mit SSL Netzwerkprogrammierung 7
L IText mit Servlets, funktioniert nicht Netzwerkprogrammierung 0
E Gruppenchat: Über HTTPS oder nicht? Netzwerkprogrammierung 5
P nanoHttp upload.html page lädt nicht Netzwerkprogrammierung 4
X Daten können nicht sofort empfangen werden Netzwerkprogrammierung 1
D TCP Socket funktioniert nicht richtig Netzwerkprogrammierung 3
K ByteArray über Netzwerk senden klappt nicht Netzwerkprogrammierung 5
D Socket UDP Client reagiert nicht auf spontane Meldungen Netzwerkprogrammierung 5
C Servlet erstellen klappt nicht Netzwerkprogrammierung 3
A Socket Socket-Problem - Object wird nicht übertragen Netzwerkprogrammierung 3
S Socket (client) verbindet nicht Netzwerkprogrammierung 6
B Methoden und Konstruktoren von Java.net package werden nicht geladen Netzwerkprogrammierung 2
L Email versenden mit Java funktioniert nicht, Fehlermeldungen: MessagingException & SocketException Netzwerkprogrammierung 10
L Server anpingen (Pingzeit) ?? Pingzeit wird nicht verändert Netzwerkprogrammierung 6
C Portscanner funktioniert nicht! Netzwerkprogrammierung 8
M JSP wird im gesamten Projekt nicht neugeladen Netzwerkprogrammierung 3
B HTTP Webseite unter IP-Addresse nicht aufrufbar - unter Domain schon Netzwerkprogrammierung 9
K Chatprogramm - Server funktioniert nicht Netzwerkprogrammierung 5
A Socket ASCii Zeichen werden nicht per udp übermittelt. please help . Netzwerkprogrammierung 6
J Erster Server-Client läuft auf lokalem Rechner problemlos. Zwei Rechner über das Internet nicht Netzwerkprogrammierung 8
H HTTP Header Response kann nicht ausgelesen werden Netzwerkprogrammierung 4
K Socket InputStream wird nicht erzeugt Netzwerkprogrammierung 4
G FTP FTP-Client funktioniert nicht bei Modem-Verbindungen Netzwerkprogrammierung 8
R Socket SSL-Connect in Servlet - keystore wird nicht gefunden Netzwerkprogrammierung 2
D JNLP über Webstart funktioniert nicht... Netzwerkprogrammierung 2
V Socket Objekte werden nicht aktualisiert Netzwerkprogrammierung 2
F Kann Klasse nicht zu Servlet casten Netzwerkprogrammierung 5
T Server und Client verbinden nicht Netzwerkprogrammierung 6
M HTTP File Upload mit Prozessbar Funktioniert nicht. Netzwerkprogrammierung 8
K Socket byte Schleife beendet nicht Netzwerkprogrammierung 9

Ähnliche Java Themen

Neue Themen


Oben