BMP bzw. Stream Indy TCPServer an alle verbundenen Clients schicken

[mytbo]

Zitat:

Zitat von Hobbycoder (Beitrag 1474878)

hat jemand ein gutes Beispiel, wie ich per Indy TCPServer ein Bitmap oder besser noch einen Stream an alle aktuell verbundenen Clients senden kann?

Wenn es auch mit der Open Source Library mORMot sein darf, kannst du es mit WebSockets implementieren. In der Hilfe zum WebSockets support findest du die notwendigen Informationen. Das hilfreiche Forum findest du hier.

Bis bald...
Thomas

[Harry Stahl]

Zitat:

Zitat von Michael II (Beitrag 1475039)

Zitat:

Zitat von Harry Stahl (Beitrag 1475037)

Ich habe mich bei meinem Programm (https://www.hastasoft.de/pcnetwork/index.html) letztlich für die zweite Lösung entschieden (also Abfrage in einem vom User angebbaren Zeitraum), da oft nicht eine Rückverbindung vom Server zum Client gegeben ist,

Bei tcp hast du eine Verbindung, welche Datenaustausch in beide Richtungen erlaubt. Sobald und solang also der Client mit dem Server verbunden ist, hast du einfach zwei "Endpunkte", welche je Daten senden und empfangen können.

- D.h. der Client muss also nicht ständig fragen "Server hast du mir Daten". Der Server sendet einfach...
- Der Client muss keine Portweiterleitungen o.ä. im Router vornehmen.

https://de.wikipedia.org/wiki/Transm...ntrol_Protocol

Kurz: Der Client verbindet mit dem Server. Du lässt die Verbindung Client-Server offen. Sobald Client oder Server Daten senden wollen tun sie das einfach...

Der Server kann direkt in die einmal erstellte Verbindung antworten, das stimmt. Aber wie bewerkstelligst Du es, wenn der Server von sich aus Daten an den Client senden will (etwa, nur wenn Bedarf besteht)? Denn es gibt ja kein vergleichbares "OnExecute" Event in der TCPidTCPClient Komponente...

[Michael II]

Hallo Harry

meine Bemerkung zu tcp war genereller Art und nicht Indy/ICS oder was auch immer spezifisch.

Ich verwende ausschliesslich ICS und kenne Indy sehr schlecht (und die 4'700 seitige PDF Anleitung mag nun echt niemand lesen ;-)).

Aber soweit ich sehe, verwendet Indy "IOHandler" über welche die Kommunikation abgewickelt wird. Es gibt doch sicher Beispiele bei Emba.

Wenn du dort keins findest Hier gibt's eins inkl. herunterladbarem Code. Wenn du dem Serverprogramm noch ein SendeEdit:TEdit und einen SendeButton:TButton spendierst und das Beispiel durch den folgenden Code erweiterst

Delphi-Quellcode:

procedure TFServer.SendeButtonClick(Sender: TObject);
begin
  broadcastmessage( SendeEdit.Text );
end;

dann hast du ein "Client kann senden" und "Server darf aber auch" Beispiel.

[Harry Stahl]

Zitat:

Zitat von Michael II (Beitrag 1475061)

Wenn du dort keins findest Hier gibt's eins inkl. herunterladbarem Code...

Wow, herzlichen Dank, wieder was dazugelernt...

Das wird mir bei einer Reihe von meinen Netzwerkprogrammen das Handling sehr vereinfachen...:thumb:

(Das ist ein schönes Beispiel hier, dass man auch mit Wissenszuwachs belohnt werden kann, wenn eigentlich selber weiterhelfen wollte...)

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.

Meine bestehende Anwendung kann ich daher leider nicht so einfach umstellen (müsste Senden und Empfangen splitten), aber für neue Anwendungen sicher eine Option...

[Schwedenbitter]

Zitat:

Zitat von Harry Stahl (Beitrag 1475065)

(Das ist ein schönes Beispiel hier, dass man auch mit Wissenszuwachs belohnt werden kann, wenn eigentlich selber weiterhelfen wollte...)

Und das ist auch der Grund, warum ich hier mitlesen wollte. So eine Funktion scheint es im Forum nicht zu geben: E-Mail Benachrichtigung zu einem Thema, wo man nichts schreibt :gruebel:

Aber mal zum Thema zurück:
Kümmern sich die Indys/ICS darum, dass die Pakete vollständig und in der richtigen Reihenfolge ankommen?
Ein Screenshot - noch dazu als BitMap - dürfte recht groß sein. Wenn man das z.B. mittels VPN über das Internet sendet, wird das bei einer MTU von 1.500 Bytes sonst echt spannend.

[himitsu]

Um das Ankommen, die Reihenfolge und die Datenintegrität kümmert sich das Transport-Protokoll, also z.B. hier TCP/IP, nicht die Indy.
Die Packete sind nummeriert und werden bei Ankunft entsprechend behandelt.
Indy kümmert sich nur um die Übertragungsprotokolle (HTTP/FTP/...).

Bei UDP dagegen kann was verloren gehen, da nur "blind" gesendet wird, aber es keine Rückantwort gibt.

[Michael II]

Zitat:

Zitat von Schwedenbitter (Beitrag 1475069)

Kümmern sich die Indys/ICS darum, dass die Pakete vollständig und in der richtigen Reihenfolge ankommen?
Ein Screenshot - noch dazu als BitMap - dürfte recht groß sein. Wenn man das z.B. mittels VPN über das Internet sendet, wird das bei einer MTU von 1.500 Bytes sonst echt spannend.

Wenn du eine tcp Verbindung aufbaust, dann musst du dich nicht um die Reihenfolge der Daten kümmern; auch nicht um MTU, das geschieht nicht in "deiner Schicht".
D.h. du kannst zum Beispiel 5*32KB und dann noch 3*12KB senden - und alles kommt (bei tcp) immer in der korrekten Reihenfolge an. Ein Paket kann in mehreren Teilen ankommen, oder es landen gleich mehrere Pakete aufs Mal bei deinem Programm. Je nach verwendeter Methode zum Einlesen der Daten (Indy/ICS) merkst du davon was (oder eben auch nix).

Wie weiter oben erwähnt wird: Wenn du über eine Verbindung zum Beispiel Chatmeldungen und Bitmaps senden willst, dann musst du für ein Protokoll sorgen, dank welchem du erkennst was ankommt.

Am besten definierst du einen "Meldungstyp" in der Art: WAS WIEVIEL DATEN
Wenn du eine Bitmap sendest, dann sendest du WAS=BITMAP WIEVIEL=LÄNGE DER DATEN DATEN=BITMAPDATEN. Wenn du eine Chatmeldung sendest, dann sendest du CHAT 5 HALLO.

Der Empfänger liest ankommende Daten in einen Buffer, und übergibt diesen Buffer einem Parser, welcher checkt, ob eine vollständige Meldung angekommen ist. Wenn eine Meldung angekommen ist, dann löschst du die Meldung aus dem Buffer und rufst entsprechende Hilfsfunktionen (Chatmeldung anzeigen, Bitmap speichern etc.) auf. Wenn der Buffer noch nicht leer ist, dann rufst du erneut den Parser auf, bis sämtliche Befehle abgearbeitet sind.

[Schwedenbitter]

Ich stelle gerade fest, dass ich meine Frage wohl missverständlich formuliert habe. Entschuldigung!

Ich habe bereits ein Chat-Programm auf Basis der schon genannten Empfehlung, welches hier schon empfohlen wurde.

Zitat:

Zitat von Jumpy (Beitrag 1474967)

https://entwickler-ecke.de/topic_66706.html

Zwangsläufig hatte ich mich mit den Untis beschäftigt. Und zumindest beim Bitmap-Empfang erfolgte eine Prüfung, ob die Pakete in der richtigen Reihenfolge kamen. Auch das System TCP/IP meine ich mit meinem laienhaften Verständnis einigermaßen erfasst zu haben. Ich bin eben nur Hobby-Programmierer.

Aber:

1. Verstehe ich das richtig, dass ich das alle eben genannte vergessen kann und mich bei den Indys bloß noch um das Übertragungsprotokoll als solches kümmern muss? (Das dürfte für den Fragenersteller auch interessant sein.)
2. Und verstehe ich das richtig, dass die Indys das auch so machen, dass mein Programm nicht mehr "einfriert", wenn die Verbindung eines Client hängt? (Bei Narses gibt es dazu einen händischen, aus meiner Sicht aufwändigen QoS-Teil in der Unit.) Oder wäre das nur bei den genannten ICS so?

:gruebel:

[mjustin]

Zitat:

Zitat von Schwedenbitter (Beitrag 1475089)

1. Verstehe ich das richtig, dass ich das alle eben genannte vergessen kann und mich bei den Indys bloß noch um das Übertragungsprotokoll als solches kümmern muss? (Das dürfte für den Fragenersteller auch interessant sein.)
2. Und verstehe ich das richtig, dass die Indys das auch so machen, dass mein Programm nicht mehr "einfriert", wenn die Verbindung eines Client hängt? (Bei Narses gibt es dazu einen händischen, aus meiner Sicht aufwändigen QoS-Teil in der Unit.) Oder wäre das nur bei den genannten ICS so?

1. ja, genau so ist es (kein eigenes "Parsing" notwendig um zu erkennen ob eine auf Netzwerkebene päckchenweise gesendete Nachricht komplett angekommen ist)
2. serverseitig: ja; clientseitig muss ein Thread verwendet werden wenn die restliche Anwendung nicht einfrieren soll

[stahli]

[OT]

Zitat:

Zitat von Schwedenbitter (Beitrag 1475069)

Und das ist auch der Grund, warum ich hier mitlesen wollte. So eine Funktion scheint es im Forum nicht zu geben: E-Mail Benachrichtigung zu einem Thema, wo man nichts schreibt :gruebel:

Doch, oben über Themen-Optionen kannst Du das Thema explizit abonieren.

[/OT]