Was Tschibo und Sun Microsystems miteinander zu tun haben? Nun beide ermöglichen Ihren Kunden den verantwortungsvollen Umganz mit Energie. Bei Tschibo ist das in Form eines Watt-Meters. Jörn berichtet darüber in seinem Blog: EDV - Ende der Vernunft: Part1, Part2.
Geschrieben von Bernd Eckenfels
in Enterprise IT, Hardware, Technik
| Kommentare (0)
| Trackbacks (0)
In meiner Freizeit pflege ich die net-tools für Linux. Das ist eine Sammlung der grundlegenden Netzwerk Konfigurationsbefehle wie netstat, arp und ifconfig.
Deswegen bekomme ich öfters Anfragen und Fehlermeldungen wegen unerwartetem Verhalten dieser (und anderer) Netzwerk Programme, bei der Eingabe von IPv4-Addressen mit führenden Nullen, wie zum Beispiel: 010.010.010.010 oder 120.130.130.099.
In der Literatur (RFC790 macht dies falsch), und vor allem beim Umgang mit dem Rechner sollte man diese formatierungen vermeiden (besonders fatal ist es, wenn Programme diese Art von formatierung selbst verwenden!). Der Grund: eine Reihe von Implementierungen erlauben traditionell eine gaze Reihe von Schreibweisen für IPv4 Addressen. Darunter fällt auch die Interpretation der einzelnen Punkt-getrennten Nummern als Octalzahlen (statt Decimal), wenn diese eine führende null besitzen (oder hexadezimale Interpretation bei einem 0x Prefix, wie in C üblich).
Nicht alle Programme erlauben diese Schreibweise, und noch weniger Menschen ist diese geläufig. Das ist wohl auch ein guter Grund, warum man diese nicht verwenden sollte. Allerdings sollte man sich bewusst sein, dass manche Software die Zahlen anders interpretiert (oder sogar abweist, weil 100.100.100.09 keine gültige Octal-Zahl ist)
(Das Windows XP Ping.exe verhält sich übrigens genauso). Für Techniker: traditionell wird in der Unix Welt die Umsetzung von Strings in IPV4 Addressen mit der C-Library Funtion inet_aton(3) gemacht, die diese Interpretation vornimmt. Diese Function erlaubt auch die Angabe einer IP Addresse in Hexadezimalschreibweise 0x08080808 oder mit einer 16bit Komponente: 8.8.2056 oder eben mit Octal/Hexadecimal Prefix.
Übrigens erlaubt RFC3986 (der den Syntax für URLs angibt) diese Schreibweise nicht, und definiert nur Decimal-Zahlen. Das ist auch eine Konsequenz aus den Angriffen auf String-basierende URL Fillter die sich zu leicht durch die vielen unterschiedlichen Schreibweisen haben auf das Kreuz legen lassen.
Im Zuge der Umstellung auf IPv6 wurde die Fähigkeit der alternativen Schreibweisen übrigens in den meisten Implementierungen entfernt, z.b. inet_ntop weist diese Funktion nicht auf.
Die IPv6 RFCs (RFC3531) haben den selben Fehler wie die IPv4 RFCs gemacht, und vergessen die IPv6 Literale formal zu definieren (keine BNF Definition), auch dies wurde in RFC3986 nachgeholt.
Deswegen bekomme ich öfters Anfragen und Fehlermeldungen wegen unerwartetem Verhalten dieser (und anderer) Netzwerk Programme, bei der Eingabe von IPv4-Addressen mit führenden Nullen, wie zum Beispiel: 010.010.010.010 oder 120.130.130.099.
In der Literatur (RFC790 macht dies falsch), und vor allem beim Umgang mit dem Rechner sollte man diese formatierungen vermeiden (besonders fatal ist es, wenn Programme diese Art von formatierung selbst verwenden!). Der Grund: eine Reihe von Implementierungen erlauben traditionell eine gaze Reihe von Schreibweisen für IPv4 Addressen. Darunter fällt auch die Interpretation der einzelnen Punkt-getrennten Nummern als Octalzahlen (statt Decimal), wenn diese eine führende null besitzen (oder hexadezimale Interpretation bei einem 0x Prefix, wie in C üblich).
Nicht alle Programme erlauben diese Schreibweise, und noch weniger Menschen ist diese geläufig. Das ist wohl auch ein guter Grund, warum man diese nicht verwenden sollte. Allerdings sollte man sich bewusst sein, dass manche Software die Zahlen anders interpretiert (oder sogar abweist, weil 100.100.100.09 keine gültige Octal-Zahl ist)
# ifconfig lo 010.010.010.010
# ifconfig lo | grep inet
inet addr:8.8.8.8 Mask:255.0.0.0
# ping -c 1 010.010.010.010
PING 010.010.010.010 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=64 time=0.070 ms
# ping -c 1 0x08080808
PING 0x08080808 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=64 time=0.078 ms
(Das Windows XP Ping.exe verhält sich übrigens genauso). Für Techniker: traditionell wird in der Unix Welt die Umsetzung von Strings in IPV4 Addressen mit der C-Library Funtion inet_aton(3) gemacht, die diese Interpretation vornimmt. Diese Function erlaubt auch die Angabe einer IP Addresse in Hexadezimalschreibweise 0x08080808 oder mit einer 16bit Komponente: 8.8.2056 oder eben mit Octal/Hexadecimal Prefix.
Übrigens erlaubt RFC3986 (der den Syntax für URLs angibt) diese Schreibweise nicht, und definiert nur Decimal-Zahlen. Das ist auch eine Konsequenz aus den Angriffen auf String-basierende URL Fillter die sich zu leicht durch die vielen unterschiedlichen Schreibweisen haben auf das Kreuz legen lassen.
Im Zuge der Umstellung auf IPv6 wurde die Fähigkeit der alternativen Schreibweisen übrigens in den meisten Implementierungen entfernt, z.b. inet_ntop weist diese Funktion nicht auf.
Die IPv6 RFCs (RFC3531) haben den selben Fehler wie die IPv4 RFCs gemacht, und vergessen die IPv6 Literale formal zu definieren (keine BNF Definition), auch dies wurde in RFC3986 nachgeholt.
Tekrati ist immer wieder interessant. Analysten veröffentichen Ihre Arbeiten und Tekrati berichtet darüber. Leider wollen die Analysten nicht für Freiheit und Bier arbeiten. So muß man sich mit dem Vorschau-Content zufrieden geben.
Manchmal frage ich mich aber wirklich, wer würde $3.995 (oder $12.995) zahlen für eine Untersuchung der größten Colocation Facilities und Anbieter der Welt? Ist das die Art, wie man eine strategische Entscheidung vorbereitet?
Anyway, TeleGeography bietet auch einige freie Ressourcen an. Wer Karten und Bilder mag kann sich dort ja mal umsehen (Registrierung notwendig).

Manchmal frage ich mich aber wirklich, wer würde $3.995 (oder $12.995) zahlen für eine Untersuchung der größten Colocation Facilities und Anbieter der Welt? Ist das die Art, wie man eine strategische Entscheidung vorbereitet?
Anyway, TeleGeography bietet auch einige freie Ressourcen an. Wer Karten und Bilder mag kann sich dort ja mal umsehen (Registrierung notwendig).

Gerade kam über die Linux-Kernel Mailingliste ein interessanter Link:
http://www.psc.edu/networking/projects/tcptune/
TCP Tuning auf unterschiedlichen Systeme. Ein Must-Read für Admins von stark belasteten Servern und für alle die effiziente Datentransfers über schnelle Netzwerke suchen.
Die Bandbreiteninflation bei DSL Zugänge (zusammen mit der typischerweise hohen Latenz) erfodert auch immer mehr das Anpassen der konservativen Defaults bei den gängigen Betriebsystemen. Auch dafür ist der Link gut geeignet, wenn auch sehr technisch. Powersauger sollten besser auf einfach zu bedienende Speed Tuning Tools ausweichen.
http://www.psc.edu/networking/projects/tcptune/
TCP Tuning auf unterschiedlichen Systeme. Ein Must-Read für Admins von stark belasteten Servern und für alle die effiziente Datentransfers über schnelle Netzwerke suchen.
Die Bandbreiteninflation bei DSL Zugänge (zusammen mit der typischerweise hohen Latenz) erfodert auch immer mehr das Anpassen der konservativen Defaults bei den gängigen Betriebsystemen. Auch dafür ist der Link gut geeignet, wenn auch sehr technisch. Powersauger sollten besser auf einfach zu bedienende Speed Tuning Tools ausweichen.
« vorherige Seite
(Seite 2 von 2, insgesamt 19 Einträge)
Layout by Ricky Wilson | Serendipity Template by Carl Galloway | Login
Impressum
Bernd Eckenfels
Mörscher Str. 8
76185 Karlsruhe
bernd-08(a)eckenfels.net
Read More
Suche
Umfrage
Inhouse Coding?
Archive
Archive
Blog abonnieren
Blogsphere
Top Referers
www.google.de (26)
www.google.at (3)
209.85.135.104 (2)
extrabot.com (2)
www.google.ch (2)
search.live.com (1)
www.eckes.org (1)
www.google.hr (1)
www.keywordspy.com (1)
www.michaelreichart.de (1)
www.google.at (3)
209.85.135.104 (2)
extrabot.com (2)
www.google.ch (2)
search.live.com (1)
www.eckes.org (1)
www.google.hr (1)
www.keywordspy.com (1)
www.michaelreichart.de (1)

Kommentare
2008-08-12 16:59
2008-08-12 10:35
2008-08-12 09:04
2008-08-12 03:23
2008-07-21 20:44
2008-07-18 21:17
2008-07-15 19:00
2008-07-01 04:35
2008-06-12 14:47
2008-05-30 00:44