Indy 10: String-Limit für Server-Client-Kommunikation?

[Klaxon]

Hallo,

bei meinem Programm schicke ich Strings vom Server zum Client mit den idTCP-Komponenten. Alles funktioniert gut, aber nach ca. 11 000 Buchstaben wird die Verbindung getrennt("Closed Connection Gracefully"). Die Zeit spielt da wirklich keine Rolle, ich habe verschiedene Zeitabstände und Stringlängen getestet, aber es sind immer ca. 11 000 Characters, die dann zum Abbruch führen.

Wo und wie stellt man denn da ein mögliches Limit ein? Würde mich über Hilfe sehr freuen.

Danke und Gruß,
Klaxon.

[Klaxon]

Hallo,

ich habe inzwischen gesehen, das viele mit der Fehlermeldung "Connection Closed Gracefully" kämpfen. Leider habe ich keinen Ansatz dafür, mein Problem zu lösen. Warum sorgt eine gewisse Menge an geschickten Strings für diese Meldung? Hat niemand eine Idee?

Ich benutze übrigens Delphi 2006. Ich kann auch den Code posten, falls das nötig sein sollte.

Vielen Dank,
Klaxon.

[Zacherl]

Guck dir mal BufferSize oder MaxBufferSize an ... Das ist eine Property der Komponenten. Ansonsten habe ich vor 3 Tagen ein Protokoll für die Sockets in der CodeLib gepostet, welches lange Strings auch getrennt übermitteln kann. Natürlich ist das ganze auch sehr leicht auf die Indys zu poertieren.

Florian

[Klaxon]

@Florian Bernd

Danke für den Hinweis, ich hatte schon befürchtet dass mir niemand antwortet.

Aber ich muss glaube ich genauer erklären was ich mache. Ich möchte nämlich nicht einen String mit 11000 Zeichen verschicken, wofür dann dein Protokoll und evtl. Buffersize interessant wäre. Der Server soll Strings mit einer Länge von genau 436 Zeichen schicken. Das Ganze funktioniert genau 27 Mal, danach kommt die Fehlermeldung. Wenn ich die Stringlänge auf die Hälfte verkürze, schafft er es doppelt so oft, es liegt also irgendwie an der Menge an Zeichen, die verschickt werden.

Die Kommunikation läuft so: Der Client macht timergesteuert ein Read-Befehl, worauf der Server ein Writeln macht(im OnExecute-Ereignis).

Bin für jeden Tipp dankbar,
David.

[Zacherl]

Vermutlich sind die Komponenten einfach überfordert. Nimm einfach mal mein Protokoll und sende damit den String nicht als Ganzes, sondern in kleinere Teile gesplittet ...

Florian

[Klaxon]

Vielen Dank für den Vorschlag. Aber bevor ich mich mit dem konvertieren/anpassen deines Protokolls für meine Software beschäftige, muss ich erwähnen, dass es absolute Vorraussetzung meiner Software ist, dass die Strings so schnell wie möglich beim Clienten ankommen und nur zusammenhängend ausgewertet werden können. Ein Schicken von kleinen Paketen hintereinander wäre wahrscheinlich mit einer zu großen Zeitverzögerung verbunden.

Übrigens habe ich es auch schon mit kleinen Paketen versucht, da kam die genannte Fehlermeldung dann halt nach 15 Minuten. Würde dein Protokoll da wirklich Abhilfe schaffen, also die Dinge so entscheidend anders machen?
Vielleicht ist ja auch mein Code unglücklich, warum hatte sonst nie jemand mit diesem Problem zu kämpfen.

Server:

Delphi-Quellcode:

procedure TForm1.IdTCPServerExecute(AContext: TIdContext);
begin
          AContext.Connection.iohandler.WriteLn(s);
end;

Client:

Delphi-Quellcode:

procedure TForm1.GetData;
 begin
with TCPClient do begin
    try
      S:=IOHandler.ReadLn;
    finally
      Disconnect;
    end;
  end;
 end;

Also wirklich so simpel wie möglich. Das GetData wird dann timergesteuert aufgerufen.

Vielen Dank,
Klaxon.

[Zacherl]

In welchem Intervall rufst du GetData auf? Minimal würde ich 500ms einstellen, weil es sonst öfters zu Problemen kommt.

Dann noch zum Protokoll von mir:
Also erstens werden die 10000 Zeichen sowieso nicht alle auf einmal versendet, sondern erst vom Server wieder zusammengesetzt und du könntest das Protkoll so einsetzen, wie es mittlerweile als Unit im Forum "Neuen Beitrag zur codeLib hinzufügen" vorhanden ist.

Mit der Funktion GetCMDString kannst du einen Befehlscode erstellen, bzw mit der Funktion GetLimitedCMDString erstellst du mehrere String Teile, die den Befehlscode enthalten.

Ein Beispiel zum Parsen der Befehle ist auch dabei.

Florian

[Klaxon]

JUHU!

Ich habe den Fehlerverursacher gefunden. Das "Disconnect" in der finally-Sektion beim Client hat wohl die Verbindung getrennt. Mir ist zwar noch nicht ganz klar, warum es überhaupt ausgeführt wurde, aber man kann sich ja schon vorstellen, dass mal ein "readln" fehlschlägt.

Vielen Dank für Deine versuchte Hilfe Florian!

Was für ein geniales Gefühl, dieses Problem beschäftigt mich schon ewig...

Gruß,
Klaxon.

[Zacherl]

Manchmal sieht man den Wald vor lauter Bäumen nicht Hätte ich ja auch merken müssen ...

Der unterschied von try ... finally ... end zu try ... except ... end ist, dass im finally Block der Code aufjeden Fall ausgeführt wird, auch wenn zwischen try und finally ein Fehler auftritt.
Im try except Block wird der Code zwischen except und end nur dann ausgeführt, wenn zwischen try und except ein Fehler auftritt.

Also verwende einfach except statt finally

Florian