Indy-Test optimieren

[BUG]

Um es nochmal zu betonen:
TCP-Verbindungen schnell hintereinander auf und ab zu bauen ist fast immer eine schlechte Idee.
Wenn es mit auf- und abbauen übertreibt, kann es sogar passieren, das einem die Ports ausgehen (bei insgesamt wenigen "gleichzeitigen" Verbindungen).

Zitat von Union:

Man braucht die Pakete für die Clients nur durchnumerieren. Die dann zu implementierende Prüfungslogik ist trival.

Und wenn man festgestellt hat das ein Packet fehlt? Selective Repeat, go-back N oder halt nur Best-Effort-Delivery? Was bedeutet das auf Anwendungsebene?
Klar kann man ein Protokoll basierend auf UDP haargenau auf seine Anwendung zuschneiden, aber für allgemeine Aufgaben würde ich immer mit TCP beginnen.
Natürlich ordentlich weggekapselt hinter einer anwendungsspezifischen Schnittstelle.

[stahli]

Ich habe noch mal einen aktuellen Projektstand angehängt (nur die Quellen).
Wenn man im Client jetzt auf das Formular klickt wird im Server ein Sleep(10Sec) und danach die Drehanweisung ausgeführt.
Da der Client die "Datenabfrage" und die "Drehanweisung" aber jetzt in verschiedenen Threads verschickt bleibt der Client bis zum "Berechnungsergebnis" quasi am Leben (zeigt weiter aktuelle Daten an).
Ohne getrennte Threads im Client würde der Client natürlich hängen, solange der Server noch nichts zurück schickt - die 10 Sekunden eben.

(Ich nutze hier einen anonymen Thread. Mit älteren Delphi-Versionen müsste man das natürlich umstellen.)