Auf Basis dieses Tutorials TSocket-Tutorial habe ich einen einfachen Client/Server-Chat programmiert.

Soweit so gut. Die Kommunikation funktioniert reibungslos, alles wird übertragen. Allerdings habe ich dann mit einem lokalen und einem entferten Clienten mal den Stresstest gemacht: Was passiert, wenn viel geschrieben (in diesem Test nur ein Buchstabe) und sofort zum Server abgeschickt wird?

Der entfernte Client bekam zum Teil doppelte Chatlinien in einer Linie zusammengefasst zugeschickt!

Beispiel:

Beide schrieben zur gleichen Zeit:

Zitat:

Lokal: sada
Entfernt: wqd

Der lokale Client bekam jede Zeile einzelt, so wie es auch sein soll. Der entfernte Client bekam jedoch dieses Ergebnis:

Zitat:

Lokal: sada Entfernt: wqd

Meine Vermutung war, dass während der Versende-Schleife (an alle Clienten) weiterer Text in den Puffer kam, so dass die Clienten, die am Ende der der Connection-Liste sind, sozusagen die "Ars**karte" gezogen haben und somit mehr Text empfangen, als sie überhaupt sollen.

Meine erste Lösung war:
Ich brauche eine Warteliste! Eine Art Array, in der die gesendeten Texte reingebracht werden und über einem sehr schnellen Timer (Intervall im Millisekundenbereich) an die Clienten dann nach und nach abgearbeitet werden. Allerdings ergibt dies nach mehreren Sekunden Stresstest eine wunderbare Schutzverletzung. Außerdem, so meine Theorie, könnten Lücken entstehen, da, während die Inhalte des Warteschlangen-Arrays um einen versetzt werden, das Array wiederum weiter anschwellen kann. Diese Erweiterungen werden aber in der Verschiebeschleife ja noch nicht mit berücksichtigt. Die Folge: Der letzte Beitrag wird danach einfach gelöscht, ohne jemals gesendet worden zu sein.


Nun bin ich doch etwas ratlos. Hat jemand dieses Problem schonmal gelöst und kann mir da einen Lösungsansatz geben? Vielen Dank schonmal.

Hi,
es gibt zwei Dinge die dir hier weiterhelfen, mal ganz Schlagwortartig : Nichtsequentielle Programmierung und Protokoll. Hab mir jetzt nicht das Tutorial angeschaut, aber denke es passt zu deinem Problem.
Das leichtere Thema ist das Protokoll. Hier ist gar nicht so viel spezielles zu tun, du sendest nur einfach mehr als einen String. Wenn du Start- und Endzeichen mitschickst, dann ist immer klar, zuwem welcher Text gehört. Das sollten natürlich Zeichen sein, die keiner eintippt. Sagen wir mal z.B. #2 Dein Text, ... #3 , würde dann ein #2 Lokal : Bla #3 #2 Entfernt : Sein Text #3 ankommen, würdest du sicherstellen, dass du unterscheiden kannst welcher Text zu welchem Sender gehört.

Ein anderes Problem dass auftauchen könnte hat was mit NSP (Nichtsequentieller Programmierung) zu tun, könnte dir auch als Multithreading oder Nebenläufigkeit bekannt sein. Wenn du zwei Packete überträgst, so ist nie gesichert wann welches ankommt. Da du aber sicherlich gerne auf ein Event (Daten kommen an) reagieren möchtest, kann es also passieren, dass Daten von Lokal und Entfernt ankommen (bei mehr Teilnehmern analog). Würden jetzt alle auf die gleiche Variable zugreifen, hast du ein Problem. Beispielsweise wenn du etwas machst wie

markieren

Delphi-Quellcode:

var s : String; // global
...
s := Client.GetString; // hier irgendwas, was den Text einliest
ShowMessage(s);

Dann kann es zu folgendem Ablauf kommen

markieren

Delphi-Quellcode:

// allet pseudocode
s := 'Lokal'; // Client.getString durch lokal ausgelöst;
s := 'Entfernt'; // UPS, da kommt schon entfernt an und das bevor der Text ausgegeben wurde
ShowMessage(s); // Showmessage von entfernt ausgelöst
ShowMessage(s); // jetzt kommt erst Showmessage von Lokal ausgelöst, aber mit falschem Inhalt der variable

Damit das nicht passiert, müsstest du Synchronisieren. Rund um das Thema Threading findest du eine Menge guter Tutorials dazu, die dir sicher weiterhelfen (auch die Delphi Hilfe hat da tipps).

Gruß Der Unwissende

Also der 2. Teil ist hinfällig, da die Event Methoden durch die TServerSocket und TClientSocket synchronisiert werden und somit auch nicht die Handler reentrant aufrufen. Daher kann der zweite Teil getrost ignoriert werden, da es diesen Fall mit den Komponenten nicht geben wird.

Und grundsätzlich brauchst du ein kleines Protokoll um die Daten auseinander halten zu können. Die einzelnen Nutzer kannst du aber durch die Events anhand des übergebenen Sockets auseinander halten, daher brauchst du einen Trenner. Die Sockets übertragen die Daten nur und sorgen nicht(!) dafür, dass die Daten als ein Block wieder ankommen. So kannst du bei einem ReceiveText mal nur einen Teil der Nachricht bekommen oder auch mehrere Nachrichten auf einmal. Daher brauchst du ein Trennzeichen zwischen den einzelnen Texten, anhand dessen du die Texte wieder trennen kannst bzw. auch feststellen kannst, ob du sie komplett empfangen hast oder vllt. noch (ein) weitere(s) ReceiveText notwendig sind.