Hi Leute,
ich habe ein Problem mit dem TserverSocket und dem TCLientSocket.

Server und Client kommunizieren mithilfe eines Records. (Socket.SendBuf(...))
Über diesen Record tauschen sie sich die ID aus und andere Hintergrund-Verbindungs-Sachen.

Für die eigentlichen Daten meines Spiels/ Programms will ich Streams verschicken, indem ich alle
Daten hintereinander in einen Stream packe.
Senden tue ich ihn ja mit der Funktion Socket.Sendstream(...)
Das Empfangen macht aber Probleme...

Einerseits könnte meine Empfangenen Daten der Kommunikations-Record sein oder der Data-Stream.
Das muss ich in der OnClientRead Procedure ja herausfinden, und da liegt mein eigentliches Problem.

Die Procedure ist folgendermaßen aufgebaut:



Irgendwie merkt die Procedure nicht, wenn statt eines Records ein Stream ankommt.
Geht das etwa garnicht (oder so nicht) ?
Was mache ich falsch?!

Vielen Dank im vorraus.

_________________
http://texelviews.delphigl.com

igitt. Einfach nur über die Länge abzuprüfen, was das empfangene ist, halte ich für eine denkbar schlechte Idee. Sende doch stattdessen sowohl Record als auch Stream.
bzw...
Als allererstes, bevor du was sendest, schreibst du in den Strom, den du sendest, WAS du eigentlich sendest. Damit die anderen Routinen auch wissen, was sie dann mit den empfangenen Sachen machen sollen.

Außerdem solltest du imao wenn du schon dabei bist, dann gleich nur Streams senden. Kannst ja nen MemoryStream anlegen und dann da deine Records und anderen Streams ganz einfach reinpacken. Dann versendest du das inklusive der Info, was damit geschehen soll und du bist auf der sicheren Seite.

Nebenbei... Kann ich dich für Synapse begeistern? Falls du ne Crossplattform-Anwendung schreiben willst, solltest du da nen Blick drauf werfen. Ist definitiv ziemlich geil

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Außerdem sollte man das ganze Zeit-Insensitiv senden!

Das heißt, wenn du Socket.SendText/wasauchimmer('ABC'); und Socket.SendText('DEF'); schnell hintereinander senden würdest mit 2x SendText/stream/Buffer/wasauchimmer, dann würde die Gegenseite nicht wie man erwartet, 2 Strings mit ABC und DEF empfangen, sondern der Event würde dann genau einmal ausgelöst und man würde 6 Zeichen mit dem Inhalt ABCDEF zurückbekommen.

Andersherum gilt es natürlich auch: Wenn man einmal zB 20.000 Zeichen sendet, kann es Dir passieren, besonders über das Internet, das der Event OnRead zwei, drei oder sogar mehrmals ausgelöst wird und im ersten Happen 14.000 und im zweiten Happen dann die restlichen 6.000 Bytes empfängst, wohlgemerkt obwohl Du alles mit einem "Rutsch" (sprich SendText, SendBuffer etc) gesendet hast.

Das heißt: Sockets sind "Streams" und beim SendText/Buffer/Wasauchimmer sendet es kein Termination aka. "Hier-ist-ende"-Byte mit. Das muss man nämlich selber machen.

Also mein Tipp, man sollte die Längenangabe mitsenden inklusive den Datentyp, damit der andere weiß, was es ist. Und sollte die Anzahl der Bytes der empfangenen Daten nicht der vorher übergebenen Länge übereinstimmen (was bei längeren Stücken passieren kann), sollte man ein temporären Buffer erstellen, der solange wächst (buf := buf + Socket.ReceiveText/Buffer/data/etc), bis Länge >= angegebene Länge ist und es DANN erst verarbeiten.

Da muss man sehr aufpassen: Termination-Byte / Längenangabe nicht vergessen mitzusenden, sonst kann es zB passieren, das das Programm im LAN super funktioniert und plötzlich im Internet sein Dienst versagt, weil die Behandlungsroutine nicht mit Häppchen umgehen kann und den gesamten Buffer unbedingt in einem Abwasch serviert kriegen will.

Genial
Das ich da net selbst drauf gekommen bin ...
Ich muss den Code halt noch etwas umschreiben aber ich denke das wird dann gehen.


Klingt interessant! Was es net alles gibt..


@Noop:
Kann dieses "in-einem-Rutsch-senden, in-zwei-happen-empfangen" (und umgekehrt) -Problem im Lan
auch auftreten? oder nur im Internet?
Ansonsten müsste ich das Termination-Byte auch noch mit in den Stream packen.
Danke für den Hinweis.

_________________
http://texelviews.delphigl.com

Kann sein, dass ich mich irre, aber bei TCP/IP sollte sowas nicht passieren. TCP/IP sollte doch eigentlich selbst dafür sorgen, dass die gesendeten Sachen korrekt in kleinere Pakete geteilt werden, wenn sie zu groß sind, und wieder beim Empfänger korrekt zusammengesetzt werden. imho stellt sich dieses Problem nur bei UDP oder vergleichbarem.
Kann aber auch sein, dass ich mich irre. Den größten Teil meiner Netzwerkerfahrung kann ich nämlich nur im LAN vorweisen Und die paar Sachen, die mich ins Internet geführt haben, gingen alle reibungslos.

€dit: Es ist aber dennoch nicht verkehrt, am Anfang die Größe der zusendenen Daten mitreinzupacken. Ein Termination-Byte halte ich für nicht sinnvoll. Da müsstest du dann auch noch escapen - was passiert denn, wenn du eine Datei versendest, die zufällig dieses Termination Byte drin hat? Dann hast n Problem
Drum die Größe vorher reinschreiben. Also genauso, wie man auch strings speichert. Da strings ja bekanntlich letztendlich dynamische Arrays sind, kann man diese nicht einfach so speichern. D.h. speichern geht schon. Aber wenn man das Zeug wieder einlesen will, weiß man ja nicht, wo der string aufhört. Drum vorher die Länge des strings speichern und dann den string. k?

€dit 2: Wenn du tatsächlich noch am Anfang bist, dann solltest du Synapse wirklich ne Chance geben. Wer gerne die Vielfalt und den Protokoll-Support der Indy-Komponenten aber dabei eine einfache Bedienung und richtige Performance will, für den ist Synapse die richtige Wahl imho
Kleines Beispiel, um ne Datei per http runterzuladen mittels Streams:

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Hi,
ich bin gerade dabei eine Unit zu schreiben mit der man, unabhängig von dem Spiel was man schreibt,
leicht einen Datenaustausch zwischen Server und Client vornehmen kann, ohne sich um Hintergründiges zu kümmern
(wie zB. Log, dis/connecten, ID bekommen, neue ID bekommen wenn einer das Spiel verlässt, Clientlist etc).

_________________
http://texelviews.delphigl.com

Nennt sich auch neudeutsch "Engine" .

Sehr vernünftig sowas. Das ist einer der ersten Schritte zu imho gutem Code Verteile sowas aber bitte in eine sinvolle Ordnerstruktur und auf mehrere Units. Und mach es OOP. Ist immer gut Falls du mal keine Idee hast, wie du z.B. den Logger am elegantesten in eine Klasse packst, dann kannst du ja mal bei X-Dream vorbeischauen. TAK2004 und meine Wenigkeit arbeiten da gerade dran und wie eigentlich jede Engine dient auch diese der Vermeidung von Redundanzen (Means: nicht immer für jedes Projekt immer dasselbe nochmal schreiben z.B. Logger etc.). Läuft im Endeffekt darauf hinaus, dass man dann nur einmal einen Logger, eine GUI oder einen Texturmanager schreibt, diese dann aber gscheit Anders gesagt: Qualität statt Quantität.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Falsch!
Das was du genannt hast, das mit dem Zerteilen und Zusammensetzen, spielt sich in einer ganz anderen Liga ab, und zwar nicht für die Applikation-Ebene, denn die muss selber dafür sorgen, die Pakete auch zeitmäßig korrekt zu zusammengesetzt und verarbeitet wird.

TCP/IP garantiert Dir nur, DAS die Pakete ALLE ankommen und in der richtigen Reihenfolge, und das tut IP, indem es schon beim Routing bereits kleine IP-Pakete (max 65536 Bytes!) in noch kleinere Pakete (~1000 Bytes) zerteilt falls notwendig, aber TCP/IP kann dir unmöglich garantieren das die auf einmal und gleichzeitig beim Empfänger ankommenm, wenn du was größeres sendest. Wie denn auch, wenn man 20.000 Bytes senden will und nach 10.000 Bytes die Netzwerkverbindung gestört ist oder halt langsame Verbindung und die ersten Bytes schon gesendet wurden? Du WIRST in diesem Fall OnRead +zweimal+ oder mehrmals ausgelöst kriegen und die Bytes zwar vollständig, aber in Häppchen serviert bekommen. Die Sache ist ja, sobald man Send() machst, sieht der Empfänger die ersten Bytes bereits bevor der Absender den letzten Byte erfolgreich abgeschickt hat.

Nochmal: Socket sind Streams und kennen keine "Terminierungsbytes", ergo du musst das Längenbyte mitsenden, also nach dem Format {6}123456{12}Beispiel{}12{0}{5}abcde{100}100Bytes--usw., wenn erst Längenbyte und dann gnadenlos die {n} Bytes ausliest, dann kann nichts passieren, egal was im String ist.

PS nach meiner Erfahrung tritt die Zerstückelung im LAN bei Paketen >8000 Bytes und im Internet ab ~200-1000 bytes auf, nochmal TCP/IP ist NICHT dafür zuständig das die Pakete im richtigen Timing ankommen, sondern nur DAS sie ankommen

Ja ne. Das ist soweit auch klar. Vielleicht sollte noch geklärt werden, ob es hier um synchrones oder asynchronen Datentransfer geht. bei synchronen nämlich sollte das nicht passieren. Immerhin blockieren die solange, bis sie alle Daten haben oder es ein Timeout gibt. Synapse z.B. ist synchron. Imho braucht man sich dann nicht mehr um solche primitiven Sachen wie zusammensetzen von Paketen kümmern.

So Sachen wie OnRead... Ich hatte bislang immer stillschweigend angenommen, dass diese Ereignisse erst dann ausgelöst werden, wenn alles angekommen ist. Wie gesagt, auch größere Dateien (waren schon ein paar Dutzend MB) hab ich im LAN mit den Sockets rumgeschickt und es verlief absolut reibungslos.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Das kann gut sein, das beim Synchronen (aka "Blocking Mode") solange anhält bis auch der letzte Byte gelesen wurde.

In der Funktion selber, die von irgendwo initiert werden muss (ReceiveBuf, ReceiveText etc.) müsste aber Windows dann solange "steckenbleiben" (deshalb heißt es ja "Blocking Mode"), bis auch der letzte Byte gelesen wurde oder ein Timeout gibt - Richtig!

Ein Problem weniger, gut, aber dann bleibt noch die Frage, wenn die zu empfangene Länge unbekannt ist, woher soll - selbst ein synchroner Socket - wissen, WANN Ende ist? Wenn 1 Sekunde lang nichts kommt? Wenn 5 Sekunden lang nichts kommt? Wenn 15 Sekunden lang nichts kommt?

Ich würde also deswegen zur Sicherheit aufjedenfall IMMER eine Länge voraussenden und ihn solange blocken lassen, bis er die "X" Bytes empfangen hat, und dann die Ausführung sofort fortsetzen, ohne nach der Methode "solange lesen bis X sekunden nichts kommt", die den User auch noch warten lässt.

Das kann ich dir sagen. Weil nämlich, sobald das Paket vollständig angekommen ist, bekannt ist, wo es aufhört. Im Paket-Header selbst ist nämlich dessen Größe angegeben afaik und dadurch weiß der Empfänger auch, wo das Paket anfängt und wo es aufhört. Das wird aber durch TCP/IP geregelt. Sollte mich mal n bisschen intensiver mit dem OSI Zeug beschäftigen. Hatte das mal alles drauf ^^

Jedenfalls... mit "blocking" Sockets (nur Microsoft nennt die Teile so. Normalerweise nennen die sich synchron *g*) sollte es keine Probleme geben. Asynchrone (also nonblocking *g*) entstanden iirc mit Win 3.11. Weil dort Multithreading nicht wirklich nutzbar war. Da wir aber nun Multithreading haben, braucht man lediglich jeden Socket nur in nen eigenen Thread packen und voila. Schon wartet der sorgfältig darauf, dass er das Paket auch ganz bekommt und man braucht sich nicht mehr darum zu kümmern, andererseits friert einem aber währenddessen auch nicht die Anwendung ein.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Ahh... ich wusste doch das mir irgendwas fehlte bei den synchronen. Mit threads machen die richtig sinn.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Wenn du dir die IP-Spezifikation anguckst, siehst du, ein IP-Paket darf MAXIMAL 65.536 Bytes groß sein


Wiegesagt, das gilt nur für Pakete <65536 Bytes. Sind die größer, muss nämlich die Send()-Methode mehrmals angewendet werden (bei Komponenten tut das die Methode automatisch, das man nichts mehr merkt) und auf der Empfängerseite ist eine bekannte Methode, größere Brocken zu empfangen, die, solange zu warten, bis x Sekunden nichts mehr kommt. Aber ICH würde das so nicht machen, mit der Wartemethode.

hm. Wartemethode fände ich auch etwas dirty. Mir fällt grad auf, dass ich eigentlich bei TCP/IP nur mit synchronen Sockets gearbeitet hab. Sowohl unter Delphi als auch unter PHP. Nur UDP hat mich mal in die asynchrone Welt entführt, dort ist aber eh vieles anders

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Ja, bei UDP/IP hast du nichtmal die Garantie, das es ankommt, aber synchrone Sachen kannst du theoretisch auch mit UDP machen oder zumundest simulieren, aber wehe es kommt ein Paket mal nicht an: dann hängt das Programm solange, bis der Timeout kommt, deswegen finde ich es besonders da sinnvoll, asynchron zu arbeiten.
Wenn ich UDP benutze, dann nur für Liveübertragungen oder andere Sachen wo ruhig paar Sachen fehlen dürfen. Übringens zum Sicherheitstechnischen: IP-Absenderadressen von einzelnen UDP lässt sich auch in der Praxis leicht spoofen, wobei man bei TCP die Sequenznummer erraten müsste. Daher kanns passieren, wenn ein UDP-Dienst auf ein UDP-Paket mit vielen UDP-Paketen ungeprüft reagiert und das Programm sehr bekannt ist, das dieser Dienst durch füttern von gespooften Paketen auf mehreren Rechnern mit viel Bandbreite und wo das Programm läuft, als DDoS-Schleuder/Beihilfe missbraucht wird.

Nochmal zum IP: Paketgrößen sind auf 65.536 Bytes beschränkt. Alles was drüber ist, da kann einen TCP/IP nicht mehr garantieren, das sie richtig wieder auseinandergelegt werden. Deswegen, lieber Längenbyte voraussenden als diese "Dirty" Wartemethode.