Spielwiese - SocketTest

[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?