max Länge TCPIP

[Bbommel]

Ich habe selbst auch Code, der zeilenweise liest, und auf die Art seit 17 Jahren problemlos funktioniert. Daher habe ich gerade mal geschaut, ob ich bei mir noch etwas finde, was ich hilfreiches schreiben könnte, aber eigentlich ist alles gesagt. Was mir aber aufgefallen ist: bei mir steht:

Result:=tcpConnection.Socket.ReadLn('',aTimeOut,-1,useIndyEncoding);
Bei mir steht also tcpConnection.Socket statt tcpConnection.IOHandler . Weiß jemand, ob das ein Unterschied ist (tcpConnection ist TIdTCPClient und hätte auch den IOHandler)?

[AJ_Oldendorf]

@jaenicke: Danke für den Hinweis mit dem Timeout. Ich verstehe was du meinst aber wenn ich vorher den InputBuffer auf <> Empty abfrage, dann bleibt mein Thread mit dem ReadLn nur bis zum nächsten gelesen Terminator hängen. Richtig? Auf welchen Wert sollte man das Timeout denn setzen? Erfahrungen? Was passiert, wenn Timeout abläuft und er nicht bis zum Terminator gelesen hat? Bekomme ich dann wieder nur ein Teilstring von meinem Telegramm?

@QuickAndDirty: Das sagt mir erstmal gar nichts dein Vorschlag Wie würde denn sowas genau aussehen und was meinst du mit "Wenn sie auf beiden Seiten bekannt sind, dann"? Also die Telegramme sind immer inhaltlich unterschiedlich und auch immer unterschiedlich lang

[QuickAndDirty]

Zitat von AJ_Oldendorf:

@QuickAndDirty: Das sagt mir erstmal gar nichts dein Vorschlag Wie würde denn sowas genau aussehen und was meinst du mit "Wenn sie auf beiden Seiten bekannt sind, dann"? Also die Telegramme sind immer inhaltlich unterschiedlich und auch immer unterschiedlich lang

Wenn du einen Typ TTermin hast welcher von TPersistent oder so abgeleitet ist, dann kannst du Instanzen dieses Typs mittels RTTI nach Json "serialisieren" und wenn du am anderen ende die Unit wo der Typ deklariert ist auch eingebunden hast, dann kannst du den JSON String auch wieder in ein Objekt umwandeln aka Deserialisieren.
Wenn man einmal Das serialisieren mittels RTTI und JSON programmiert hat, funktioniert das für alle Objekte die gewisse Regeln einhalten und so kannst du alles mögliche an Typen in strings umwandeln verschicken und wieder in Objekte umwandeln...ohne das du es für jeden einzelfall neu programmieren musst.

[jaenicke]

Zitat von AJ_Oldendorf:

Ich verstehe was du meinst aber wenn ich vorher den InputBuffer auf <> Empty abfrage, dann bleibt mein Thread mit dem ReadLn nur bis zum nächsten gelesen Terminator hängen. Richtig?

Ja, schon, aber wenn keine Daten mehr kommen, wartet die Funktion einfach weiter. Wenn du das Programm dann beenden möchtest, kannst du den Lesevorgang nicht sauber beenden.

Zitat von AJ_Oldendorf:

Auf welchen Wert sollte man das Timeout denn setzen? Erfahrungen?

Das kommt auf die Größe der Pakete an und wie lange es dauern darf, bis der Thread sich auf Anforderung beendet. Ich nehme meistens 100 bis 500 Millisekunden, weil das die Verzögerung gering genug hält, dass niemand beim Beenden bewusst warten muss, andererseits aber auch nicht zu oft versucht wird zu lesen.

Zitat von AJ_Oldendorf:

Was passiert, wenn Timeout abläuft und er nicht bis zum Terminator gelesen hat? Bekomme ich dann wieder nur ein Teilstring von meinem Telegramm?

Das kannst du ja leicht testen. Soweit ich mich erinnere, wird der schon angekommene Teil nicht zurückgeliefert, sprich du bekommst einen Leerstring und beim nächsten Aufruf alles. Du kannst aber prüfen, ob ein Timeout aufgetreten ist, indem du ReadLnTimedOut abfragst.

[AJ_Oldendorf]

@jaenicke:
Danke, ich prüfe das mal mit dem Leerstring und dem Timeout.

Sag mal, beim Server ist es aktuell so, dass wenn sich ein Client verbunden hat, die CPU Auslastung auf ca 6% von dem Programm geht.
Es werden keine Daten verschickt vom Server und vom Client. Einfach nur das Verbinden.
Wenn ich beim Server das Active auf False setze, geht die Auslastung sofort runter.
Hat jemand eine Idee dazu?

[jaenicke]

Zum Server lässt sich ohne Quelltext nicht viel sagen. Du kannst nur mal zwischendurch anhalten und schauen, wo du gerade bist.

Hast du vielleicht ein OnExecute mit Schleife, in der du kein Sleep(1) drin hast (wenn keine Anfrage da war), um die Schleifendurchläufe im Leerlauf zu begrenzen?

[AJ_Oldendorf]

Also ich habe eine Form mit TIdTCPServer und verknüpften TIdServerIOHandlerStack.

Delphi-Quellcode:

procedure TMyForm.FormCreate(Sender: TObject);
begin
  IdTCPServer1.DefaultPort := 44001;
end;

procedure TMyForm.FormDestroy(Sender: TObject);
begin
  IdTCPServer1.Active := False;
end;

procedure TMyForm.IdTCPServer1Connect(AContext: TIdContext);
begin
  if Assigned(LogSL) then
  begin
    LogSL.Add('A client connected');
  end;
end;

procedure TMyForm.IdTCPServer1Disconnect(AContext: TIdContext);
begin
  if Assigned(LogSL) then
  begin
    LogSL.Add('A client disconnected');
  end;
end;

procedure TMyForm.IdTCPServer1Exception(AContext: TIdContext;
  AException: Exception);
begin
  if Assigned(LogSL) then
  begin
    LogSL.Add('A exception happend !');
  end;
end;

procedure TMyForm.IdTCPServer1Execute(AContext: TIdContext);
var
  tmpStr : String;
begin
  if IdTCPServer1.Active then
  begin
    if not AContext.Connection.IOHandler.InputBufferIsEmpty then
    begin
      tmpStr := AContext.Connection.IOHandler.ReadLn('#~#*', 300, -1);
      LogSL.Add(tmpStr);

      Timer1.Enabled := True;
    end;
  end;
end;

Das ist im groben alles...

[jaenicke]

Pack mal am Ende des OnExecute ein Sleep(1) rein oder verwende AContext.Connection.IOHandler.CheckForDataOnSource(10); , damit die Anzahl der Aufrufe reduziert wird, dann sollte das nicht mehr passieren.