Indy9-client friert ein trotz Antifreeze

schippi · Beiträge: 23

Hallo!
Ich benutze die Komponenten IdTCPServer und IdTCPClient von Indy 9.
Mein Client friert immer ein, wenn ich mehrmals nacheinander Daten an den Server schicke und der Server nicht gleich antwortet. Schickt der Server sofort eine Antwort zurück, friert mein Programm nicht ein. Anscheinend müsste das Problem ja bekannt sein, weil sonst würde man die Antifreeze-Komponente nicht benötigen. Aber mit dieser Komponente gehts trotzdem nicht...

Kann mir da jemand helfen??

Viele Grüße!

Narses · Verfasst: Mi 28.11.07 12:42

Moin!

Das Antifreeze-Gefrickel von den Indies ist eh Müll...

Pack die Operationen in einen Thread und gut is das. :idea:

cu
Narses

_________________
There are 10 types of people - those who understand binary and those who don´t.

schippi · Beiträge: 23

Narses hat folgendes geschrieben:

Das Antifreeze-Gefrickel von den Indies ist eh Müll... Pack die Operationen in einen Thread und gut is das.

Danke für den Tip. Jetzt friert zumindest mein Client nicht mehr ein.

Jetzt bleibt aber mein Server in der Execute-Methode hängen.

Das passiert aber nur wenn der Server viele Daten bekommt und ein Weilchen zum verarbeiten braucht. Anscheinend stauen sich dann die Daten auf und der Server schmiert ab.
Gibts hierfür auch noch so ne einfache Lösung?

Quitzlinga · Verfasst: Mi 28.11.07 16:30

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:

procedure Form1.ServerExecute(AContext: TIdContext);
var
   msg : string;
   context : TidContext;
begin
  // Text vom Client holen
  Msg := AContext.Connection.IOHandler.ReadLn();
  // und auf stapel packen;
  ServerBatch.AddObject(Msg,AContext);
  // Wenn Busy dann raus
  if not ServerBusy then begin
    ServerBusy := true;
    // Nachricht am Amfang herausloesen, zwischenspeichern
    // und aus der Liste loeschen
    Msg := ServerBatch.Strings[0];
    Context := TIdContext(ServerBatch.Objects[0]);
    ServerBatch.Delete(0);
    // Daten verarbeiten
    // ...
    ServerBusy := false;
  end;  
end;

ServerBatch ist eine Liste vom Typ TList und wird im Hauptprogramm initialisiert. Funktioniert bei mir bestens und hat den Vorteil, das die Execute-Routine des Servers sich nicht aufstaut.

MfG

Qutizlinga

schippi · Beiträge: 23

@Quitzlinga: Hast du das so gemeint, dass du alle Daten die beim Server ankommen speicherst und dann einen Thread aufrufst in dem alles abgearbeitet wird?
Ich habs selbst noch nicht ausprobiert. Mach ich aber noch.

Aber mal was anderes. Eigentlich müsste doch das Ganze die Komponente für mich erledigen, so dass ich mich überhaupt nicht mit sowas befassen müsste. Das ist doch total benutzerunfreundlich. Warum empfiehlt bloß jeder Indy :gruebel:

Wenn ich das vorher gewusst hätte, was da auf mich zukommt, wäre ich bei der guten alten TServerSocket-Komponente geblieben...

mfg

Quitzlinga · Verfasst: Fr 30.11.07 00:55

Das ich die Daten zwischenspeicher stimmt schon. Damit will ich nur verhindern, das die Execute-Routine des Servers mehrmals aufgerufen wird und mir so den Speicher vollmüllt. Es hat auch noch den weiteren Vorteil, das die Daten so abgearbeitet werden, wie sie ankommen. Im Normalfall möchte ich nämlich nicht, das der nächste Befehl abgearbeitet wird (lineare Abarbeitung), bloss weil der vorherige mehr Zeit zur Abarbeitung verbraucht und nicht rechtzeitig beendet werden kann und daher auf dem Stack landet,der vermutlich sehr begrenzt ist. Inbesondere beim zerstückelten versenden von Dateien darf nicht der nächste Teil verarbeitet werden, bevor der vorherige abgearbeitet wurde.

Zitat:

Eigentlich müsste doch das Ganze die Komponente für mich erledigen, so dass ich mich überhaupt nicht mit sowas befassen müsste.

Das macht die Komponente ja auch, aber sie ruft mit jeder Ankunft von Daten automatisch die Execute Routine auf. Sie wartet nicht solange, bis du den vorherigen Aufruf wieder verlassen hast.

Zitat:

Warum empfiehlt bloß jeder Indy

Das liegt daran, das die TServer und TClient Komponente von Borland nicht mehr unterstützt werden und nur noch der Vollständigkeit halber dabei sind. (Hab ich zumindest irgentwo mal gelesen). Weiterhin kommt noch eine gute Netzwerkstabilität hinzu und natürlich letztlich der Support zu den Indys.

Zitat:

Wenn ich das vorher gewusst hätte, was da auf mich zukommt, wäre ich bei der guten alten TServerSocket-Komponente geblieben...

Da hättest du genau dasselbe Problem gehabt (und wahrscheinlich noch ein paar mehr dazu)

MfG

Quitzlinga

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme