Sockets und Paketorientierte datenübertragung
-
ja, ich habe es schon oft erlebt, das spiele (obwohl meins sicherlich nie so großen andrang bekommt wie die die ich grad meine) von irgendwelchen freaks zerhackt werden, indem sie den datenverkehr mitschneiden, die einzelnen variablen auslesen und dann an einer kritischen stelle ein manipuliertes paket einschleusen um den server zu "verwirren" oder andere dinge auszulösen
ein beispiel ist ein MMORPG was im moment in der beta phase ist, clientseitig konnte man da zwischen einigen grundlegenden charakter wählen, ein weiterer character war schon serverseitig implementiert aber clientseitig nicht auswählbar, da hat einfach jemand ein manipuliertes paket abgeschickt bei der auswahl wo statt der 5 für den momentan letzten chrarakter eine 6 für den noch versteckten charakter übertragen wurde. und wenn derjenige komplizierte daten manipuliertr kann ihm doch leicht ein fehler unterlaufen, ich möchte aber nicht das die übertragung gleich zusammenbricht deswegen.
das mit dem header und der länge hab ich oben ja schon grob erklärt und ich dackel im falle eines unvollständigen paketes immer mit msg_peek über den socket und les auch nur so viel wie ich auch brauche, danach such ich wieder den anfang eines neuen paketes usw. oder ich erwarte ein endzeichen, wenn ich selbiges nicht finde geh ich zurück bis zu dem ersten gefundenen header setz dahinter an und such nach einem neuen paket.
@pumuckl meine übertragung sieht ein startzeichen von 4 byte gefolgt von einem byte oder 2 für die datenlänge vor. trennzeichen sind wurst die können auch zufällig im datenstrom auftauchen und würden zufallsfehler generieren, feste länge wäre ineffizient und auch da kann es passieren das jemand 1 byte zuviel sendet (weil er ja nicht unbedingt weis wie groß 1 paket ist) und dann alle folgepakete verkerht sind.
das jemand einen fake client baut kann ich nicht oder nur schwer verhindern.
das mit der prüfsumme könnt ich für das endzeichen verwenden, klasse idee, find ich keins spul ich wie beschrieben zurück und such das nächste startzeichen/paket
by the way: was wäre ein brauchbares verfahren für ne prüfsumme ?
-
wenn du einfach nur nich willst dass dein spiel zusammenbricht musst du einfach nur die interpretation der daten sehr defensiv programmieren
d.h. es gibt n nachrichtentypen
jeder nachrichtentyp hat eine bestimmte länge m
und jeder wert in dieser nachricht hat einen gültigen wertebereich von x bis yund wenn irgendwelche daten ankommen die außerhalb der bereiche liegen
machst du die verbindung zu, zeigst ne fehlermeldung und springst wieder ins hauptmenü, damit der user ein neues spiel anfangen kann@prüfsumme: http://de.wikipedia.org/wiki/Cyclic_Redundancy_Check
-
naja zuuumachen wollt ich nicht gleich, kann ja auch sein das ich irgendwo in der übertragung oder bei der paketgenerierung nen fehler mache und deshalb soll ja eben die verbinndung sich regenerieren ... aber das mit dem CRC iss echt klasse danke _
damit hätt ich ne doppelte absicherung, einmal gegen falsche datenlänge und gegen "einfache" manipulation.
gegen einen fake client könnte ich ja noch im falle einer defekten übertragung ein kontrollsignal schicken, wird dieses kontrollsignal nicht vernünftig(also wie von original client erwartet) beantwortet brech ich die verbindung ab.
-
davon auszugehn dass du bei der erstellung oder übertragung nen fehler machst halt ich aber für falsch.
das wär als würdest du davon ausgehn, dass du auf nen nullpointer zugreifst und dann crasht die software ja auch
-
ja mei, niemand iss perfekt, ich würde versuchen jede eventualität vorherzusehen, aber stell dir einfach mal vor, das du ... was weis ich ... irgend wo nen fehler bei einem befehl geamcht hast, ihn 1 byte länger anlegst als er eigentlich sein soll ... warum auch immer .... du testest den befehl in einer anordnung die funktioniert und irgendein spieler passaiert nun mal worst case er erwischt den befehl und bei ihm stimmen von nun an keine befehle merh, da würde man sich schon wünschen das die verbindung das ausgleicht.
nen nullpointer kann dir auch überall mal vor die flinte laufen unter testbedingungen passiert nix nachm release schaffts aber n spezialist irgendwie doch n fehler zu prvozieren der SO nicht erwartet war ne Exception halt ... und genau wie try catch möcht ich halt versuchen nen übertragungsfehler vom programm her zu koriigieren
-
da würde man sich schon wünschen das die verbindung das ausgleicht.
lol auf gar keinen fall
-
netter beitrag .... würdest du mir bitte erläutern warum nicht ?
-
es geht schon... also auch wenns mir nich gefällt is dein ansatz schon möglich
wenn du fehlerhafte daten findest die nich in dein schema passen wirf sie weg und such nach dem nächsten header
-
@ sovok
naja ich verbuch das mal unter geschmackssache und über geschmack lässt sich bekanntlich streiten _
danke jedenfalls, du hast mir auf jeden fall geholfen es noch ein wenig sicherer zu machen
-
sry für doppelpost aber mir ist grad der grund eingefallen wieso ich das mit der regenerierenden verbindung einer defensiven(also reset bei fehler) bevorzuge ... es gibt einige befehle die sich nur unter gewissen umständen, die ein wenig "aufwand" erzeugen, benutzen lassen und um den fehler reprorduzierbar zu machen und eventuell während des auftretens noch debuggen zu können, wollte ich halt das der befehl einfach verworfen wird statt die verbindung zu terminieren.
-
dafür würde aber auch eine gute protokollierung reichen
wenn die daten verworfen werden hilft dir das auch nicht so sehr beim debuggen