UDP Sicherheit / Übertragungsprotokoll

Übersicht

BlitzBasic

Allgemein

	wunderkind Betreff: UDP Sicherheit / Übertragungsprotokoll	Sa, Okt 30, 2004 21:00 Antworten mit Zitat
Moin, vielleicht könnt ihr mir noch zwei, drei Denkanstöße zur Sicherheit der Datenübertragung bei UDP-basierten Client-/Server-Modellen geben. Momentan verwende ich folgende Mechanismen: Jede Nachricht enthält eine Prüfsumme, die ausgewertet wird. Stimmt die Prüfsumme nicht, dann wird die Nachricht erneut angefordert. Jede Nachricht ist in ihrer Wichtigkeit gekennzeichnet. Ist sie unwichtig und tritt ein Fehler auf (falsche Prüfsumme, falsche Reihenfolge [veraltet]), dann wird sie übergangen und verworfen. Jede Nachricht ist durch eine fortlaufende ID gekennzeichnet. Entsteht eine Lücke, dann wird die fehlende Nachricht nachträglich angefordert, außer... Zusätzlich ist in jeder Nachricht die Wichtigkeit der vorherigen Nachricht hinterlegt. Darüber wird bestimmt, ob fehlende Nachrichten nachträglich angefordert werden. Bei wichtigen Nachrichten wird der Empfang beim Absender bestätigt. Diese Information (oder das Ausbleiben desselben) wird zur Zeit beim Sender nicht genutzt. Zur Synchonisation enthält jede Nachricht eine Timestamp. Gerät ein System in Verzug, dann werden alle unwichtigen Nachrichten verworfen, bis das System wieder aufgeholt hat. Was fällt euch dazu noch ein?

wunderkind

Betreff: UDP Sicherheit / Übertragungsprotokoll

Sa, Okt 30, 2004 21:00
Antworten mit Zitat

Moin,

vielleicht könnt ihr mir noch zwei, drei Denkanstöße zur Sicherheit der Datenübertragung bei UDP-basierten Client-/Server-Modellen geben. Momentan verwende ich folgende Mechanismen:

Jede Nachricht enthält eine Prüfsumme, die ausgewertet wird. Stimmt die Prüfsumme nicht, dann wird die Nachricht erneut angefordert.
Jede Nachricht ist in ihrer Wichtigkeit gekennzeichnet. Ist sie unwichtig und tritt ein Fehler auf (falsche Prüfsumme, falsche Reihenfolge [veraltet]), dann wird sie übergangen und verworfen.
Jede Nachricht ist durch eine fortlaufende ID gekennzeichnet. Entsteht eine Lücke, dann wird die fehlende Nachricht nachträglich angefordert, außer...
Zusätzlich ist in jeder Nachricht die Wichtigkeit der vorherigen Nachricht hinterlegt. Darüber wird bestimmt, ob fehlende Nachrichten nachträglich angefordert werden.
Bei wichtigen Nachrichten wird der Empfang beim Absender bestätigt. Diese Information (oder das Ausbleiben desselben) wird zur Zeit beim Sender nicht genutzt.
Zur Synchonisation enthält jede Nachricht eine Timestamp. Gerät ein System in Verzug, dann werden alle unwichtigen Nachrichten verworfen, bis das System wieder aufgeholt hat.

Was fällt euch dazu noch ein?

	Nox	Sa, Okt 30, 2004 21:10 Antworten mit Zitat
Ich würde die Priorität einer Nachricht nicht mitsenden. Ich weiß nicht, wieviele Clients du gleichzeitig verwalten willst, aber das treibt die Netzlast in die Höhe. Lass doch den Server/Client die Prioritäten übernehmen.

Nox

Sa, Okt 30, 2004 21:10
Antworten mit Zitat

Ich würde die Priorität einer Nachricht nicht mitsenden. Ich weiß nicht, wieviele Clients du gleichzeitig verwalten willst, aber das treibt die Netzlast in die Höhe. Lass doch den Server/Client die Prioritäten übernehmen.

	wunderkind	Sa, Okt 30, 2004 21:17 Antworten mit Zitat
Ist das damit nicht getan?

wunderkind

Sa, Okt 30, 2004 21:17
Antworten mit Zitat

Ist das damit nicht getan?

	Nox	Sa, Okt 30, 2004 21:26 Antworten mit Zitat
So wie ich es verstanden habe, möchtest du mit jeder Nachricht die Priorität mitsenden, oder? Wenn nicht, dann ignoriere meine Äußerung. =) Falls doch, dann schlage ich halt einfach vor, dass der Code die Priorität der Nachricht (jede Nachricht hat ja eine Message-ID, also was sie tut) regelt und ggf. die Nachricht erneut anfordert. Und ich weiß net, inwiefern UDP für eine länger andauernde Verbindung sinnvoll sein soll, denn die Fehlerquellen erhöhen sich deutlich (stattdessen TCP verwenden). Als ich mal was ähnliches entwickelt hatte, benutzte ich 32 Bits für eine CRC32-Prüfsumme und 8 Bits für die Message-Länge. Das war mein Header. =) Allerdings dazugesagt: Das Modell war nicht für viel Transfer ausgelegt.

Nox

Sa, Okt 30, 2004 21:26
Antworten mit Zitat

So wie ich es verstanden habe, möchtest du mit jeder Nachricht die Priorität mitsenden, oder? Wenn nicht, dann ignoriere meine Äußerung. =) Falls doch, dann schlage ich halt einfach vor, dass der Code die Priorität der Nachricht (jede Nachricht hat ja eine Message-ID, also was sie tut) regelt und ggf. die Nachricht erneut anfordert.
Und ich weiß net, inwiefern UDP für eine länger andauernde Verbindung sinnvoll sein soll, denn die Fehlerquellen erhöhen sich deutlich (stattdessen TCP verwenden). Als ich mal was ähnliches entwickelt hatte, benutzte ich 32 Bits für eine CRC32-Prüfsumme und 8 Bits für die Message-Länge. Das war mein Header. =) Allerdings dazugesagt: Das Modell war nicht für viel Transfer ausgelegt.

	wunderkind	Sa, Okt 30, 2004 21:32 Antworten mit Zitat
Hi, die MsgID bestimmt nicht was die Nachricht tut, sondern wird nur für die Reihenfolge benutzt.

wunderkind

Sa, Okt 30, 2004 21:32
Antworten mit Zitat

Hi,

die MsgID bestimmt nicht was die Nachricht tut, sondern wird nur für die Reihenfolge benutzt.

	Nox	So, Okt 31, 2004 3:01 Antworten mit Zitat
Und wie willst du dann später unterscheiden, welche Msg für was zuständig ist? Meistens ist in einer Message ein Op-Byte oder ähnliches enthalten. Gänzlich ohne stell ich mir das schwierig vor.

Nox

So, Okt 31, 2004 3:01
Antworten mit Zitat

Und wie willst du dann später unterscheiden, welche Msg für was zuständig ist? Meistens ist in einer Message ein Op-Byte oder ähnliches enthalten. Gänzlich ohne stell ich mir das schwierig vor. Smile

	Holzchopf Meisterpacker	So, Okt 31, 2004 14:14 Antworten mit Zitat
Also dass mit der Prüfsumme brauchst du glaubich nicht umbedingt, die ist nämlich schon im UDP-Header integriert. Zwar optional, aber da ich es noch nie erlebt habe, dass UDP-Nachrichten verstückelt, wennschon, dann gar nicht ankamen, gehe ich mal davon aus, dass Blitz diese Prüfsumme nutzt und nur dann eine als empfangen angibt, wenn sie ganz ankam. Google einfach mal nach UDP-Header. Ausserdem könnte es ja sein, dass 2 Nachrichten nach einander verloren gehen, wie würdest du das in deinem Fall lösen?
Erledige alles Schritt um Schritt - erledige alles. - Holzchopf CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018) Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm

Holzchopf

Meisterpacker

So, Okt 31, 2004 14:14
Antworten mit Zitat

Also dass mit der Prüfsumme brauchst du glaubich nicht umbedingt, die ist nämlich schon im UDP-Header integriert. Zwar optional, aber da ich es noch nie erlebt habe, dass UDP-Nachrichten verstückelt, wennschon, dann gar nicht ankamen, gehe ich mal davon aus, dass Blitz diese Prüfsumme nutzt und nur dann eine als empfangen angibt, wenn sie ganz ankam.
Google einfach mal nach UDP-Header.
Ausserdem könnte es ja sein, dass 2 Nachrichten nach einander verloren gehen, wie würdest du das in deinem Fall lösen?

Erledige alles Schritt um Schritt - erledige alles. - Holzchopf
CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018)
Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm

	wunderkind	So, Okt 31, 2004 14:20 Antworten mit Zitat
Holzchopf hat Folgendes geschrieben: Ausserdem könnte es ja sein, dass 2 Nachrichten nach einander verloren gehen, wie würdest du das in deinem Fall lösen? Moinsens, in diesem Fall würden rekursiv alle Nachrichten nachgefordert werden, bis in einer Nachricht die vorhergehende als unwichtig gekennzeichnet ist.

wunderkind

So, Okt 31, 2004 14:20
Antworten mit Zitat

Holzchopf hat Folgendes geschrieben:

Ausserdem könnte es ja sein, dass 2 Nachrichten nach einander verloren gehen, wie würdest du das in deinem Fall lösen?

Moinsens,

in diesem Fall würden rekursiv alle Nachrichten nachgefordert werden, bis in einer Nachricht die vorhergehende als unwichtig gekennzeichnet ist.

	Nox	So, Okt 31, 2004 15:42 Antworten mit Zitat
Was UDP manchmal mit Paketen macht, will ich garnicht wissen. ^^ Es kam bei mir beispielweise mal vor, dass einzelne Pakete einfach verloren gingen. Da war bisher eine ordentliche Prüfsumme immer sinnvoll.

Nox

So, Okt 31, 2004 15:42
Antworten mit Zitat

Was UDP manchmal mit Paketen macht, will ich garnicht wissen. ^^ Es kam bei mir beispielweise mal vor, dass einzelne Pakete einfach verloren gingen. Da war bisher eine ordentliche Prüfsumme immer sinnvoll.

	Holzchopf Meisterpacker	So, Okt 31, 2004 16:32 Antworten mit Zitat
Ja, aber die Prüfsumme ist ja eben schon im Header integriert, wenn was mit der Nachricht nicht stimmt, tut BB einfach so, als ob gar keine angekommen wäre (behaupte ich jetzt mal, weil ich es noch nie erlebt habe, dass in BB eine Nachricht zerstückelt angekommen ist). Also bringt eine zusätzliche Prüfsumme kaum was.
Erledige alles Schritt um Schritt - erledige alles. - Holzchopf CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018) Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm

Holzchopf

Meisterpacker

So, Okt 31, 2004 16:32
Antworten mit Zitat

Ja, aber die Prüfsumme ist ja eben schon im Header integriert, wenn was mit der Nachricht nicht stimmt, tut BB einfach so, als ob gar keine angekommen wäre (behaupte ich jetzt mal, weil ich es noch nie erlebt habe, dass in BB eine Nachricht zerstückelt angekommen ist).
Also bringt eine zusätzliche Prüfsumme kaum was.

Erledige alles Schritt um Schritt - erledige alles. - Holzchopf
CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018)
Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm

	eXceptION	Mo, Nov 01, 2004 23:11 Antworten mit Zitat
Erstens: Ich komme aus norwegen... Also achtung, Sprachprobleme! :S -- UDP -- 1. Packets sind immer vollständig (wenn sie überhaubt ankommen). In das UDP Header, liegt tatsächlich eine Prüfsumme. Ist diese falsch, wird die ganze Packet weggeworfen. 2. Packets ankommen nicht unbedingt in die gleiche Reihenfolge wie sie gesendet waren. 3. Packets tauchen ab und zu mal gar nicht auf, oder auch aber doch... Oder sogar zwei mal oder mehr. Beispiel (Ja extrem, aber in teorie, nicht unmöglich): Sender: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Receiver: 1, 2, 3, 2, 2, 7, 5, 5, 1, 9, 9, 8, 9 -- TCP -- 1. Packets sind nicht immer vollständig. (Edit: Auch TCP hat eine Prüfsumme. Wenn sie nicht mit dem Data passt, wird einen neuen Packet nachgefragt. Das passiert bei jedem server wo die Packet vorkommt. Nachfolgende Packets müssen warten) 2. Packets ankommen immer, und auch immer in die richtige Reihenfolge. 3. Packets ankommen immer nur ein mal. ---- UDP hat weniger Overhead (kleiner header, weniger Error-testing bei die verschiedene servers es besucht auf den Weg zu dir), so also ein wenig schneller! UDP eignet sich für multiplayer spiele, da ein Kerl mit'ne Modem Connection das Spielspass für die andere nicht zerstören muss. TCP eignet sich für das übertragung von dateien, da es immer garantiert ist das es richtig wird. ---- Hoffe ihr könnt das verstehen! :S
Norweger... Spreche aber verdammt gut 8086

eXceptION

Mo, Nov 01, 2004 23:11
Antworten mit Zitat

Erstens: Ich komme aus norwegen... Also achtung, Sprachprobleme! :S

-- UDP --

1. Packets sind immer vollständig (wenn sie überhaubt ankommen). In das UDP Header, liegt tatsächlich eine Prüfsumme. Ist diese falsch, wird die ganze Packet weggeworfen.

2. Packets ankommen nicht unbedingt in die gleiche Reihenfolge wie sie gesendet waren.

3. Packets tauchen ab und zu mal gar nicht auf, oder auch aber doch... Oder sogar zwei mal oder mehr.

Beispiel (Ja extrem, aber in teorie, nicht unmöglich):
Sender: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
Receiver: 1, 2, 3, 2, 2, 7, 5, 5, 1, 9, 9, 8, 9

-- TCP --

1. Packets sind nicht immer vollständig. (Edit: Auch TCP hat eine Prüfsumme. Wenn sie nicht mit dem Data passt, wird einen neuen Packet nachgefragt. Das passiert bei jedem server wo die Packet vorkommt. Nachfolgende Packets müssen warten)

2. Packets ankommen immer, und auch immer in die richtige Reihenfolge.

3. Packets ankommen immer nur ein mal.

----

UDP hat weniger Overhead (kleiner header, weniger Error-testing bei die verschiedene servers es besucht auf den Weg zu dir), so also ein wenig schneller!

UDP eignet sich für multiplayer spiele, da ein Kerl mit'ne Modem Connection das Spielspass für die andere nicht zerstören muss.

TCP eignet sich für das übertragung von dateien, da es immer garantiert ist das es richtig wird.

----

Hoffe ihr könnt das verstehen! :S

Norweger...

Spreche aber verdammt gut 8086

	IonPainter	Di, Nov 02, 2004 1:59 Antworten mit Zitat
@Thread was mir dazu einfällt ist, das du um 12 bytes header zu sparen (UDP hat 8 bytes, TCP 20) einen gigantischen Overhead erzeugst. Um das sichere ankommen von nachrichten zu gewährleisten musst du jedesmal eine nachricht an den server senden welche bestätigt das die nachricht angekommen ist, hier verbrätst du weitere 8 bytes + prüfsumme (4 oder mehr bytes). du hast aber noch keine sicherheit das messages nicht 2 mal ankommen, das sie in der rictigen reihenfolge ankommen, u.s.w. deshalb mein rat: nutze tcp

IonPainter

Di, Nov 02, 2004 1:59
Antworten mit Zitat

@Thread

was mir dazu einfällt ist, das du um 12 bytes header zu sparen (UDP hat 8 bytes, TCP 20) einen gigantischen Overhead erzeugst. Um das sichere ankommen von nachrichten zu gewährleisten musst du jedesmal eine nachricht an den server senden welche bestätigt das die nachricht angekommen ist, hier verbrätst du weitere 8 bytes + prüfsumme (4 oder mehr bytes). du hast aber noch keine sicherheit das messages nicht 2 mal ankommen, das sie in der rictigen reihenfolge ankommen, u.s.w.

deshalb mein rat: nutze tcp Wink

	Holzchopf Meisterpacker	Di, Nov 02, 2004 18:58 Antworten mit Zitat
@Ion: Die Nachrichten vom Client zum Server müssen ja sonst nicht leer sein, da können auch noch Daten drinn stehen. Und da bei Shooter generell nicht so viele Daten anfallen, lohnt sich das sogar noch, längstens. Ausserdem bremst TCP BB ein wenig aus, leider... Also ich könnte mir ein Shooter auf TCP-Basis nicht gut vorstellen
Erledige alles Schritt um Schritt - erledige alles. - Holzchopf CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018) Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm

Holzchopf

Meisterpacker

Di, Nov 02, 2004 18:58
Antworten mit Zitat

@Ion: Die Nachrichten vom Client zum Server müssen ja sonst nicht leer sein, da können auch noch Daten drinn stehen. Und da bei Shooter generell nicht so viele Daten anfallen, lohnt sich das sogar noch, längstens.
Ausserdem bremst TCP BB ein wenig aus, leider... Also ich könnte mir ein Shooter auf TCP-Basis nicht gut vorstellen Confused

Erledige alles Schritt um Schritt - erledige alles. - Holzchopf
CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018)
Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm

	IonPainter	Di, Nov 02, 2004 22:11 Antworten mit Zitat
quake2 basiert(e) auf tcp...

IonPainter

Di, Nov 02, 2004 22:11
Antworten mit Zitat

quake2 basiert(e) auf tcp... Rolling Eyes

	wunderkind	Di, Nov 02, 2004 22:27 Antworten mit Zitat
IonPainter hat Folgendes geschrieben: quake2 basiert(e) auf tcp... Das stimmt meines Wissens nicht. Vernünftig belegen kann ich's momentan nicht. Ich habe nur folgende List zur Hand, aus der ganz klar hervorgeht, welchen Port Quake XYZ auf UDP belegt: http://www.mikesel.karoo.net/hosting.html Der Geschwindigkeitsnachteil wäre für Spiele dieser Art auch untragbar.

wunderkind

Di, Nov 02, 2004 22:27
Antworten mit Zitat

IonPainter hat Folgendes geschrieben:

quake2 basiert(e) auf tcp... Rolling Eyes

Das stimmt meines Wissens nicht. Vernünftig belegen kann ich's momentan nicht. Ich habe nur folgende List zur Hand, aus der ganz klar hervorgeht, welchen Port Quake XYZ auf UDP belegt: http://www.mikesel.karoo.net/hosting.html

Der Geschwindigkeitsnachteil wäre für Spiele dieser Art auch untragbar.

Übersicht

BlitzBasic

Allgemein

Nach Oben

BlitzBasic Portal

UDP Sicherheit / Übertragungsprotokoll

Betreff: UDP Sicherheit / Übertragungsprotokoll