Hätte gerne paar harte Daten bezüglich Datentransfer in Netzwerken.
-
SideWinder schrieb:
UDP hat zwar eine Checksum, aber garantiert unbeschädigt sind die Pakete nicht, oder?
MfG SideWinder
Also eine starke Garantie ist es nicht ;o
-
IP verwendet überhaupt nur ne 16 Bit "+" Checksumme, sowohl bei TCP als auch bei UDP (bei UDP optional).
D.h. wenn es um die Wurst geht sollte man immer noch zusätzliche eigene Prüfsummen verwenden.
-
hustbaer schrieb:
IP verwendet überhaupt nur ne 16 Bit "+" Checksumme, sowohl bei TCP als auch bei UDP (bei UDP optional).
D.h. wenn es um die Wurst geht sollte man immer noch zusätzliche eigene Prüfsummen verwenden.
Sollte die Checksum von IP nicht für TCP/UDP egal sein? Inwiefern spielt die eine Rolle? Du meinst falls das Paket an eine falsche Adresse gesendet wurde?
MfG SideWinder
-
TCP ist eine Schicht höher, soll keine Verfikation von den Daten auf IP-Ebene stattfinden? Im IP Header können Bit auch umkippen.
Aber ja, die Checksume dort sind für Header + Options.
-
Ich hab das falsch formuliert.
Ich meinte die beiden IP Protokolle TCP und UDP verwenden beide nur 16 Bit Prüfsummen.Die IP Header-Prüfsumme meinte ich nicht, die ist was die Daten angeht wirklich egal.
Auf jeden Fall: sämtliche Prüfsummen der Protokollschichten IP, TCP und UDP sind extrem schwach.
-
Bitfehler sind auch eher Sache der Sicherungsschicht. TCP/UPD kümmern sich eher Paketweise um alles. Die Prüfsumme in der Transportschicht ist glaub ich eher nur noch so eine Art letzte Sicherung.
-
Das ist im OSI Modell sicher so gedacht, ja.
Da man sich die "Sicherungsschicht" allerdings nicht aussuchen kann, ist man IMO gut beraten, wenn man trotzdem eigenen (starke) Prüfsummen in der Anwendungsschicht verwendet.
-
Mit der Argumentation müsste ich alle Aufgaben der unteren Schichten nochmal selbst in der höheren Schicht umsetzen...das ist sicherlich nicht Sinn eines Schichtenmodells. Ich muss mich auf die darunterliegende Schicht verlassen können.
MfG SideWinder
-
Das kommt darauf an was du machst, was die Anwendung für Anforderungen hat.
Wenn ein "wird im Normalfall funktionieren" ausreicht, dann verlass dich auf das was die diversen darunterliegenden Schichten machen.Wenn du dagegen eine bestimmte Schranke für die Fehlerwahrscheinlichkeit garantieren musst (willst), dann brauchst du End-To-End Checks/Prüfsummen, und die kann prinzipbedingt kein Schichtenmodell bieten.
-
Wenn ich solche Garantien in einem Netzwerk abgegeben muss, dann sollte ich kein Netzwerk haben, denn so etwas ist schlichtweg nicht zu garantieren.
Wenn ich eine solche Garantie nur für 99,9999% der Zeit abgeben muss sollte ich ebenfalls noch ziemliche Kontrolle über das Netzwerk haben und somit Herr über alle Schichten sein.
Sobald ich keine Kontrolle mehr über darunterliegende Schichten habe bringt mir eine Checksumme weiter oben auch nur noch wenig weil dann das Risiko eines TCP-Pakets in falscher Reihenfolge da ist wenn die Zahl geswappt wurde, etc. Da können ja dann beim TCP/IP-Stack in 4 Schichten Probleme auftreten die du weiter oben überhaupt nicht mitbekommst. Einzig und allein deine Anwendungsdaten könntest du noch etwas besser überprüfen, mag nett sein, denke aber nicht, dass das insgesamt noch nötig ist.
Hast du irgendwelche Quellen/Papers wo das tatsächlich empfohlen wird?
MfG SideWinder
-
Paketdienst schrieb:
Und auch:
Wenn ein Paket verloren geht werden alle nachfolgenden Pakete bei TCP zurückgehalten, bis das verlorene ankommt, auch evtl durch neuschicken.
das ist nicht so. nachfolgende pakete sind i.d.r. bereits versandt, bevor die bestaetigung zurueck kommt.
Jodocus schrieb:
> ebensowenig bei TCP,
Oh doch, TCP garantiert dir die korrekte Reihenfolge der Packete.
aus meinem quote war ersichtlich, dass ich das ankommen meine. du hast es dahingehend entstellt.
Jodocus schrieb:
> sie werden wieder sortiert, solange es geht.
Passiert eigentlich nicht. Wenn man das tun wollte, könnte man gleich den TCP-Stack des OS nutzen, der ist mit Sicherheit schneller als ein künstlich zusammengefrickeltes Pseudo-TCP.
ich kenne die standardeinstellung eins mediagateway in der preisklasse mehrerer jahresgehaelter: bis 5 ms
das ist im uebrigen komplexer als ein bisschen puffern, was klar wird, wenn man sich verdeutlicht, dass es sich um sprache handelt. soviel zu eigentlich - aber hey, warum hier nicht einach ein bisschen was schreiben?
warum tcp fuer sprache NIE benutzt wird, haben wir bereits geklaert.
-
mezzo mix schrieb:
Paketdienst schrieb:
Und auch:
Wenn ein Paket verloren geht werden alle nachfolgenden Pakete bei TCP zurückgehalten, bis das verlorene ankommt, auch evtl durch neuschicken.
das ist nicht so. nachfolgende pakete sind i.d.r. bereits versandt, bevor die bestaetigung zurueck kommt.
Ich meinte auch bei der anderen Seite. Die Daten kommen in richtiger Reihenfolge bei dem Programm an. Daher blockieren Daten die noch nicht angekommen sind auch erst noch die evtl schon angekommenen nachfolgenden Daten.
-
ahhhso, d'accord
-
SideWinder schrieb:
Wenn ich solche Garantien in einem Netzwerk abgegeben muss, dann sollte ich kein Netzwerk haben, denn so etwas ist schlichtweg nicht zu garantieren.
Wenn ich eine solche Garantie nur für 99,9999% der Zeit abgeben muss sollte ich ebenfalls noch ziemliche Kontrolle über das Netzwerk haben und somit Herr über alle Schichten sein.
Sorry, aber diese Art der Argumentation halte ich für ziemlichen Unsinn.
Dann müssten wir auch der Rettung verbieten mit Blaulicht zu fahren. Denn wenns dringend ist muss es sowieso der Hubschrauber sein, und sonst ist es ja nicht so dringend. Oder wie.Man kann mit End-To-End Checks übers Internet wunderbar Fehlerschranken garantieren. Zumindest so lange man keine Echtzeit Anforderung hat, also nur garantieren muss dass die Daten irgendwann mal richtig ankommen werden. Ich glaube dass das für viele Anwendungen reicht, und besser ist, als die Daten einfach so ungesichert zu schicken.
Sobald ich keine Kontrolle mehr über darunterliegende Schichten habe bringt mir eine Checksumme weiter oben auch nur noch wenig weil dann das Risiko eines TCP-Pakets in falscher Reihenfolge da ist wenn die Zahl geswappt wurde, etc. Da können ja dann beim TCP/IP-Stack in 4 Schichten Probleme auftreten die du weiter oben überhaupt nicht mitbekommst.
Unsinn. Dreher in der Paketreihenfolge etc. kann man relativ leicht mitbekommen, indem man eine Rolling-Checksum verwendet. Die kann man z.B. am Ende jedes Anwendungspakets mitschicken. Dadurch findet man Fehler, egal wie sie in den darunterliegenden Schichten passiert sind.
Hast du irgendwelche Quellen/Papers wo das tatsächlich empfohlen wird?
Ne, Paper kann ich dir dazu keins nennen, ist einfach meine Meinung.