Socket SocketException: Connection reset

[VfL_Freak]

Hallo zusammen,
habe seit gestern ein böses Problem mit der genannten SocketException ....

Zuerst mal der Code:

public byte[] CommunicateData( byte[] RQB, String strIP, int nPort ) 
throws IOException 
{
      byte[] blwPBuffer = null;
      SocketAddress sockaddr = new InetSocketAddress( strIP, nPort );
      Socket csock = new Socket();
      csock.connect( sockaddr, m_REPSOCKETTIMEOUT );
      csock.setSoTimeout( m_REPSOCKETTIMEOUT );
      OutputStream cout = csock.getOutputStream();


      InputStream cin = csock.getInputStream();  // tritt hier auf !!!


      cout.write( RQB );
      byte[] blwPBufferTemp = new byte[MAXBUFFERLEN];
      byte[] blwPBufferHeader = new byte[16];
      int len = cin.read( blwPBufferHeader, 0, 16 );
      int nsize = 0;
      if (blwPBufferHeader[0] == BUFFER_START) 
      {
        nsize = ByteHelper.getRSPDataSize( blwPBufferHeader );
        int lenneu = 0;
        blwPBuffer = new byte[BUFFER_OFFSET + 1 + nsize];
        
        for (int n = 0; n < BUFFER_OFFSET; n++) 
        {
        	blwPBufferTemp[n] = blwPBufferHeader[n];
        }
        
        while( (nsize + BUFFER_OFFSET) > len ) 
        {
        	lenneu = cin.read( blwPBufferTemp, len, (nsize - len + BUFFER_OFFSET) );
        	len += lenneu;
        }
        
        for( int k = 0; k < len; k++ ) 
        {
        	blwPBuffer[k] = blwPBufferTemp[k];
        }

        cin.close();
        cout.close();
        csock.close();
        WorkerErrorStatus.getInstance().setErrorWS( com.gselectronic.worker.status.IWorkerErrorStatus.WORKERERRORSTATUS_NOERROR );
      }
    return blwPBuffer;
  }

Das Ganze tritt in einer funktionierenden Anwendung auf, die hier bei uns im Hause ca. 40 - 50 mal problemlos läuft.
Interessanterweise jedoch dabei nur auf genau drei PCs, die allesamt in den letzten Tagen entweder neu aufgesetzt wurden oder komplett neu sind. Die Java-Version ist überall 1.6.0_29. Ich habe bei einem der drei Rechner dann mal auf Java 1.6.0_30 upgedatet, aber leider ohne Erfolg ....

Leider liefert eine Websuche hier weder Erklärungen noch mögliche Ursachen.
Deswegen hoffe ich, ggf. hier Hilfe zu finden !

Gruß
Klaus

EDIT: es handelt sich durchweg um Rechner mit WIN XP SP3

 

[dayaftereh]

Hey, Versuch mal erst den InputStream zu öffnen und dann den OutputStream!

 

[VfL_Freak]

Moin,

na, ok, kann ich am Montag mal versuchen (bin derzeit nicht im Büro).
Wenn gleich ich mir nicht viel davon verspreche, da es in der bisherigen Version ja problemlos seit ca. etlichen Jahren gelaufen hat.

Irgendwas muss IMHO rechnerseitig durch das Neuaufsetzen resp. -einrichten geändert haben ... nur was ?

Gruß
Kalus

 

[VfL_Freak]

Mist, sehe gerade, dass ich vorhin im ersten Post die falsche Stelle bezeichnet habe!
Es passiert natürlich beim READ !!

public byte[] CommunicateData( byte[] RQB, String strIP, int nPort ) 
throws IOException 
{
      byte[] blwPBuffer = null;
      SocketAddress sockaddr = new InetSocketAddress( strIP, nPort );
      Socket csock = new Socket();
      csock.connect( sockaddr, m_REPSOCKETTIMEOUT );
      csock.setSoTimeout( m_REPSOCKETTIMEOUT );
      OutputStream cout = csock.getOutputStream();
      InputStream cin = csock.getInputStream();
      cout.write( RQB );
      byte[] blwPBufferTemp = new byte[MAXBUFFERLEN];
      byte[] blwPBufferHeader = new byte[16];


      int len = cin.read( blwPBufferHeader, 0, 16 );    // tritt natürlich HIER auf !!!


      int nsize = 0;
      if (blwPBufferHeader[0] == BUFFER_START) 
      {
        nsize = ByteHelper.getRSPDataSize( blwPBufferHeader );
        int lenneu = 0;
        blwPBuffer = new byte[BUFFER_OFFSET + 1 + nsize];
        
        for (int n = 0; n < BUFFER_OFFSET; n++) 
        {
            blwPBufferTemp[n] = blwPBufferHeader[n];
        }
        
        while( (nsize + BUFFER_OFFSET) > len ) 
        {
            lenneu = cin.read( blwPBufferTemp, len, (nsize - len + BUFFER_OFFSET) );
            len += lenneu;
        }
        
        for( int k = 0; k < len; k++ ) 
        {
            blwPBuffer[k] = blwPBufferTemp[k];
        }
 
        cin.close();
        cout.close();
        csock.close();
        WorkerErrorStatus.getInstance().setErrorWS( com.gselectronic.worker.status.IWorkerErrorStatus.WORKERERRORSTATUS_NOERROR );
      }
    return blwPBuffer;
  }

Gruß
Klaus

 

[ESCS]

Wie die Exception es schon sagt, die Verbindung wurde "resettet". Scheint also von der Gegenseite geschlossen worden zu sein.

 

[VfL_Freak]

Moin,

Wie die Exception es schon sagt, die Verbindung wurde "resettet". Scheint also von der Gegenseite geschlossen worden zu sein

Nun ja - das Serverprogramm arbeitet das Kommando, dass o.g. JavaClient aus gesendet wird, ab und gibt dann einen Byte-Buffer zurück. Sollte eigentlich die Socketverbindung nicht wirklich beeinflussen!
Zudem: warum tritt dass dann nur auf den drei neuen resp. neu aufgesetzten PCs auf ?

Ich hatte zwischenzeitlich auch im Serverprogramm beim betroffenen Kommando einige Ausgaben in ein Logfile eingebaut. Sah dabei nur, dass das Kommando von Serverprogramm sauber bis zu Ende abgearbeitet wurde und der Ergebnisbuffer sauber rausgeschickt wurde.
Während des Loggens trat der Fehler nur noch sporadisch auf und seitdem die Logs raus sind, gar nicht mehr ....

Ist alles seeehr seltsam :-(

Gruß
Klaus

EDIT:

Versuch mal erst den InputStream zu öffnen und dann den OutputStream

Hatte auch keinen Effekt - zumal die Reihenfolge der Deklarationen doch eigentlich egal sein sollte, oder ??

 

[ESCS]

Post mal bitte den Quelltext des Servers.

 

[VfL_Freak]

Moin,

erstmal Danke für Deine Antwort 🙂

Den Code kann ich frühestens am Montag posten, da ich im Moment meinen wohlverdienten Resturlaub genieße und von hier aus keinen Zugriff auf die Sourcen habe.

Das problem wird aber sein, dass das gesamte Komando, was dort bearbeitet wird, etwa 6000 - 8000 Zeilen umfasst, die ich hier sicherlich nicht alle posten kann 😳
Die Stelle, an der die Komandos über die Socket emfangen werden und anschließend das Antwortpaket versendet wird ist um einiges kürzer. Werde den Code hier mal reinstellen am Montag. Habe dort aber eben gesehen, dass das entsprechende Datenpaket (auch rund 5000 byte) korrekt gefüllt war und auch abgeschickt worden ist ....

Gruß
Klaus

 

[ESCS]

Gerne!
Hab mich gerade noch etwas über die genannte Exception informiert und nach meinen Erkenntnissen kann es nur an der Server Seite liegen, da in dem gegebenen Code die Verbindung nicht geschlossen wird (daher muss sie beim Server getrennt worden sein).

Daher am Besten dort weiter Fehlersuche betreiben ;-)

Grüße

 

[VfL_Freak]

Moin,

Hab mich gerade noch etwas über die genannte Exception informiert

Oh, interessant, kannst Du dazu ein paar Links posten?
Habe nämlich im Web nicht wirklich was gefunden ...

nach meinen Erkenntnissen kann es nur an der Server Seite liegen, da in dem gegebenen Code die Verbindung nicht geschlossen wird (daher muss sie beim Server getrennt worden sein).
Daher am Besten dort weiter Fehlersuche betreiben ;-)

Würde mich offen gestanden wundern, da das Server-Programm ja auf einem anderen Rechner läuft. An dem Serverprogramm hängen immer so um 40 weitere Rrechner und das Problem trat Clientseitig ja nur auf 3 neuen resp. neu aufgesetzten PCs auf.

Auf der anderen Seite tritt es im Moment gar nicht mehr auf (s. o.) ... iwie scheint das Hin- und Her-Frickeln was bewirkt zu haben .....

Gruß
Klaus

 

[ESCS]

Oh, interessant, kannst Du dazu ein paar Links posten?
Habe nämlich im Web nicht wirklich was gefunden ...

Hab mich einfach ein bisschen im Quelltext der entsprechenden Klassen umgeschaut, da findet man in der Klasse "SocketInputStream":

	// connection reset
	if (impl.isConnectionReset()) {
	    throw new SocketException("Connection reset");
	}

Und in den Javadocs wird eine SocketException wie folgt beschrieben:

Thrown to indicate that there is an error in the underlying protocol, such as a TCP error.

Würde mich offen gestanden wundern, da das Server-Programm ja auf einem anderen Rechner läuft. An dem Serverprogramm hängen immer so um 40 weitere Rrechner und das Problem trat Clientseitig ja nur auf 3 neuen resp. neu aufgesetzten PCs auf.

Dann muss der Fehler ausserhalb des gegebenen Quelltexts liegen, beispielsweise in einer anderen ausgeführten Methode oder in der Netzwerkkonfiguration des Betriebssystems.

 

[VfL_Freak]

Moin,

Dann muss der Fehler ausserhalb des gegebenen Quelltexts liegen, beispielsweise in einer anderen ausgeführten Methode oder in der Netzwerkkonfiguration des Betriebssystems

Ja, dass ist genau das, was ich befürchte ...

Sowas ist dann ja schwer zu greifen! Ich weiß nicht, ob mir das dieses WireShark weiterhelfen würde ...
Dummerweise tritt der Fehler derzeit nicht mehr auf (nachdem wie gesagt mal Input- und Outputstream hin und her getauscht hatte sowie eine Loggs im Serverprogramm drin hatte).

Das ganze ist ebenso unklar wie unbefriedigend!

Gruß
Klaus