Spielwiese - SocketTest

**stahli**

Hi,

im Bereich "Tutorial" wäre es nicht korrekt aufgehoben, daher mal hier...

Ich habe ein Testprojekt (XE3) mit ServerSocket und ClientSocket erstellt.

Es gibt einen "ClientManager", der die Mausereignisse erhält und mit dem Server kommuniziert und als Ergebnis ein Bitmap erstellt, das im Formular dargestellt wird.
Die Clientlogik läuft also in dem Manager und das Formular dient nur als grafische und Ereignisschnittstelle.

Im Servermanager auf der anderen Seite läuft eine eigenständige "Businesslogik" in einem eigenen Thread.
Änderungen in der Datenschicht (hier testweise alle paar Millisekunden) werden an die Clients geschickt, die die Daten empfangen und ein neues Bitmap erstellen.

So hält der Server einen kompletten Datenbestand und die Clients zeichnen sich entsprechend der übertragenen Daten.

Ein wenig könnte man das vielleicht mit einem simplen Spiel vergleichen.

Der Anwendungsfall macht natürlich wenig Sinn, aber
- ich habe zwei konkrete Fragen, die Ihr vielleicht beantworten könnt
- vielleicht können wir die Struktur der Anwendung verbessern und die mit Sicherheit vorhandenen problematischen Teile optimieren.
- vielleicht ist das ja für andere mal von Interesse
- evtl. könnte man auch ein etwas ernsthafteres Projekt daraus weiterentwickeln (vielleicht ein kleines Netzwerkspiel für die DP oder das von Mavarik angedachte Ameisenprojekt?) um daran weiter zu lernen - nur so eine Idee...

Meine Fragen:
1) Bei mir arbeitet der Server oft deutlich (10-30 mal) langsamer als normal, wenn die Delphi-IDE geschlossen ist. Starte ich die IDE, läuft er wieder normal, schließe ich sie, ist er wieder langsamer. Das ist jedoch nicht immer so (im verlinkten Video z.B. nicht). Kann das jemand einordnen?
2) Ich erhalte einen "asnchronen Fehler" vom ServerSocket, wenn ein Client geschlossen wird.
Das Problem liegt darin, dass die in einem eigenen Thread laufende "Businesslogik" ständig (alle paar ms) Änderungsmeldungen an alle Clients verschickt. Ich habe zwar versucht, diese mit dem Mainthread zu synchronisieren, aber das reicht nicht.
Der zu schließende Socket hat wohl schon die Kill-Nachricht vom Server, befindet sich aber noch einen Moment in der Socketliste und wird somit vom BL-Thread noch mit beim Nachrichtenversand berücksichtigt. Das führt dann zu einem Fehler.
Ich finde keine Möglichkeit, die Kill-Nachricht rechtzeitig zu erkennen und somit keine Rundumnachricht mehr an den Kill-Socket zu senden.
Kann da jemand helfen?

Anbei das XE3-Projekt.
Die Bibliothekspfade müsste man bei Bedarf einrichten, so dass die Nachnutzung leider etwas aufwendiger wird (ggf. kann ich dazu noch eine Übersicht erstellen, was erforderlich wäre).
Die Exen sind in den Release-Ordnern. In den Ini´s könnte man andere Ports und für die Clients andere IPs eintragen (habe ich aber noch nicht getestet).

Hier ein Link zu einem Video:

https://youtu.be/mnoBtkIzEf4
(Sind aber 18 min, also lohnt sich nur, wenn Ihr direktes Interesse am Thema habt.)

Bin gespannt, ob das für irgendwen von Interesse ist...

**stahli**

Mal eine neuere Version.

Die IP und Port in der Ini wird jetzt auch berücksichtigt.

(Ich war wohl doch zu übermüdet.)

Die Exen werden jetzt zentral unter D:\SocketTest erzeugt. Das ist m.E. übersichtlicher.

Ich habe das jetzt auch über WLAN und Internet getestet.
Der Server schickt 4*360 Änderungen pro Sekunde an die Clients.
Lokal sieht das flüssig aus. Über Netzwerk hakelt es natürlich.

Natürlich ist das nicht optimiert, aber es soll ja auch mal ein Stresstest sein.

Als nächstes will ich mal protokollieren, ob alle Daten bei den Clients ankommen oder ob welche verloren gehen.
Kann ja ein einfacher Integer sein, der laufend erhöht wird.
Werde ich nächste Woche mal tun.

Dann will ich auch prüfen, wie die Sockets sich im blockierenden Modus verhalten.

**Zacherl**

Zitat von stahli:

Als nächstes will ich mal protokollieren, ob alle Daten bei den Clients ankommen oder ob welche verloren gehen.

Darüber brauchst du dir keine Gedanken machen. TCP garantiert sowohl die korrekte Reihenfolge als auch die verlustfreie Zustellung der Pakete

**stahli**

... oder was es für Probleme geben kann, wenn der Server massenweise Nachrichten verschickt und die Clients nicht hinterherkommen würden.

Wie gesagt, ich kann diese ganzen Grenzfälle nicht wirklich einordnen und werde das daher mal "am eigenen Leib" versuchen...

**Michael II**

Hallo stahli

Wenn du dich nur auf eigene Mittel verlassen willst, dann lass doch den Server in gewissen Abständen (zum Beispiel abhängig von der Zeit oder von der Menge der gesendeten Daten) eine Nachricht [Inhalt: Sendezeit] an den Client senden, welche der Client rausfischt und an den Server zurücksendet. Dann weisst du relativ genau, wie schnell/gut deine Leitung ist.

Gruss
M

**stahli**

Ich bin hin und her gerissen ... aber multidimensional!

Erst mal zu einem festgestellten Problem:

Nicht blockierende Sockets unterhalten sich ungeordnet.
Aus drei gesendeten Texten
Text1
Text2
Text3
kann auf der Empfängerseite
Text1Text2Text3
werden.

Im Screenshot 1 sieht man, dass die eigentlich einzeln gesendeten Stringlisten auf der Gegenseite verbunden ankommen. Möglicherweise werden sie u.U. auch mittendrin geteilt, das habe ich nicht untersucht.

Man muss somit klare Trennzeichen definieren:
Text1*
Text2*
Text3*
würde dann
Text1*Text2*Text3*
und könnte wieder zerlegt werden
oder
man könnte bei übertragenen Stringlisten festlegen, wie viele der nächsten Zeilen zu einem command gehören:
3
SetXY
10
10
2
SetName
stahli

Also man braucht genaue Regeln, damit man sie wieder ordentlich trennen bzw. zusammenfügen kann, ehe man sie verarbeitet.

Was aber gravierender ist, ist dass die Reihenfolge bzw. der Zeitpunkt der Textsendungen nicht klar vorherzusehen ist (siehe Screenshot2). Es ist insofern nachvollziehbar, da ja für den Mainthread Messages erzeugt werden, die dann nach und nach abgearbeitet werden.

Wenn ich also in meiner Demo vielfach pro Sekunde automatisch Daten vom Server verschicke (und vielleicht von Clients aus zwischendurch auch noch Rückfragen starte), werden die Clients mit Messages bombardiert und sind voll beschäftigt, diese abzuarbeiten. Von 1000 Zwischenständen werden somit 999 gar nicht sinnvoll berücksichtigt oder es werden 100 Rückfragen in Form von Messages "gesammelt", obwohl dies natürlich nur einmal sinnvoll wäre.
Entsprechend muss man entweder die Frequenz reduzieren oder auf Clientseite feststellen, dass gerade nur der letzte erhaltene Zwischenstand relevant ist - oder beides.
Eine Rückfrage bezüglich einer bestimmten Information dürfte nicht nochmal rausgehen, sofern schon eine gleichartige erzeugt wurde und noch nicht beantwortet ist. Das müsste somit extra verwaltet werden, da man schlecht die WindowsMessageQueue durchsuchen kann (oder diese vielleicht gerade schon unterwegs zum Server ist).

Ein Chatbeispiel ist für non blocking Sockets sicherlich gut geeignet, nicht aber unbedingt ein Projekt, das auf Serverseite ständig neue Änderungen erzeugt oder erzeugen kann und viele Clients darüber informieren will.

Wenn man dies mit non blocking Sockets realisieren will muss der Server am besten für jeden Client verwalten, wann dieser zuletzt über welche Änderungen informiert wurde und Änderungsmitteilungen etwas verzögert und optimiert versenden.

Der Client dürfte seinerseits nicht sofort neue Daten abrufen sondern müsste auch schauen, wann ein guter Zeitpunkt dafür ist und den Status aller Anfragen intern selbst verwalten - obwohl die Antwort über Windows-Nachrichten kommt.

Also so etwas ist sicherlich möglich, aber kann sicher sehr schnell sehr aufwendig werden.

Jetzt könnte man natürlich auf den blockierenden Modus umstellen, aber dann kann ich ja auch bei den Indys bleiben, mit denen ich eine funktionierende Kommunikation schon im Griff hatte.
Ich hatte mir nur gedacht, dass ich mit den nicht blockierenden Sockets performanter bin und halt ohne pulls auskomme.

Schicken die non blocket sockets eigentlich interne Pulls und erzeugen letztlich auch eine Last auf dem Netzwerk und der CPU?
Oder sind Pulls aller 1/2 Sekunde von den Clients schon teurer?

Long Pulls über Threads wären natürlich auch denkbar, aber da würde ich doch regelmäßige kurze Pulls bevorzugen, in denen Zeitstempel abgerufen werden.

Wenn man ein Projekt jetzt doch mit den non blocket sockets aufbaut, könnte man das Projekt dann grundsätzlich irgendwie auf andere Plattformen übertragen?
Sicherlich doch nicht, da man dann ja an die Windows Messages gebunden ist - oder?

Mein Zwischenfazit ist derzeit, dass die Indys wohl doch keine so schlechte Lösung sind und man eben mit zyklischen Pulls oder LongPulls leben muss.

Weiteres Fazit ist, dass es scheinbar kein vernünftiges Tutorial gibt, das diese ganzen Zusammenhänge mal beleuchtet...

**Zacherl**

Zitat von stahli:

Jetzt könnte man natürlich auf den blockierenden Modus umstellen, aber dann kann ich ja auch bei den Indys bleiben, mit denen ich eine funktionierende Kommunikation schon im Griff hatte.
Ich hatte mir nur gedacht, dass ich mit den nicht blockierenden Sockets performanter bin und halt ohne pulls auskomme.

Schicken die non blocket sockets eigentlich interne Pulls und erzeugen letztlich auch eine Last auf dem Netzwerk und der CPU?
Oder sind Pulls aller 1/2 Sekunde von den Clients schon teurer?

Von der Performance her sind die non-blocking Sockets sogar geringfügig langsamer, weil dort alle Events über Window-Messages getriggert werden, die zuerst den kompletten Weg durch die MessageQueue nehmen müssen. Das Pullen von blocking Sockets ist sehr sparsam was CPU Last angeht. Windows regelt die kompletten Synchronisationsmechanismen im Kernel, weshalb zwar einmalig ein Context-Switch stattfinden muss, aber danach bekommt der entsprechende Thread vereinfacht ausgedrückt einfach keine CPU-Zeit vom Scheduler mehr zugeteilt, bis neue Daten vorliegen.

**stahli**

Du beziehst Dich aber auf long polling, bei dem der Client einen extra Thread startet, der bis zur Antwort vom Server blockiert - richtig?

Dann muss aber auch der Server eine Connection pro Client offen halten - richtig?
Das würde bedeuten, dass man nicht tausende sondern höchstens hunderte Clients verbinden kann - richtig?

Wenn der Client keine Antwort vom Server erhält (was ja der Standardfall sein sollte) und seinerseits jetzt Änderungen veranlassen oder weitere Daten abrufen will, muss er dann eine weitere Verbindung aufbauen oder kann er den wartenden Thread abbrechen, seine Kommunikation abwickeln und wieder in den Wartemodus gehen?

Indys hätten keine Nachteile gegenüber blockierenden Sockets, abgesehen von den erweiterten Möglichkeiten und unterstützen Protokollen?
Also die Kommunikation und der Ablauf an sich wären quasi identisch - richtig?

**Zacherl**

Zitat von stahli:

Du beziehst Dich aber auf long polling, bei dem der Client einen extra Thread startet, der bis zur Antwort vom Server blockiert - richtig?

Genau.

Zitat von stahli:

Dann muss aber auch der Server eine Connection pro Client offen halten - richtig?
Das würde bedeuten, dass man nicht tausende sondern höchstens hunderte Clients verbinden kann - richtig?

TCP Connections hält man bei solchen Anwendungsfällen eigentlich immer permanent offen. Unter Windows kannst du mit einem

IOCP Server durchaus auch tausende Verbindungen gleichzeitig offen halten. Hierbei wird dann nicht pro eingehender Client Verbindung ein Thread erstellt, sondern ein Thread-Pool genutzt.

Zitat von stahli:

Wenn der Client keine Antwort vom Server erhält (was ja der Standardfall sein sollte) und seinerseits jetzt Änderungen veranlassen oder weitere Daten abrufen will, muss er dann eine weitere Verbindung aufbauen oder kann er den wartenden Thread abbrechen, seine Kommunikation abwickeln und wieder in den Wartemodus gehen?

Das sollte gehen. Eventuell solltest du dir aber auch mal UDP (und eventuell das

enet-Protokoll) anschauen. Bei UDP bleiben keine dauerhaften Verbindungen offen und es ist performanter, wenn du viele schnelle Änderungen übertragen willst (besonders, wenn es nicht so wichtig ist, dass wirklich ALLE Pakete ankommen). Würde ich aber nur dann in Betracht ziehen, wenn du immer einen kompletten Kontext übertragst und nicht bei inkrementellen Änderungen (da bei UDP nicht garantiert ist, dass die Pakete überhaupt und in der richtigen Reihenfolge ankommen).

Zitat von stahli:

Indys hätten keine Nachteile gegenüber blockierenden Sockets, abgesehen von den erweiterten Möglichkeiten und unterstützen Protokollen?
Also die Kommunikation und der Ablauf an sich wären quasi identisch - richtig?

Das stimmt. Die Indys sind sogar glaube ich standardmäßig auch auf blocking eingestellt.

**mjustin**

Zitat von Zacherl:

Das stimmt. Die Indys sind sogar glaube ich standardmäßig auch auf blocking eingestellt.

Indy arbeitet nur mit blocking Sockets, einen Schalter für non-blocking haben sie nicht:

http://www.swissdelphicenter.ch/en/showarticle.php?id=4

Zitat:

Indy is Blocking

Indy uses blocking socket calls. Blocking calls are much like reading and writing to a file. When you read data, or write data, the function will not return until the operation is complete. The difference from working with files is that the call may take much longer as data may not be immediately ready for reading or writing (It can only operate as fast as the network or the modem can handle the data).

Für länger laufende Aktionen, z.B. Warten auf asynchrones Daten vom Server im TidTelnet Komponente, arbeiten die Indys mit Threads.