BMP bzw. Stream Indy TCPServer an alle verbundenen Clients schicken

[mjustin]

Zitat:

Zitat von Harry Stahl (Beitrag 1475065)

Nachtrag: Interessanterweise scheint es dann so zu sein, dass mit der idTCPClient-Componente nach einem Writeln nicht mehr direkt eine Antwort des Servers abgefragt werden kann, da die idThreadComponente offensichtlich die Nachrichten zuerst abfängt.

Dann lege das WriteLn ebenfalls in den Thread (vor das ReadLn), dann hast du Request/Response Paare. Das Beispiel ist eher an Telnet angelehnt, wo Client und Server spontan (unabhängig voneinander) etwas mitteilen dürfen.

[Michael II]

Zitat:

Zitat von mjustin (Beitrag 1475101)

Das Beispiel ist eher an Telnet angelehnt, wo Client und Server spontan (unabhängig voneinander) etwas mitteilen dürfen.

Zum Beispiel einander Chatmeldungen oder Bilder senden ;-). Oder bei Spielen, wenn du Daten austauschen willst.

Wenn du nur rasch "Hallo Server, gib mir was" senden willst, dann sind readln/writeln sicher ok - aber für komplexere Anwendungen bist du mit Indys IOHandler oder ICSOverbytes asynchronen Komponentan wesentlich flexibler unterwegs.

[mjustin]

Zitat:

Zitat von Michael II (Beitrag 1475106)

Wenn du nur rasch "Hallo Server, gib mir was" senden willst, dann sind readln/writeln sicher ok - aber für komplexere Anwendungen bist du mit Indys IOHandler oder ICSOverbytes asynchronen Komponentan wesentlich flexibler unterwegs.

Ich meinte ReadLn / WriteLn über Indy. Das kann auch bei Indy der IOHandler.

[Michael II]

Zitat:

Zitat von mjustin (Beitrag 1475108)

Ich meinte ReadLn / WriteLn über Indy. Das kann auch bei Indy der IOHandler.

Wenn ich gecheckt hätte, dass wir dasselbe sagen, dann hätte ich nix geschrieben ;-).

[mjustin]

Zitat:

Zitat von Hobbycoder (Beitrag 1474962)

Das Senden von IdTCPServer habe ich erst mal so gemacht:

Das ist soweit ok, wenn der Client nichts anderes macht als die Bitmaps zu empfangen. Es hat allerdings zwei Nachteile: es wird nur ein Bild gleichzeitig gesendet, wenn es mehrere Clients gibt, dann werden sie nicht parallel mit Daten beliefert, sondern einer nach dem anderen. Und dann ist OnExecute Methode tabu oder wird komplizierter: in OnExecute darf natürlich nicht in den Socket geschrieben werden, während das Bild übertragen wird.

Best practice ist daher, jeder Connection eine Queue zuzuordnen, in der über den Hauptthread Bilder hinzugefügt werden und die dann in OnExecute abgearbeitet wird. Die Clients werden dann parallel Daten erhalten, und die gesamte Steuerung der Kommunikation befindet sich in OnExecute.

Wie man bei Indy weitere Attribute (wie z.B. eine Queue, oder Benutzernamen...) an die eingehenden Connections 'antackert' poste ich später. Es gibt einige Posts bei Stackoverflow in denen das beschrieben wird.

[Hobbycoder]

Ich habe mittlerweile etwas lauffähiges zusammenbekommen.
Da ich mit Indey mittlerweise etwas besser kenne, bin ich dabei geblieben. ICS werde ich mir mal anschauen, aber da müsste ich mich neu einarbeiten. (Sind zwischen Indy und ICS performanceunterschiede bekannt? )

Ich habe das letztlich so gemacht, dass der Client halt beim Server sagt "Gib mir was" und der Server sendet halt per stream das Bild (zum verringern der Datenmenge als JPG) an den Client unmittelbar zurück.
So weit, so gut.
Vorerst habe ich damit das erreicht was ich wollte. Denn in meinem Fall reicht es aus in einem Interval von 10 Sekunden ein aktuelles Bild zu erhalten. Ich brauche keinen Livestream ala Teamviewer und ich muss auch nicht mit den anderen Bildschirm interagieren. Auch ist die interne Netzwerkstruktur hier nicht das Problem, denn ich habe selbst die Kontrolle über die Router/Firewalls dazwischen.

Aber natürlich packt einen bei einem solchen Projekt auch ein wenig der Ergeiz. Mittlerweise habe ich mir die Display Duplication API angeschaut, mit deren Hilfe es natürlich einfacher ist, die Datenmenge zu veringern, weil man nach dem ersten Bild nur noch die Teilbilder schickt, in denen sich Änderungen ergeben. Damit läßt sich auch bei geringerer Bandbreit ein gutes Ergebnis erzielen.

[Harry Stahl]

Zitat:

Zitat von Hobbycoder (Beitrag 1475365)

Denn in meinem Fall reicht es aus in einem Interval von 10 Sekunden ein aktuelles Bild zu erhalten. Ich brauche keinen Livestream ala Teamviewer und ich muss auch nicht mit den anderen Bildschirm interagieren. Auch ist die interne Netzwerkstruktur hier nicht das Problem, denn ich habe selbst die Kontrolle über die Router/Firewalls dazwischen.

Aber natürlich packt einen bei einem solchen Projekt auch ein wenig der Ehrgeiz. Mittlerweise habe ich mir die Display Duplication API angeschaut, mit deren Hilfe es natürlich einfacher ist, die Datenmenge zu verringern, weil man nach dem ersten Bild nur noch die Teilbilder schickt, in denen sich Änderungen ergeben. Damit läßt sich auch bei geringerer Bandbreite ein gutes Ergebnis erzielen.

Nachdem ich diesen Thread las, hatte ich auch noch mal Lust bekommen, an meinem PC-Network Remote Server & Controller Programm weiter zu arbeiten. Das letzte mal war das vor ca. 5 Jahren. Mit aktuellen PC's, dem neuesten Delphi (das ja auch wirklich in den letzten Jahren für schnelleren Code sorgt) und kleineren Optimierungen habe ich das Programm noch mal deutlich von der Geschwindigkeit optimieren können, innerhalb des lokalen Netzwerks ist die Bildschirmübertragung fast Echtzeit.

Habe daher eine neue Version veröffentlicht, bei Interesse ist ein kurzes Demo (ca. 1 Minute) bezüglich der Bildschirm-Übertragung hier zu sehen: https://youtu.be/vZmSHxN0d68?t=30

Dabei muss ich anmerken, dass der Client in einer virtuellen Windows-Maschine lief und ich gleichzeitig das Video aufgenommen habe. "In echt" geht es also noch etwas schneller.

Dabei hat sich heraus gestellt, dass die Indys gar nicht das Problem waren, sondern das Einfangen des aktuellen Bildschirms (auf dem älteren Entwicklungs-PC nicht unter 40 MS machbar, auf dem neuen müsste ich mal testen, muss aber deutlich schneller sein).

Für das Überprüfen, welche Bereiche im Screenshot geändert sind, brauche ich ca. 8 ms (auch alter Entwicklungs-PC).

Auch wenn das eigentlich schnell genug sein sollte, würde mich Dein Hinweis auf die Display Duplication API interessieren. Hast Du das tatsächlich mal getestet und wenn ja, dann gibt es schon eine Delphi Implementation dafür?