MAC ADresse
-
abc.w schrieb:
Ein Byte (8 Bit) wäre doch sicherlich passender gewesen... auch angenehmer zum Programmieren.
Wie so? Wenn du es gewohnt wärst mit 6 Bit pro Byte zu rechnen, dann würdest du dich an den 8 stören. Aber wenn du schon so fragst, warum denn keine 10 Bit pro Byte?
-
;fricky schrieb:
mezzo mix schrieb:
volkard schrieb:
;fricky schrieb:
man könnte ja netzwerkkarten bauen, die direkt IP können.
Dann müßte ich aber alle Netzwerkkarten austauschen und die Bridges auch. Würde ich erst machen, wenn jemand IPv6 benutzt.
also fuer jeden switch einen router kaufen. nur noch p2p links. das heisst statt statt n+3 ip addressen pro netz zu verballern (n ^= computer) jetzt insgesamt 4*n. hmmm
geroutete ports sind leider auch viel teurer, als geswitchte.ach nö, die netzwerkkarten könnten halt direkt IP, von mir aus können die adressen konfigurierbar sein, das geht schon. zu kompatibilitätszwecken macht man dann eben IP-over-IP *fg*
klaer' mich doch bitte auf, auf was das 'ach noe' bezogen ist, bevor ich auf irgendwas antworte, was du gar nicht meintst.
;fricky schrieb:
mezzo mix schrieb:
und frames durch's internet schicken ist nicht so trivial wie man vielleicht denken mag. insgesamt will man den layer auch eher los werden. und gerade um frames ueber das internet transportieren zu koennen, wird dein protokoll stack immer hoeher.
ach nö, eigentlich würde es weniger. irgendeine art von bitübertragungsprotokoll verwenden diese internet-backbones doch auch (FDDI oder sowas).
deine vorstellung des 'internets' ist einfach falsch. es ist nicht so flach, wie es nach aussen hin vielleicht aus zu sehen scheint, sonst wuerde es auch nicht funktionieren. aber da weiss ich jetzt auch nicht wo ich ansetzen soll. ganz grob: ip wird nur genutzt damit die router sich unterhalten koennen. die wegwahl von paketen wird aufgrund von labels gemacht, die jedes paket beim betreten eines backbones verpasst bekommt. diese netze sind fuer ip eh transparent, du siehst nur die netzuebergeaenge. man hat also ip header vom client, mpls header vom backbone (siehe MPLS/BGP), layer 2 header vom backbone und musst den layer 2 header vom client auch noch mitnehmen. es werden also netze ueber netze gelegt, was fuer netzbetreiber auch sehr wichtig ist. nun bist du aber schon am routen, willst also in der regel layer 2 vom client eh nicht mehr haben, ausser fuer layer 2 vpns.
ausserdem weiss ich nicht, was du hier mit layer 1 willst. was man derzeit will, ist ip ohne umwege ueber wellenlaengen zu transportieren (IP over WDM) um diese dann zu multiplexen. damit sind gigantische datenraten moeglich.;fricky schrieb:
dann könnte man z.b. 'nen glasfaseranschluss zu jedem haus legen, ohne internet-provider und sonstwas dazwischen und könnte direkt seinen PC da anstöpseln.
wie jetzt ohne provider? irgendjemand will dafuer geld sehen. in der regel ein so genannter provider. ausserdem gibt's das schon, z.b. mit GPON.
um zusammen zu fassen: du musst unterscheiden zwischen access und backbone. hier sind die anforderungen einfach verschieden. ethernet z.b. skaliert nicht gut. routing ist teuer. also z.b. switching fuer staedte, und ip/mpls fuer den backbone. das sind jetzt natuerlich keine richtlinien...
-
zusammenfassung von der zusammenfassung
:
irgendeine adresse mußt man eh end-to-end transportieren. heute ist das die ip adresse (ggf. mit übersetzung durch nat etc.). zusätzlich hast du halt zumeist ethernet zu hause. das ist, wie schon erwähnt wurde, bewährt und günstig. bis das im heimbereich verschwindet, kann man noch lange warten. was in den backbones passiert, kann dem benutzer eh egal sein.und was völlig neues, auch für den heimbereich, einzuführen wäre schon cool
aber leider unrealistisch...
-
mezzo mix schrieb:
und was völlig neues, auch für den heimbereich, einzuführen wäre schon cool aber leider unrealistisch...
leider unrealistisch, aber ich fänds toll, nicht nur für den heimbereich. es müsste ein völlig neues system her, das mit möglichst wenig zwischen-layern und protokoll-umsetzern auskommt, all diesen ganzen schnickschnack wie ARP, PPPoE, usw. braucht man doch nur, um verschiedene netzwerktechnologien zusammenzubringen. man müsste ein einheitliches protokoll und eine technik erfinden, die für alle möglichen netze und geräte taugt und dabei schlank und erweiterbar ist. dann könnte da alles drüber laufen, internet, rundfunk, telefon, computer, speichermedien, waschmaschine, toaster, usw.usw., einfach alles. jedes haus, jede wohnung, jeder raum bekommt einen anschluss verpasst, jedes gerät hat einen (drahtlos geht natürlich auch) und dann kann jeder anschliessen was er will und mit jedem kommunizieren. machbar wär's bestimmt und vielleicht kommt sowas ja mal. stattdessen haben wir z.zt. tausend verschiedene technologien, die mit allen möglichen tricks zusammengebracht werden. ziemlich suboptimal, würde ich mal sagen.
-
;fricky schrieb:
es müsste ein völlig neues system her, das mit möglichst wenig zwischen-layern und protokoll-umsetzern auskommt, all diesen ganzen schnickschnack wie ARP, PPPoE, usw. braucht man doch nur, um verschiedene netzwerktechnologien zusammenzubringen. man müsste ein einheitliches protokoll und eine technik erfinden, die für alle möglichen netze und geräte taugt und dabei schlank und erweiterbar ist.
Mit dem Erfolg, daß man ein Frickel-Protokoll kriegt, das für verschiedene Hardware-Anforderungen jeweils umgebaut wird, für allein schon für Kabeltelephon andere Prüfsummen als für Funk und und und. (Kompression und Verschlüsselung willste sicher auch dort einbauen, oder?) Erreicht hast Du damit genau gar nichts, außer daß Du Plugis für Subprotokolle und Protokollerweiterungen brauchst, statt einfach zu layern. Helau.
-
volkard schrieb:
Mit dem Erfolg, daß man ein Frickel-Protokoll kriegt, das für verschiedene Hardware-Anforderungen jeweils umgebaut wird, für allein schon für Kabeltelephon andere Prüfsummen als für Funk und und und. (Kompression und Verschlüsselung willste sicher auch dort einbauen, oder?) Erreicht hast Du damit genau gar nichts, außer daß Du Plugis für Subprotokolle und Protokollerweiterungen brauchst, statt einfach zu layern. Helau.
^^ nee, nix frickel-protokoll. das ganze muss wohlüberlegt und gut gemacht sein. da müsste schon so'n genialer typ wie einstein oder gödel her, der sich die absolute killer-netzwerktechnik ausdenkt (z.b. aufgrund neuer physikalischer erkenntnisse usw.), wahrscheinlich kommt dabei irgendwas raus, das nach ganz anderen prinzipien funktioniert, als wir's uns heute überhaupt vorstellen können. vielleicht stellt sich digitaltechnik irgendwann als sackgasse heraus und man zieht sowas mit analogtechnik und quantenmechanik hoch. aus unserer heutigen sicht ist das alles utopie, aber es wurden ja schon früher dinge erfunden, die die welt verändert haben.
-
War dein Hirn zulange in der Mikrowelle?
-
~(Zufällig lese ich gerade Gödel, Escher Bach)~
Nein. Es braucht einen genialen Geist wie Gödel, um Leuten wie Dir zu beweisen, daß es kein Universalprotokoll geben KANN, das alle Belange abdeckt.
-
> quantenmechanik
Ja, aber es wird doch schon ewig an Quantencomputern geforscht?!. Was sich da groß unterscheidet? Naja, Computer sind dann eben nicht mehr deterministisch. Aber mehr könnense deshalb trotzdem nicht, höchstens schneller/besser. Mach dir also keine Hoffnung, dass irgendeine neue Erfindung das bricht, was die theoret. Informatik seit fast 100 Jahren weiß.
Was willste denn mit 'nem W-LAN-Toaster? Oma anrufen? Oder 'nen Film gucken?
Außerdem: wie willste denn sicherstellen, dass die NIC-Hersteller die MAC-Adressen so sinnvoll und logisch wie IP-Adressen verteilen (in WANs, MANs und LANs)? Und dann sollten se doch besser gleich 8-Byte oder so lang sein, damit wir hoffentlich nie wieder das "IPv4-Problem" haben? Und wenn wir das mal 'ne Kiste umstellen? Müssen wir dann gleich das EPROM auf der NIC flashen? Sollte nicht irgendein lieber irgendein DHCP diese Super-Adressen verteilen? Wie kann dich der DHCP ohne sinnvolle Adresse überhaupt finden, um dir die neue zu geben? Per Post? Das klappt doch alles nicht.
-
Ad aCTa schrieb:
Und dann sollten se doch besser gleich 8-Byte oder so lang sein, damit wir hoffentlich nie wieder das "IPv4-Problem" haben?
Welche Verschwendung! Das alte Toaster-Zu-Toaster-Protokoll kam mit 5½-Bit-Adressen aus. Und wer braucht schon mehr als 45 Toaster?
-
Ich will auf jeden Fall mal sehen, wie mein Toaster und mein Kühlschrank kommunizieren.
Wenn das kleine netzwerkfähige Sprachlabor, das ich administriere, genauso gut funktioniert wie meine Küche, bin ich wahrscheinlich in ein paar Tagen verhungert.
Andererseits, es würde bestimmt Spaß machen, den Nachbarn mit Broadcast-Nachrichten zu terrorisieren. DoS-Angriffe, das macht Spaß!
Oder ich stelle meine Adresse auf die selbe des Kühlschranks meines Nachbarn und schicke die Nachrichten an diesen Internet-Kühlschrank, die ich dann empfange, gar nicht erst weiter.Noch besser:
Kühlschränke mit blockierenden Sockets, dann geht die Tür gar nicht erst auf.
-
Ad aCTa schrieb:
Wenn das kleine netzwerkfähige Sprachlabor, das ich administriere, genauso gut funktioniert wie meine Küche, bin ich wahrscheinlich in ein paar Tagen verhungert.
Wenn Rechner so einfach und zuverlässig wären deine Küche, würden wir Informatiker alle verhungern.
-
volkard schrieb:
Ad aCTa schrieb:
Wenn das kleine netzwerkfähige Sprachlabor, das ich administriere, genauso gut funktioniert wie meine Küche, bin ich wahrscheinlich in ein paar Tagen verhungert.
Wenn Rechner so einfach und zuverlässig wären wie Küchengeräte, würden wir Informatiker alle verhungern.
Deswegen wollen wir in allen ein Rechner einbauen, damit wir stink reich werden!
-
Hach Mist, wenn ich doch Informatiker wäre...
Kann ja noch werden.
-
Erst wenn der letze Kühlschrank ausgefallen ist, werdet ihr feststellen, daß man Geld nicht essen kann.
-
volkard schrieb:
Erst wenn der letze Kühlschrank ausgefallen ist, werdet ihr feststellen, daß man Geld nicht essen kann.
Sind Geldscheine giftig?
-
_Luckie schrieb:
abc.w schrieb:
Ein Byte (8 Bit) wäre doch sicherlich passender gewesen... auch angenehmer zum Programmieren.
Wie so? Wenn du es gewohnt wärst mit 6 Bit pro Byte zu rechnen, dann würdest du dich an den 8 stören...
Genau, ich würde mich über die 8 Bits ärgern, weil man dafür ruhig zwei 6-Bits Bytes vergeben könnte.
Es sieht doch so aus: Es wird eine Spezifikation 1.0 verabschiedet, die irgendwelche krummen Zahlen festlegt. Dann wird festgestellt, das ist nicht gut, also muss eine "Spezifikation 2.0 Extended" verabschiedet werden, die die krummen Zahlen mit weiteren krummen Zahlen erweitert... Was hat man sich damit erspart? Die Software, Treiber usw., werden unnötig kompiliziert, wegen irgendwelcher Bitmasken, Bitschiebereien usw...
-
volkard schrieb:
~(Zufällig lese ich gerade Gödel, Escher Bach)~
cool, *daumen hoch*, dieses buch ist pflichtlektüre für jeden computerfreak. ich muss mich jetzt aber als absoluter loser outen: ich will's seit ca. 10 jahren lesen, aber irgendwie bin ich noch nie dazu gekommen.
volkard schrieb:
Nein. Es braucht einen genialen Geist wie Gödel, um Leuten wie Dir zu beweisen, daß es kein Universalprotokoll geben KANN, das alle Belange abdeckt.
ach menno, für science fiction habt ihr einfach nichts übrig hier, das ist mir schon öfter aufgefallen. *heul*
volkard schrieb:
Erst wenn der letze Kühlschrank ausgefallen ist, werdet ihr feststellen, daß man Geld nicht essen kann.
kühlschränke sind aber auch nix für unseren verdauungstrakt *fg*
abc.w schrieb:
Es sieht doch so aus: Es wird eine Spezifikation 1.0 verabschiedet, die irgendwelche krummen Zahlen festlegt. Dann wird festgestellt, das ist nicht gut, also muss eine "Spezifikation 2.0 Extended" verabschiedet werden, die die krummen Zahlen mit weiteren krummen Zahlen erweitert... Was hat man sich damit erspart? Die Software, Treiber usw., werden unnötig kompiliziert, wegen irgendwelcher Bitmasken, Bitschiebereien usw...
falls du auf den CAN-bus anspielst: was sind 'krumme zahlen'? meinste die 11 bzw. 29-bit CAN-IDs? naja, es sind primzahlen *fg*, aber das stört doch nicht. das meiste nimmt dir doch sowieso die hardware ab, bus-arbitrierung, retransmissions, ack-bit senden und error-frames senden, filterung empfangener frames usw. das bisschen shiften und ausmaskieren (wenn überhaupt), was die CPU tun muss, um eine CAN-ID in einem 16 oder 32-bit register zu verarbeiten, ist ja wohl kein akt. und wenn du das CAN-protokoll in hardware giessen darfst, haste es ja sowieso mit 'programmiersprachen' zu tun (hallo hardwaredesigner, nicht böse sein, habs extra in anführungszeichen gesetzt *fg*), die nicht auf datentypen angewiesen sind, die ein vielfaches von 8 bits haben.
-
;fricky schrieb:
falls du auf den CAN-bus anspielst: was sind 'krumme zahlen'? meinste die 11 bzw. 29-bit CAN-IDs?...
Bei FlexRay: Frame ID 11 Bit, Anzahl Datenworte 7 bit, Zyklus Zähler 6 Bit... (schreibe die Zahlen gerade aus einem Buch ab). Widerspricht doch irgendwie der natürlichen Intuition und riecht nach FlexRay 2.0, oder
Alles irgendwie unvollständig zusammengefrickelt... 
-
abc.w schrieb:
Bei FlexRay: Frame ID 11 Bit, Anzahl Datenworte 7 bit, Zyklus Zähler 6 Bit... Widerspricht doch irgendwie der natürlichen Intuition...
warum? welche 'natürliche intuition' meinst du? wertebereich kein vielfaches von n*2^8, anzahl bits ist ungerade, passt nicht exakt in ein 'byte' der von dir genutzten programmiersprache, oder was?
abc.w schrieb:
...und riecht nach FlexRay 2.0, oder Alles irgendwie unvollständig zusammengefrickelt
wenn 2048 IDs, 128 datenworte oder ein zyklus von 64 nicht reichen, wirds vielleicht irgendwann ein update geben, wenn flexray sonst noch macken hat, vielleicht schon eher.