Server/Client kleine Pakete sehr oft an mehrere Clienten

[sonny2007]

Hiho Zusammen,

ich habe ein Problem mit dem Datenaustausch zwischen mehreren Clienten über einen Server.

Folgendes Szenario

Client 1, Client 2, Client 3
| | |
Server TCP Indy

Jeder Client sendet alle 100-200ms ein Buffer oder Stream von ca 0,2-0,6KByte.

Diese sollen dann vom Server an alle anderen Clienten verteilt werden.

Welcher Lösungsansatz ist der Richtige?
ist TCP die richtige Wahl ?

Folgendes habe ich bisher probiert.
per Stream

Delphi-Quellcode:

....

    ms := TMemoryStream.Create;
    Try
      ms.Write(tmpClient, SizeOf(tmpClient));
      if (SendStream(IdClient, TStream(ms)) = False) then
        Exit;
    Finally
      ms.Free;
    End;

    ms := TMemoryStream.Create;
    Try
      if (ReceiveStream(IdClient, TStream(ms)) = False) then
        Exit;

      //slServerLog.Add('Receive StreamSize ' + IntToStr(ms.Size));
      SetLength(arClients, ms.Size div SizeOf(arClients[0]));
      // Setzen der Anzahl der Elemente im Array
      ms.Position := 0;
      for i := 0 to High(arClients) do
        ms.Read(arClients[i], SizeOf(arClients[i]));
    finally
      ms.Free;
    end;

per Buffer mit Protokoll, was jedoch extrem langsam ist. Habe das Gefühl das es sich eher für Messenger eignet.
Kann aber auch an meiner Unwissenheit liegen.

Grüße
sOn

[stahli]

Es ist besser, wenige größere Pakete zu übertragen als extrem viele kleine.
Ich stand mal bei dem gleichen Problem: http://www.delphipraxis.net/180134-i...ptimieren.html
Also wenn Du einige Daten puffern und dann übertragen kannst würde das sicher helfen.

Indy arbeitet nur blockierend. Client fragt und Server antwortet.
Wenn der Server alle Clients versorgen soll müssen die Clients ständig nachfragen (polling / long polling).



Ich habe jetzt mal Versuche mit asynchroner Kommunikation unternommen und finde das sehr empfehlenswert.
http://www.delphipraxis.net/190482-s...ockettest.html
Mit Hilfe des Frameworks ist die Kommunikation sehr übersichtlich.
Man versendet einfach Nachrichten (Interfaces), die auf der Gegenseite automatisch wiederhergestellt werden und dann nur noch in die Logik übernommen werden müssen.



Es gibt noch alternative Lösungen für die Kommunikation zwischen mehreren Partnern. Dazu kann ich aber nichts genaueres sagen.

[Mavarik]

Zitat:

Zitat von sonny2007 (Beitrag 1358099)

Jeder Client sendet alle 100-200ms ein Buffer oder Stream von ca 0,2-0,6KByte.

Diese sollen dann vom Server an alle anderen Clienten verteilt werden.

Welcher Lösungsansatz ist der Richtige?
ist TCP die richtige Wahl ?

Also... UDP Ist ein bisschen schlanker, dafür ist nicht sichergestellt ob und in welcher Reihenfolge die Pakete ankommen.

TCP/IP ist schon ok... ein Frame ist aber ca 1500 bytes lang inkl. 20 Byte Headerdaten. Und noch das ein oder andere Byte... also Deine 200 oder 600 byte sind kein Thema.

Ein Server spaltet normalerweise für jeden Client einen eigenen Thread ab. Wenn Du die Daten verteilst, Musst Du dem Buffer also so lange im Speicher halten, bis "TimeOut" oder alles Clients Ihn empfangen haben. So sparst Du Dir ne Kopie für jeden Client. (RefCounted Queued- oder Ring-Buffer).

Von diesen Paketen solltest Du im lokalen Netz "physikalisch" ca. 65.000 Stk. pro Sekunde verteilen können.
Bei einer Client Anzahl unter 1000 sollte es also klein Problem sein... :stupid:
Wo bei Du sicherlich nicht 1000 Threads aufmachen willst... :stupid:

aber bei 5-10x pro Sekunde 500 Bytes zu übertragen... an sagen wir mal 10 Clients... kein Thema...

Oder habe ich mich verrechnet? Ist schon spät... 8-)

Mavarik

[mjustin]

Zitat:

Zitat von stahli (Beitrag 1358108)

Indy arbeitet nur blockierend. Client fragt und Server antwortet.
Wenn der Server alle Clients versorgen soll müssen die Clients ständig nachfragen (polling / long polling).

Wenn der Server alle Clients versorgen soll, sendet der Server einfach an alle Clients.
Das geht mit allen Socketverbindungen, Indy ist da keine Ausnahme :)

Sockets sind, sobald einmal die Verbindung hergestellt wurde, bidirektional.

Blockierend und Request/Reply sind zwei verschiedene Paar Schuhe. Wenn der Server an Clients sendet, wird bei Indy die Servernachricht blockierend gelesen. Normalerweise in einem Thread, der im Hintergrund läuft.

Beispiel für Message Push:

https://mikejustin.wordpress.com/201...-push-example/

[stahli]

Da ist man der Meinung, man hätte alles Wesentliche so halbwegs verstanden und dann so was... :oops:

Na gut, mit den asynchronen Sockets komme ich zunächst erst mal wunderbar zurecht, wenn sich da nicht irgendwann doch nochmal Probleme auftun...

[BrightAngel]

Ich finde, wir haben noch zu wenig Informationen vom TE oder?

Ganz konkret gibt es verschiedene Ziele für die man Client/Server Software schreibt:

• Ist es wichtig, dass die Nachrichten von allen Clients zeitnah ankommen (Puffern vs direkt senden)
• Ist es wichtig, dass die Nachrichten überhaupt ankommen (einfaches Notify vs wichtiger Datentransport)
• Werden einzelne Clients untereinander identifiziert? Dürfen Nachrichten verschiedener Clients vom Server zusammengefasst werden? (so wie ich das verstanden habe, soll dass ja ein All-to-all Informationsfluss werden, oder?)
• Ab wann ist ein Client Teil der zu informierenden Clientenmenge (falls TCP: was passiert bei Verbindungsabbruch)
• Wo befindet sich das Setup? Lokales geschütztes Netz vs großes, böses Internet?
• Falls großes böses Internet: Wie sensibel sind die Daten? Sollte man die vielleicht noch TLS tunneln...

Also vielleicht regen diese Punkte noch den weiteren Informationsfluss hier an :)

Brighty

[Namenloser]

Kurze Anmerkung zu mjustin und stahli: Man kann natürlich auch vom Server aus blockierend in den Socket schreiben, ohne dass es vorher eine Anfrage des Clients gegeben haben muss. Allerdings kann dann halt bei Indy, während geschrieben oder sonstwie blockiert wird (vgl. sleep() im Beispiel), keine Nachrichten des Clients empfangen. Prinzipiell geht das zwar mit Sockets mithilfe eines zweiten Threads, aber nicht mit Indy, weil Indy nicht threadsafe ist. Auch die anderen mir bekannten Libs für Delphi bzw. FreePascal haben dieses Problem.

[mjustin]

Zitat:

Zitat von Namenloser (Beitrag 1358163)

nicht mit Indy, weil Indy nicht threadsafe ist

Welche Delphi Version - eins? :)

[scrat1979]

Ich verwende für den Datentransfer über das Netzwerk die Komponenten von ESEGECE. Sehr einfach zu bedienen, für das private Umfeld kostenlos und selbst der Source nicht besonders teuer. Threadsafe, auf den Indys aufbauend, ich bastel mir damit gerade meine eigenen Server und Client-Komponenten. Vielleicht willst du dir das mal ansehen... das waren die einzigen Komponenten, welche es mir EINFACH erlaubten mit dem Netzwerktransfer zurechtzukommen.

[Mavarik]

Richtig gut im threading sind die ICS
Damit kann man ganz schnell einen Client / Server Lösung bauen.