Unser erstes Ruby on Rails Projekt ist nun endlich online!
Unter dem Motto „Kein Wettskandal – Skandalwetten!!!“ geht es bei der Webseite www.wetteifern.de darum der Wettkönig zu werden. Noch befindet sich das Projekt in der öffentlichen Betaphase und wird ständig erweitert.
Die alte Festplatte ist voll und es muss eine neue her. Wieso veraltete Technik kaufen, also habe ich gleich eine 200 GB Samsung SATA Platte mitgenommen und noch die passenden Strom- und SATA-Kabel. Na so ein Festplatteneinbau ist ja eigentlich keine große Sache, doch das gute alte Windows 2000 sollte mir viele Steine in den Weg werfen…
Das System gestartet und die Platte wurde unter Windows nur mit einer Größe von 137 GB erkannt. Zuerst dachte ich, dass es an der MSI RS480M2 Hauptplatine lag, ein Blick ins BIOS zeigte aber die richtige Größe. Nach einiger Zeit fand ich die Lösung bei Microsoft. Trotz Service Pack 4 kann Windows 2000 leider keine 48-Bit-LBA.
Das Problem war gelöst, aber es sollte nicht dabei bleiben. Nach dem Kopieren der alten IDE Platte auf die neue SATA Platte war diese ungewöhnlich langsam und die Ursache unauffindbar. Ich probierte es mit neuen Treibern in diversen Versionen, Jumpern der Platten auf SATA 150 und auch mit einem BIOS-Update – leider ohne Erfolg. Nach stundenlanger Suche war das Problem gefunden und es lag mal wieder an Windows 2000: das Laufwerk lief nur im langsamen PIO-Modus und nicht mit DMA. Die Lösung fand sich im BIOS. Beim MSI RS480M2 kann man für den SATA-Controller den DMA-Modus auf den Wert 5 begrenzen und hat so unter Windows 2000 keine Probleme mehr.
So nervig kann das Aufrüsten sein. Glücklicherweise brachte das BIOS-Update von Version 3.5 auf 3.9 gleich noch Cool ’n‘ Quit für den Athlon 64 mit und so hatte die Aktion doch noch etwas Gutes.
Seit kurzem gibt es den Samsung Syncmaster 225BW zu kaufen. Bedingt durch seine Größe und relativ hohe Auflösung war sofort das Interesse geweckt.
Hier die technischen Daten laut Hersteller:
Zuerst hatte ich mit dem 20er Samsung geliebäugelt, die zwei Zoll mehr fand ich dann aber sehr interessant. Da der preisliche Unterschied nicht so hoch war, habe ich das Teil einfach mal blind online bei HoH für 430 Euro inkl. Versand bestellt und nach drei Tagen wurde er mit DHL geliefert.
In der Box fanden sich Strom-, DVI- und D-SUB-Kabel. Außerdem noch so einiges an Papier, aber keine echte Anleitung, denn die ist auf der mitgelieferten CD als PDF vorhanden. Außerdem sind auf der CD noch Programme zum Einstellen der Farbe und des Monitor mit der Maus.
Vorgehen nach http://www.mediawiki.org/wiki/Installation.
Nach dem Download der aktuellen Version (1.8.1 vom 11.10.2006) wurde das Archiv auf dem lokalen Rechner entpackt und per FTP auf den Webserver hochgeladen.
Damit PHP 5 per CGI funktioniert mussten alle php-Dateien auf CHMOD 755 gesetzt werden.
Dann wurde die Seite im Browser aufgerufen und den Anweisungen gefolgt, sowie alle Angaben für die Umgebund und den Datenbankserver eingegeben.
Meilenstein: Wiki installiert.
Damit noch niemand im unfertigen Wiki rumpfuscht wird das gesamte Verzeichnis per .htaccess geschützt.
Die Datei .htaccess erweitert und sieht nun so aus.
AuthType Basic
AuthName „Interner Bereich“
AuthUserFile (Pfad gelöscht *fg*)
Require valid-user
Order deny,allow
Deny from All
Satisfy any
AddHandler cgi-script .php
Zusätzlich muss die Datei .htusers angelegt werden. Diese enthält die einzelnen Nutzer und wird aus verständlichen Gründen nicht veröffentlicht.
So, das Thema ist festgelegt.
Erstellung eines Wikis zum Thema „Web 2.0“
Beschränkung: PHP & MySQL.
Bevor es logeht lege ich eine passende Kategorie hier auf technixblog an, um alle Schritte zu dokumentieren. Damit auch meine beiden Mitschreiber ihre Tätigkeiten hier kurz dokumentieren können, richte ich zwei Nutzer für sie ein. Login ist jeweils der Name (Anfangsbuchstabe großgeschrieben). Als Initialpasswort habe ich den Namen einer uns allen bekannten, fußballverrückten Kommilitonin gewählt, wobei die Vokale großgeschrieben (alles andere klein) sind. Das Passwort kann (sollte) nach dem ersten Login geändert werden.
Auswahl der Plattform
Nach kurzer Überlegung kommt nur MediaWiki in Frage. Für den Server bietet sich technixblog.de an. Platz ist noch vorhanden, PHP- und MySQL-Üntersützung ebenfalls. Um das Wiki gut erreichbar zu machen, wird die Subdomain wiki eingerichtet. Das Wiki wird also unter wiki.technixblog.de erreichbar sein.
Einrichten von PHP5
Die aktuelle Version 1.8.1 benötigt PHP5. Da auf dem Webserver PHP4 als Standardumgebung gesetzt ist und PHP5 zusätzlich installiert ist, muss eine Richtlinie gesetzt werden, dass .php-Dateien mit PHP5 geparsed werden.
Dies geschieht mit ein .htaccess-Datei die in das Stammverzeichnis des Wikis kopiert wird.
.htaccess
AddHandler cgi-script .php
Da PHP5 als CGI eingebunden ist, müssen .php-Dateien ausführbar gesetzt werden (CHMOD 755).
Ein Test mit der Datei phpinfo.php funktioniert!
phpinfo.php
Die weiteren Anforderungen sind auf dem Webserver ebenfalls erfüllt. MySQL muss mindestens 4.x sein.
Das gelbe Blitzsymbol am Drucker leuchtet auf und es erscheint eine Fehlermeldung obwohl genug Papier im Schacht 2 vorhanden ist:
Papier auffüllen
BP: A4 NRML
Nach dem Anruf beim Kundendienst habe ich endlich rausgefunden wieso der Drucker nicht mehr drucken wollte.
Damit der Fehler nicht mehr auftritt, muss man bei Word die Seite einrichten > Format und dort den richtigen Papierschacht wählen. Dann klappt auch wieder das Drucken. Erstaunlicherweise hatte dieselbe Einstellung beim Drucken direkt keine Wirkung.
Das in Java entwickelte Programm zum Abzählen von 3×3 Sudoku-Gittern mit dem Dancing-Links-Algorithmus ist nun samt Dokumentation fertig. Später wird noch ein Sudoku-Benchmark erscheinen, mit dem man die Leistung der Java Virtual Machine (JVM) für diesen speziellen Fall testen kann. Hier die Dateien zum runterladen:
dlx_sudoku.jar inkl. Quellen
java -jar dlx_sudoku.jar threads – Startet das Programm mit 10 Threads (Mehrprozessorfähig)
java -jar dlx_sudoku.jar – Startet das Programm ohne Threads
Beim Uploaden von einigen Dateitypen ziegt WordPress die Meldung Der Dateityp entspricht nicht den Sicherheitsrichtlinien an. WordPress prüft beim Hochladen den Dateityp und gibt bei unbekannten Typen diese Fehlermeldung aus.
Damit WordPress 2.0.4 zusätzliche Dateitypen kennt, müssen diese in die Datei /wp-includes/functions-post.php ab Zeile 970 eingetragen werden.
function wp_check_filetype($filename, $mimes = null) {
// Accepted MIME types are set here as PCRE unless provided.
$mimes = is_array($mimes) ? $mimes : apply_filters(‚upload_mimes‘, array (
‚jpg|jpeg|jpe‘ => ‚image/jpeg‘,
‚gif‘ => ‚image/gif‘,
‚png‘ => ‚image/png‘,
[…]
‚class‘ => ‚application/java‘,
‚tar‘ => ‚application/x-tar‘,
‚zip|jar‚ => ‚application/zip‘,
‚gz|gzip‘ => ‚application/x-gzip‘,
‚exe‘ => ‚application/x-msdownload‘
));
[…]
In meinem Fall habe ich die gewünschte Endung .jar einfach hinter die vorhandenen Endungen zip geschrieben und mit ‚|‘ abgetrennt.
In meiner Seminararbeit über Topologiebewusstes, proaktives Ad-Hoc-Routing habe ich mich intensiv mit dem Optimized Link State Routing (OLSR) und dem Hybrid Landmark Routing (Hybrid LANMAR) beschäftigt. Da OLSR ohnehin recht gut dokumentiert und Hybrid LANMAR noch relativ neu ist, stelle ich den Teil zu Hybrid LANMAR online.
Wie der Name bereits andeutet, handelt es sich dabei um ein hybrides Protokoll, es vereint proaktives und reaktives Routing. Genau wie OLSR baut das Hybrid Landmark Routing auf ein bereits existierendes Verfahren auf. Hybrid LANMAR ist eine Optimierung des LANMAR Protokolls. Beide Protokolle nutzen die Annahme, dass es meistens Bewegungen ganzer Gruppen in MANETs gibt. Die eigentliche Optimierung bei Hybrid LANMAR liegt in einer verbesserten Behandlung des Falls, wenn sich einzelne Knoten nicht in einer Gruppe bewegen.
Beispieltopologie Hybrid LANMAR
Wie in der Abbildung dargestellt kann man sich ein MANET mit bewegenden Gruppen (graue Ellipsen) vorstellen. Blaue Punkte sind die Knoten, die sich individuell bewegen und die ich externe Knoten nennen werde. Die grünen Linien sind die Verbindungen zwischen den Knoten. Ein schwarzes Dreieck stellt einen Gruppenführer dar. Es ist aber nicht ausgeschlossen, dass sich Gruppen mit der Zeit ändern und neue Mitglieder gewinnen oder verlieren.
Die Autoren von Hybrid LANMAR unterteilen das Routing in drei Bereiche: lokale Wegfindung, Finden von Gruppen und Auffinden einzelner Knoten, die nicht in einer Gruppe sind.
Für das lokale Routing innerhalb eines bestimmten Bereichs wird das Fisheye Protokoll genutzt. Es begrenzt die Entfernung (Hops) auf einen relativ kleinen festgelegten Wert und ist ein proaktives Verfahren.
Damit auch außerhalb des lokalen Bereichs Wege gefunden werden können, wird das Verfahren um einen Gruppenführer (=GF) erweitert. Er ist Repräsentant seiner Gruppe und für die Vernetzung mit weiteren Gruppen zuständig. Sobald ein GF bestimmt wurde, fängt dieser an das gesamte Netzwerk über sein Dasein zu informieren. Doch wie wird ein GF bestimmt? Als GF wird der Knoten gewählt, der die meisten benachbarten Knoten in seiner Gruppe besitzt, üblicherweise sollte dies in der Mitte der Gruppe und nicht am Rand der Fall sein.
Beim klassischen LANMAR Protokoll ist jeder externe Knoten als seine eigene Gruppe definiert. Je mehr externe Knoten es gibt, desto mehr Gruppen existieren. Folglich sinkt die Skalierbarkeit. Hier setzt Hybrid LANMAR an und nutzt dafür ein reaktives Routingverfahren, das nicht ständigen, schlecht skalierbaren, proaktiven Aktualisierungen unterliegt, da es von der Gruppenstruktur getrennt arbeitet.
Ein jeder Knoten speichert die drei Routingtabellen für lokales Routing, Routing innerhalb der Gruppen (engl.: Landmark Routing Table), Routing für externe Knoten und einen Zwischenspeicher über die Gruppenzugehörigkeit der Zielknoten lokal ab. Der Ablauf der Wegefindung sieht dann wie folgt aus:
Wie wird die Gruppenzugehörigkeit bestimmt? Dazu muss man wissen, dass bei Hybrid LANMAR eine IP-Adresse in zwei Hälften aufgeteilt wird. Die erste Hälfte enthält die (variable) Nummer der zugehörigen Gruppe eines Knotens und die zweite Hälfte dessen eindeutige Kennung/Adresse. Als Gruppennummer wird einfach die Kennung des GF genutzt. Ist ein Knoten nicht Mitglied einer Gruppe, wird seine Gruppennummer auf null gesetzt. Um die Gruppenzugehörigkeit festzustellen wird ein verteiltes System zur Namensauflösung (DNS) mit der Kennung des Zielknotens befragt und als Antwort erhält man eine IP-Adresse mitsamt Gruppennummer und Knotenkennung.
Meiner Meinung nach liegen hier einige Schwachstellen in der Erklärung seitens der Erfinder von Hybrid LANMAR. Wie soll dieses verteilte DNS-System aussehen? Muss jeder x-te Knoten solche Informationen bereitstellen oder wie sieht dies in der Realität aus? Erzeugt ein solches System nicht zusätzliche Bandbreite?
Auch beim Routing zur nächsten Gruppe bleiben noch Fragen offen. Ist ein Paket von einer Gruppe bei der nächsten Gruppe angekommen, so soll nach dem Willen der Autoren nach der Tabelle für lokales Routing die Wegewahl bestimmt werden. Aber was ist wenn es eine große Gruppe ist und die Anzahl der möglichen Hops zu klein gewählt wurde? Hier hätte eine Grafik zur Erklärung vielleicht behilflich sein können.
Der Entwurf zu Hybrid LANMAR ist vom September 2005 und damit noch sehr neu. Anwendungen in der Praxis wird man schwerlich finden, weshalb ich mich kurz auf die Resultate der Tests aus dem Entwurf beziehen werde.
Glaubt man den Statistiken, ist Hybrid LANMAR eine erfolgreiche Verbesserung des ursprünglichen LANMAR Protokolls. Es sind nur wenige Nachteile zu erkennen. Hybrid LANMAR benötigt etwas mehr Verwaltungsaufwand zur Wegebestimmung. Durch das reaktive Routing steigt außerdem die Verzögerung bis ein Paket übertragen wurde. Die Vorteile überwiegen, denn bei gleichem Durchsatz weist Hybrid LANMAR eine wesentlich höhere Anzahl erfolgreich zugestellter Pakete auf, je mehr externe Knoten es gibt. Das Ziel der Entwickler scheint erfüllt.
Ursprünglich hatte ich in meiner Seminararbeit am Ende OLSR und Hybrid LANMAR verglichen. Da hier nur der Teil über Hybrid LANMAR zu finden ist und ich nicht alles neu schreiben wollte, habe ich einen passenden Abschnitt kopiert. Dieser befasst sich mit möglichen Problemen:
Bei Hybrid LANMAR wird es sich negativ auswirken, wenn eine Gruppe ihren GF verliert und dadurch bei allen Knoten der Eintrag aktualisiert werden muss. Während bei OLSR keine Änderungen an den IP-Adressen notwendig waren, baut Hybrid LANMAR auf eine Kombination von Knoten- und Gruppenkennung auf. Bei nicht angepassten Anwendungen kann dies zu Problemen führen, da sich die Adresse durch eine neue Gruppenzuordnung ändert. Auch die Rückgewinnung der Gruppenzugehörigkeit über das verteilte DNS-System lässt noch offene Fragen, die erst noch geklärt werden müssen.