Basis für Multiuser Stream Server

Hier könnt Ihr gute, von Euch geschriebene Codes posten. Sie müssen auf jeden Fall funktionieren und sollten möglichst effizient, elegant und beispielhaft oder einfach nur cool sein.
Benutzeravatar
mk-soft
Beiträge: 3855
Registriert: 24.11.2004 13:12
Wohnort: Germany

Basis für Multiuser Stream Server

Beitrag von mk-soft »

Hi,

Es kommen öfters fragen wie man mehrere User verwaltet und Daten sicher über das Netzwerk versendet.
Dazu verwende ich ein eigenes binäres Protokoll welches auf TCP aufsetzt.

Die Verwaltung läuft über eine LinkedList mit der Struktur udtManager. In dieser werden alle Informationen des angemeldeten Clients gespeichert.

Jedes gesendete und empfangende Paket fäng mit eine Header an

Structure udtHeader
Ident.w -> Feste Server ID, Muss gleich sein
Version.w -> Feste Server Version, muss gleich sein
Command.w -> Befehl von Server oder Client
Size.w -> größe der angehängten Daten
EndStructure

Sollten die Ident oder Version nicht stimmen, so trennt der Server automatisch die verbindung.
Des gleichen auch wenn die Größe der angehängten Daten nicht stimmt.

Der StreamServer als Beispiel sendet zyklisch alle Daten der angemeldeten Clients an alle Clients. Um so mehr Clients angemeldet sind um so grösser werden diese Daten.

Link zu den Dateien:
http://mk-soft.homepage.t-online.de/fil ... eamServer/

FF :wink:

P.S. Der TestClient läuft nichtz ganz sauber
Alles ist möglich, fragt sich nur wie...
Projekte ThreadToGUI / EventDesigner V3 / OOP-BaseClass-Modul
Downloads auf MyWebspace / OneDrive
Benutzeravatar
HeX0R
Beiträge: 3042
Registriert: 10.09.2004 09:59
Computerausstattung: AMD Ryzen 7 5800X
96Gig Ram
NVIDIA GEFORCE RTX 3060TI/8Gig
Win11 64Bit
G19 Tastatur
2x 24" + 1x27" Monitore
Glorious O Wireless Maus
PB 3.x-PB 6.x
Oculus Quest 2 + 3
Kontaktdaten:

Beitrag von HeX0R »

Ich muß leider sagen, dass das nicht wirklich für den praktischen Einsatz taugt.
Es wird nirgends der Rückgabewert von SendNetworkData() beachtet, der jedoch sehr wichtig ist.

Gerade, bei heftigem Netzwerkverkehr kommt es hier öfter zu einem Rückgabewert von -1 und einer WSAEWOULDBLOCK Meldung, was nix anderes heisst, als dass der Empfangsbuffer voll ist, und man das Paket erneut senden muß (und das eigentlich erst, wenn eine FD_WRITE Msg ankommt... das ganze ist recht komplex und lässt sich richtig eigentlich gar nicht ohne API machen...).

Beachtet man das nicht, ist das Paket verschollen, was natürlich zu seltsamen Ereignissen führen dürfte.

Aber mach dir nix draus, nahezu keine Netzwerkbeispiele sind wirklich alltagstauglich.
Zuletzt geändert von HeX0R am 02.03.2009 01:10, insgesamt 1-mal geändert.
Benutzeravatar
STARGÅTE
Kommando SG1
Beiträge: 7031
Registriert: 01.11.2005 13:34
Wohnort: Glienicke
Kontaktdaten:

Beitrag von STARGÅTE »

Erst mal danke das du es zur Verfügung gestellt hast, abe rauch ich habe n kleine Bemerkung:

die Procedure ReceiveData arbeitet falsch.

Mal angenommen der der Client sendet mehr als der Server empfangen kann (weil er zB "viel zu tun hat" oder das Delay() größer ist)

dann würde im ReceiveNetworkData - Buffer beim Server mehr daten (Gesendete Pakete, header+daten ) liegen als *header\size vorgibt, weil halt der Server mehr Sachen sammeln musste.
das heißt alle weitere Daten werden ignoriert.

Du solltest in ReceiveData n schleife drin haben die, solange wie nötig weilter Ausließt.
PB 6.01 ― Win 10, 21H2 ― Ryzen 9 3900X, 32 GB ― NVIDIA GeForce RTX 3080 ― Vivaldi 6.0 ― www.unionbytes.de
Aktuelles Projekt: Lizard - Skriptsprache für symbolische Berechnungen und mehr
Benutzeravatar
HeX0R
Beiträge: 3042
Registriert: 10.09.2004 09:59
Computerausstattung: AMD Ryzen 7 5800X
96Gig Ram
NVIDIA GEFORCE RTX 3060TI/8Gig
Win11 64Bit
G19 Tastatur
2x 24" + 1x27" Monitore
Glorious O Wireless Maus
PB 3.x-PB 6.x
Oculus Quest 2 + 3
Kontaktdaten:

Beitrag von HeX0R »

Das hier ist in Sachen Netzwerk eine interessante Lektüre.

(Auch die etwas ignorante Art, die Fred damals an den Tag legte... wobei, wenn ichs mir recht überlege... 6.5 Jahre später, ich brauche immernoch API, um "richtig" das Netzwerk zu bedienen...)
Antworten