Socket Error 10054 Connection reset by peer - wie behandeln?

[Sir Rufo]

Hast du auch schon versucht den InputBuffer vom IOHandler zu löschen, so wie hier beschrieben
http://stackoverflow.com/a/10523444/1744164

Also so in etwa

Delphi-Quellcode:

// TCP Komponenten Erstellen
procedure TValueGroup.CreateTCP;
var
  tmp: TIdTCPClient;
begin
  if Assigned( FTCP )
  then
    begin
      if FTCP.Connected
      then
        try
          FTCP.Disconnect( false ); // Hier kommt u.U. der Socket Error 10054
        except
          on e: Exception do
            frmTCPLog.Add( FTCP.Host + ': Error on Disconnect "' + e.ClassName + ': ' + e.Message + '". Do not care, we are recreating the connection' );
        end;
      if Assigned( FTCP.IOHandler )
      then
        FTCP.IOHandler.InputBuffer.Clear;
      FreeAndNil( FTCP );
    end;
  // Hier sollte eigentlich kein Fehler passieren,
  // aber falls doch, dann so absichern
  tmp := TIdTCPClient.Create;
  try
    tmp.IOHandler             := TIdIOHandlerStack.Create;
    tmp.IOHandler.ReadTimeout := 1000;
    tmp.Host                  := FIP;
    tmp.Port                  := FPort;
    tmp.OnStatus              := OnTCPStatus;

    FTCP := tmp;
    tmp  := nil;
  finally
    tmp.Free;
  end;
end;

// Verbindungsherstellung
procedure TValueGroup.ConnectToGateway;
begin
  try
    FTCP.ConnectTimeout := 100;
    if not FTCP.Connected
    then
      FTCP.Connect( );
  except
    on e: Exception do
      begin
        // Exception komplett mitloggen
        frmTCPLog.Add( FTCP.Host + ': Connect failed with "' e.ClassName + ': ' + e.Message + '" Recreating.' );
        // try
        CreateTCP;
        // except
        // end;
      end;
  end;
end;

// Meine Daten-Refresh Prozedur
procedure TValueGroup.RefreshData;

var
  remainingBytes: Integer;
  sAdr          : Integer;
begin
  remainingBytes := FMaxAddress + 4 + 2;
  SetLength( FBuffer, remainingBytes );
  try
    if not FTCP.Connected
    then
      ConnectToGateway;

    sAdr := 0;
    while remainingBytes > 255 do
      begin
        FRequestBuffer[ 1 ] := Byte( sAdr shr 8 );
        FRequestBuffer[ 2 ] := Byte( sAdr and $FF );
        FRequestBuffer[ 4 ] := 255;
        SendBuffer( TCP, RequestBuffer );
        ReceiveBuffer( TCP, FBuffer, sAdr, 255 );
        dec( remainingBytes, 255 );
        inc( sAdr, 255 );
      end;

    FRequestBuffer[ 1 ] := Byte( sAdr shr 8 );
    FRequestBuffer[ 2 ] := Byte( sAdr and $FF );
    FRequestBuffer[ 4 ] := Byte( remainingBytes and $FF );
    SendBuffer( TCP, RequestBuffer );
    ReceiveBuffer( TCP, FBuffer, sAdr, remainingBytes );

    BufferToValues;
  except
    on e: Exception do
      begin
        // Exception komplett mitloggen
        frmTCPLog.Add( FTCP.Host + ': Recovering from "' + e.ClassName + ': ' + e.Message + '"' );
        CreateTCP;
      end;
  end;
end;

[Medium]

Über den SO bin ich bei meiner Suche auch gestolpert, ja . Das Neuerstellen der TIdTCPClient Komponente (inkl. ihres IOHandlers) sollte das durchaus erledigen. Aber ich habe davor tatsächlich das Stück Code aus der Antwort dort probiert. Leider ohne Erfolg. (Durch den Post bin ich erst auf die Idee gekommen, Disconnect() mit dem Parameter aufzurufen.) Trotzdem danke für das Interesse!!

[Dejan Vu]

ich hatte vor Jahren mit Delphi im SPS-Umfeld zu tun. Ich kann mich erinnern, das gleiche Problem gehabt zu haben, woraufhin ich bei jeder TCP-Zicke das Programm gnadenlos beendet habe (Halt). Durch einen Neustart und anschließendem reconnect war das Problem dauerhaft gelöst. Der Neustart war einfach eine Endlosschleife in einer Batchdatei

Code:

:Loop
MeinProgramm.EXE
Goto Loop

Mir war und ist klar, das diese Art der Lösung ziemlich unprofessionell ist. Aber seit dieser Maßnahme ist Ruhe im Karton-

[Medium]

Ich bin vorhin letztlich wieder auf UDP Kommunikation gegangen hier, wo das kein Problem ist. Ursprünglich bin ich von UDP zu TCP gewechselt, weil ich den Eindruck hatte, dass ich u.U. die Antworten in mehreren Paketen bekomme, die ich leider dank fehlender ID im Protokoll nicht einer spezifischen Anfrage zuordnen kann. TCP ist was solches Handshaking angeht ja etwas verlässlicher.
Aber ich habe meinen Fehler gefunden, und ja: Er war dämlich. In der Doku von den Gateways steht, dass ich von deren internem Array immer je 1000 Werte am Stück abfragen kann. Also habe ich das getan. Allerdings hieß "Wert" bei denen "Byte", bei mir aber "Single"... ich habe einfach 4x zu große Anforderungen geschickt, was meine Lücken in den Daten erklärt. Autsch!

Ergo: Kleinere Anfragen, auf deren Antworten ich brav warte und sie jeweils zusammen stückel, und schon ist alles paletti via UDP. Ich vermute schon fast, dass mich das Gateway per TCP ab und zu "rausgeworfen" haz, weil es irgendwann gemerkt hat, dass die Request-Buffer nach zu viel gefragt haben. (Bei den anderen 2 Gateways erfrage ich weniger, aber dennoch >1000 am Stück. Weiss der Geier warum dieses eine empfindlicher gewesen sein könnte.) Aber das werde ich nicht weiter erforschen, die ganze Nummer hat jetzt schon WEIT mehr Zeit und Nerven gekostet als man jemals zugeben dürfte.

Saß der Fehler doch mal wieder vor dem Bildschirm. Verdammt. (Auch wenn die Frage, wie man mit einem vom Peer gesendeten Reset am besten umgeht prinzipiell nicht ohne Relevanz ist.)

Vielen Dank nochmals an alle hier!!

[Dejan Vu]

Du musst dich aber nicht wundern, wenn von deinen UDP Paketen nicht immer alle ankommen.

[Medium]

Ich weiss. Dafür habe ich eine kleine eigene Timeout-Behandlung drin. Ab und zu ist die auch schon zugeschlagen. Aber das ist nicht ganz so schlimm, so lange das sehr sporadisch nur auftritt. Dann gibt's für eine Sekunde halt die Werte der vorigen für einen 64-Werte Block. Ganz so kritisch ist das nicht. Lief jetzt immerhin schon einen Tag lang ohne murren durch.