Sockets und Paketorientierte datenübertragung
-
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