Gestern, 01:43
hey stephan,
irgendwie werde ich aus deinem vorigen post nicht recht schlau was/wie du es meinst...
was mir immer aufstößt, ist, daß mehrere subjektive meinungen immer eine gesicherte objektive wahrheit ergeben sollen (das echo chamber prinzip)..
ich bin gelernter physiker, ok, und für mich gilt unumstößlich: die lösung mathematischer/physikalischer gleichungen wird nicht durch abstimmung oder glauben entschieden. ich habe mir die gesamte ethernet... website reingezogen und nirgends etwas bewiesenes gefunden, bestenfalls versatzstücke aus subjektiven behauptungen und aus dem zusammnehang gerissener kopien von inet/wiki fach artikeln. die angegebene messungen wurden weder physikalisch korrekt dokumentiert, beschrieben und schon gar nicht interpretiert (und ich bin zu blöd "teil 2" zu finden). die messungen können ja sogar korrekt sein. aber was sagen sie aus ? tut mir leid, ich sehe das so.
nicht, weil ich ich noch nie außerhalb vom "audio" bereich diese netzwerkfilter gesehen habe. sondern einfach, weil es das TCP/IP nicht hergibt. auf keinem layer des OSI-modells. und ja - da sage ich nicht "meiner meinung nach".
kurz (ginge aber auch länger wenn gewünscht): es gibt zwei prüf/korrektur mechanismen welche die korrektheit bzw. identität der bit folgen von der sender einheit bis zum empfänger garantieren. auch wenn nur ein einzelnes bit durch externe störungen gekippt ist, wird da gesamte paket (mit ~1500byte nutzlast) erneut angefordert bis es korrekt übertragen wurde (checksummen prüfungen). d.h. das TCP/IP protokoll garantiert die korrekte übertragung der bit folge. man muß sich auch keine sorgen machen um unterschiedliche geschwindigkeiten zwischen den netzwerk segmenten oder unterschiedlichem physical layer, also egal ob kupfer, funk oder glas - es kommt korrekt an, egal wie gestört wurde, ob andere felder einstreuen, CM probleme da sind, sonstwas. stimmt ein packet nicht mit der übertragenen checksumme überein (oder andersrum, das ist egal) wird es erneut angefordert. sind störungen massiv (schlechte verbindung ect), gibts time out fehler auf die die anwendung beim empfänger entsprechend mit einer fehlermeldung reagiert bzw einfach nur abbricht. anders würde das inet nicht funktionieren !!! es heisst nicht umsonst Transmission Control Protokol. wir könnten hier nicht kommunizieren, email, whatsapp, asocial media, video würde nciht funktionieren. würde nur ein einziges gekipptes bit existieren könnte man z.b. eine gezippte datei nicht öffnen, kryptisierte dateien nciht entkryptisieren, datenbank abfragen im LAN/WAN nicht valide durchführen...
d.h. was rein geht, geht auch so wieder raus. d.h. auch wenn das rauschen/verzerrungen schon mit digitalisiert werden, werden sie auch so mit gesendet. der verarbeitungsprozess macht keinen unterschied zwische gutem und schlechten signal, er digitaliseirt einfach nur was er übertragen soll. beim empfänger kommt das 1:1 so an und muß natürlich de-digitalisiert werden. und jetzt bin ich wieder bei dir: ab hier können einflüsse wieder reinkommen und bei der extrahierung von header inhalten der pakete, zusammensetzen zum übertragenen objekt, also zu dem was übertragen werden sollte. das sind aber immer noch keine analogen signale, es sind codierte bzw diskretisierte versionen eines analogen signals wie wav, mp3, flac dateien oder pwm, dsd, ect streams und was es sonst noch alles gibt.
aber die sind empfänger lokal (PC oder streamer, ect) und haben nichts mit der TCP/IP übertragung zu tun.
so sehe ich das. und wenn irgendwas falsch ist, bitte ich um aufklärung/korrektur.
irgendwie werde ich aus deinem vorigen post nicht recht schlau was/wie du es meinst...
was mir immer aufstößt, ist, daß mehrere subjektive meinungen immer eine gesicherte objektive wahrheit ergeben sollen (das echo chamber prinzip)..
ich bin gelernter physiker, ok, und für mich gilt unumstößlich: die lösung mathematischer/physikalischer gleichungen wird nicht durch abstimmung oder glauben entschieden. ich habe mir die gesamte ethernet... website reingezogen und nirgends etwas bewiesenes gefunden, bestenfalls versatzstücke aus subjektiven behauptungen und aus dem zusammnehang gerissener kopien von inet/wiki fach artikeln. die angegebene messungen wurden weder physikalisch korrekt dokumentiert, beschrieben und schon gar nicht interpretiert (und ich bin zu blöd "teil 2" zu finden). die messungen können ja sogar korrekt sein. aber was sagen sie aus ? tut mir leid, ich sehe das so.
nicht, weil ich ich noch nie außerhalb vom "audio" bereich diese netzwerkfilter gesehen habe. sondern einfach, weil es das TCP/IP nicht hergibt. auf keinem layer des OSI-modells. und ja - da sage ich nicht "meiner meinung nach".
kurz (ginge aber auch länger wenn gewünscht): es gibt zwei prüf/korrektur mechanismen welche die korrektheit bzw. identität der bit folgen von der sender einheit bis zum empfänger garantieren. auch wenn nur ein einzelnes bit durch externe störungen gekippt ist, wird da gesamte paket (mit ~1500byte nutzlast) erneut angefordert bis es korrekt übertragen wurde (checksummen prüfungen). d.h. das TCP/IP protokoll garantiert die korrekte übertragung der bit folge. man muß sich auch keine sorgen machen um unterschiedliche geschwindigkeiten zwischen den netzwerk segmenten oder unterschiedlichem physical layer, also egal ob kupfer, funk oder glas - es kommt korrekt an, egal wie gestört wurde, ob andere felder einstreuen, CM probleme da sind, sonstwas. stimmt ein packet nicht mit der übertragenen checksumme überein (oder andersrum, das ist egal) wird es erneut angefordert. sind störungen massiv (schlechte verbindung ect), gibts time out fehler auf die die anwendung beim empfänger entsprechend mit einer fehlermeldung reagiert bzw einfach nur abbricht. anders würde das inet nicht funktionieren !!! es heisst nicht umsonst Transmission Control Protokol. wir könnten hier nicht kommunizieren, email, whatsapp, asocial media, video würde nciht funktionieren. würde nur ein einziges gekipptes bit existieren könnte man z.b. eine gezippte datei nicht öffnen, kryptisierte dateien nciht entkryptisieren, datenbank abfragen im LAN/WAN nicht valide durchführen...
d.h. was rein geht, geht auch so wieder raus. d.h. auch wenn das rauschen/verzerrungen schon mit digitalisiert werden, werden sie auch so mit gesendet. der verarbeitungsprozess macht keinen unterschied zwische gutem und schlechten signal, er digitaliseirt einfach nur was er übertragen soll. beim empfänger kommt das 1:1 so an und muß natürlich de-digitalisiert werden. und jetzt bin ich wieder bei dir: ab hier können einflüsse wieder reinkommen und bei der extrahierung von header inhalten der pakete, zusammensetzen zum übertragenen objekt, also zu dem was übertragen werden sollte. das sind aber immer noch keine analogen signale, es sind codierte bzw diskretisierte versionen eines analogen signals wie wav, mp3, flac dateien oder pwm, dsd, ect streams und was es sonst noch alles gibt.
aber die sind empfänger lokal (PC oder streamer, ect) und haben nichts mit der TCP/IP übertragung zu tun.
so sehe ich das. und wenn irgendwas falsch ist, bitte ich um aufklärung/korrektur.
-----------------------
vg tg
vg tg
