Einzelnen Beitrag anzeigen

Astat

Registriert seit: 2. Dez 2009
Ort: München
320 Beiträge
 
Lazarus
 
#17

Re: Stream über TCP - Blockaufteilung ?

  Alt 8. Dez 2009, 05:02
Hallo sx2008, anbei einiges was mir unklar ist.
  • sx2008 hat geschrieben
Message Framing wäre das Suchwort für Google.
Der Absender sendet einzelne Messages (=Botschaften, Befehle, Commands) in einen TCP/IP Stream und der Empfänger hat die Aufgabe
die einzelnen Messages auch dann sauber zu trennen, wenn er immer nur einzelne Bruchstücke bekommt.
Im Extremfall tröpfeln die Bytes einzeln ein.


Meinst du mit "Message Framing" den Socket API Parameter "SOCK_SEQPACKET"!?
  • sx2008 hat geschrieben
1.) feste Blockgrösse, Sender und Emfänger vereinbaren eine feste Blockgrösse
Messages, die kleiner sind werden mit Leerzeichen oder #0 aufgefüllt.


Ist das nichgt sehr ineffizient, nicht notwendige Daten zu übertragen?
  • sx2008 hat geschrieben
2.) Jede Message wird mit CR/LF abgeschlossen


Warum brauch ich dann eine mit "werden mit Leerzeichen oder #0 aufgefüllt." großen Block?
Ich hab ja ein ASCII Protokoll, das wenn CR/LF kommt mir einen ganzen Datensatz anzeigt!?
Hier verstehe ich etwas nicht, kannst Du das genauer ausführen?
  • sx2008 hat geschrieben
3.) Jede Message beginnt mit einem 4-Byte Int, in dem die Anzahl der folgenden Nutzdaten vermerkt ist.
Meinst du hier eine Art Header?. Was ist aber, wenn jede Message aber mit einem Byte beginnen??

  • sx2008 hat geschrieben
Variante 1.) ist sehr unflexibel.

Geht das auch bei einem Webserver?
  • sx2008 hat geschrieben
Variante 2.) hat Vorteile beim Debuggen aber problematisch für binäre Daten
Verstehe ich auch nicht, kann ja auch Binär Dateien debugen, kannst du das genauer erklären?
  • sx2008 hat geschrieben
und Variante 3.) eignet sich am Besten für grosse binäre Daten.
Der HTTP Header macht das ja ähnlich, mit content length, und da spielet die Größe ja auch keine Rolle?
Wie meinst Du das?
  • sx2008 hat geschrieben
Das Grundprinzip wie man die Messages beim Empfänger bildet ist aber immer das Gleiche.
Man braucht einen globalen Puffer für die Verbindung.


Wäre nicht ein lokaler Buffer, jeder Client erhält einen eigenen Buffer, so wie es ein Webserver macht, zweckmäßiger?

  • sx2008 hat geschrieben
Ich bevorzuge AnsiStrings, weil man sich so nicht um die Reservierung und Freigabe von Speicher kümmern braucht.

D2009 oder D2010 verwenden Unicode Strings, da muss man sicher was umcodieren, oder?. Könnte man hier nicht mit Pointerarithmetik am Heap arbeiten, um die Datenfragmente effektiv aufzubereiten?
  • sx2008 hat geschrieben
Man sollte eine maximale Message - Grösse definieren, um sich vor Denial-of-Service Angriffen zu schützen.

"Denial-of-Service Angriffen" werden von vielen Rechnern, auf einen Opfer-Server durchgeführt, auch werden Schwächen der IPV4 Implementierung aktiv ausgenutzt, W2k RAW-Sockets aber auch Ring0 Treiber in der OSI 1-2 Schicht.
Hier verstehe ich nicht wie man sich vor solchen Angriffen schützem kann, kannst du das bitte genauer erklären,
Wäre sehr interessant, da dahingehend einige Forschungsarbeiten bei uns laufen.

  • sx2008 hat geschrieben
Wird die max. Grösse überschritten, wird die Verbindung getrennt.

Dies sollte man mit einem dementspechenden Protokoll, zB. ID + Len + ID + Auswertung doch hinbekommen?
Hast du da einen neuen Ansatz, bitte erklär das mal!

Würde mich auf rege Konversation freuen.

Danke für Deine Bemühungen


lg. Astat
Lanthan Astat
06810110811210410503210511511603209711003210010110 9032084097103
03211611111604403209711003210010110903210010510103 2108101116122
11610103209010110510810103206711110010103210511003 2068101108112
10410503210310111509910411410510109810111003211910 5114100046
  Mit Zitat antworten Zitat