java.net.SocketException: Tilkobling tilbakestilt

Jeg får følgende feil når jeg prøver å lese fra en socket. Jeg gjør en readInt() på den InputStream, og jeg får denne feilen. Ved å lese dokumentasjonen antyder dette at klientdelen av forbindelsen stengte forbindelsen. I dette scenariet er jeg serveren.

Jeg har tilgang til klientloggfilene, og den lukker ikke forbindelsen, og faktisk antyder loggfilene at jeg lukker forbindelsen. Så har noen en idé om hvorfor dette skjer? Hva annet kan jeg se etter? Oppstår dette når det er lokale ressurser som kanskje når terskler?


Jeg legger merke til at jeg har følgende linje:

socket.setSoTimeout(10000);

like før readInt(). Det er en grunn til dette (lang historie), men bare nysgjerrig, er det omstendigheter der dette kan føre til den angitte feilen? Jeg har serveren som kjører i IDE-en min, og jeg lot tilfeldigvis IDE-en min sitte fast på et bruddpunkt, og jeg la da merke til at nøyaktig de samme feilene begynte å vises i mine egne logger i IDE-en min.

Uansett, bare nevner det, forhåpentligvis ikke en rød sild :- (

Det er flere mulige årsaker.

  1. Den andre enden har bevisst tilbakestilt forbindelsen, på en måte som jeg ikke vil dokumentere her. Det er sjelden, og vanligvis feil, at applikasjonsprogramvare gjør dette, men det er ikke ukjent for kommersiell programvare.

  2. Mer vanlig er det forårsaket av å skrive til en forbindelse som den andre enden allerede har lukket normalt. Med andre ord en applikasjonsprotokollfeil.

  3. Det kan også være forårsaket av å lukke en socket når det er uleste data i socket-mottaksbufferen.

  4. I Windows er 'programvare forårsaket tilkoblingsavbrudd', som ikke er det samme som 'tilbakestilling av tilkobling', forårsaket av nettverksproblemer som sendes fra din side. Det er en Microsoft Knowledge Base-artikkel om dette.

Kommentarer (1)

Tilbakestilling av tilkobling betyr ganske enkelt at en TCP RST ble mottatt. Dette skjer når motparten din mottar data som den ikke kan behandle, og det kan være forskjellige grunner til det.

Den enkleste er når du lukker kontakten, og deretter skriver mer data på utgangsstrømmen. Ved å lukke kontakten forteller du motparten din at du er ferdig med å snakke, og den kan glemme forbindelsen din. Når du likevel sender mer data på den strømmen, avviser motparten den med en RST for å fortelle deg at den ikke lytter.

I andre tilfeller kan en mellomliggende brannmur eller til og med den eksterne verten selv "glemme" TCP-tilkoblingen din. Dette kan skje hvis du ikke sender data på lenge (2 timer er en vanlig tidsavbrudd), eller fordi motparten ble startet på nytt og mistet informasjonen om aktive tilkoblinger. Å sende data på en av disse nedlagte forbindelsene vil også føre til en RST.


Oppdatering som svar på tilleggsinformasjon: .

Ta en nærmere titt på håndteringen av SocketTimeoutException. Dette unntaket heves hvis den konfigurerte tidsavbruddet overskrides mens en socket-operasjon er blokkert. Tilstanden til selve sokkelen endres ikke når dette unntaket kastes, men hvis unntakshåndteringen din lukker sokkelen og deretter prøver å skrive til den, vil du være i en tilkoblingstilbakestillingstilstand. setSoTimeout() er ment å gi deg en ren måte å bryte ut av en read()-operasjon som ellers kan blokkere for alltid, uten å gjøre skitne ting som å lukke socket fra en annen tråd.

Kommentarer (2)

Når jeg har hatt rare problemer som dette, setter jeg meg vanligvis ned med et verktøy som WireShark og ser på rådataene som sendes frem og tilbake. Du kan bli overrasket over hvor ting blir koblet fra, og du blir bare varslet når du prøver å lese.

Kommentarer (0)