TCP/IP oder der Zement... |
Mittwoch, 26. November 2003
Collaborative Computing
johannes_pechatschek_salzburg, 15:51h
Marconi’s Traum ging in Erfüllung („Eines Tages werden alle Menschen ihr persönliches Funkgerät besitzen und frei miteinander kommunizieren können...“, 1905), und auch der Schneider von Ulm hätte Tränen in den Augen, könnte er sehen und miterleben, wie ein Jumbojet abhebt. Röntgen würde in seiner Bescheidenheit einen Kernspintomographen wahrscheinlich für ein „Ding aus einer anderen Welt“ halten und nächtelang darüber nachgrübeln, warum man gerade ihn als Vater dieser Entwicklung bezeichnet...
Was hätten wohl die Herren Leibnitz, Zuse, Aiken, Eckert & Mauchley oder Shannon zu unseren heutigen „binären Umtrieben“ beizutragen? Es würde ihnen im ersten Moment beim Anblick eines Personal Computers wahrscheinlich schlicht die Sprache verschlagen, nach (äußerst) kurzer Reflexion aber würde sich bestimmt ein jeder sein Spezialgebiet greifen und mit Feuereifer zu entwickeln beginnen. Selbstverständlich hielte man sich mit Hilfe von Emails, Weblogs, Foren, Messenger-Diensten und klassischen Publikationen gegenseitig auf dem Laufenden. Und mit an Sicherheit grenzender Wahrscheinlichkeit würden unsere großen Vordenker der „Artificial Intelligence“ auch regelmäßig Videokonferenzen einberufen... Wagt man sich als Dompteur der Bits und Bytes an Videokonferenzen, so verhält es sich ähnlich wie mit einem Bergsteiger, der plant, die Eiger Nordwand zu bezwingen, oder wie mit einem Motorradfahrer, der eine 170-PS-Maschine zu pilotieren gedenkt. Allen drei Aspiranten sollte klar sein, dass sie sich auf ein sehr, sehr hohes Niveau ihrer Tätigkeit begeben und dass langjährige Erfahrung und gründliche Vorbereitung eine Grundvoraussetzung für ihr Tun darstellt. Und die Möglichkeit, Schiffbruch zu erleiden und wieder von vorne beginnen zu müssen, ist natürlich auch immer im Hinterkopf zu behalten... Definitionen von „Medium“ finden wir in der Literatur ohne Zahl, wesentlich dünner dagegen wird die Luft beim Versuch, den Begriff „Multimedia“ festzunageln. Nach Dozent Brody spricht man von „Multimedia“ im Zusammenhang mit Medienverknüpfungen, die noch nicht „richtig“ charakterisiert sind – so ich seine Worte als nicht gerade leidenschaftlich stenographierender Zeitgenosse mnemotechnisch korrekt speichern konnte. Ich habe mich in die Tiefen der ebenfalls relativ dünn gesäten technisch-multimedialen Fachliteratur begeben und bei Ralf Steinmetz („Multimedia Technology“, 3. Auflage, Springer-Verlag) folgende Definition gefunden, die mir ebenfalls sehr sympathisch erscheint: „Ein Multimediasystem ist durch die rechnergesteuerte, integrierte Erzeugung, Manipulation, Darstellung, Speicherung und Kommunikation von unabhängigen Informationen gekennzeichnet, die in mindestens einem kontinuierlichen (zeitabhängigen) und einem diskreten (zeitunabhängigen) Medium kodiert sind“ – wobei die Betonung m.E. ganz klar auf „kontinuierlichem Medium“ liegen muss. Und nach dieser Standortbestimmung wären etwa Videokonferenzen zwischen unterschiedlichen Lehrsälen, geleitet von realen und „kodierten“ Vortragenden, multimediale Veranstaltungen reinsten Wassers. (Brody: „Falls der Professor nur einen PC und einen Videobeamer einsetzt, dann sprechen wir nicht von Multimedia, sondern von einer computerunterstützten Vorlesung...“) Dringen wir nun einen Schritt tiefer in die Materie ein, so wird es langsam Zeit, das Gurtzeug und den Helm anzulegen – wir steuern in direkter Konsequenz hart auf den Überbegriff des „Collaborative Computing“ zu... Steinmetz: „Eine breit verfügbare Infrastruktur von vernetzten Rechnern mit der Fähigkeit der Verarbeitung von Audio- und Videoströmen eröffnet den Anwendern die Möglichkeit, kooperativ zusammenzuarbeiten und dabei sowohl räumliche als auch zeitliche Entfernungen zu überbrücken. Die Einbindung in Netze und die Integration von Multimedia-Komponenten in die Endsysteme schafft damit für die Benützer eine Arbeitsumgebung für die gemeinschaftliche und kooperative Arbeit mit Computern. Diese Form der Kooperation wird allgemein unter dem Begriff „Computer-Supported Collaborative Work (CSCW) beschrieben und zusammengefasst.“ Die Dimensionen der Zusammenarbeit lassen sich nach Zeit und Ort in ein Viererschema einfügen: Ort & Zeit gleich: „Face-to-face-work, shared applications, LAN-Parties Ort & Zeit verschieden: Email, Newsgroups, Weblogs, Dynamic Developments Ort gleich, Zeit verschieden: Kommunikations-, Kooperations-, Planungs- und Entscheidungswerkzeuge in Wissenschaft und Wirtschaft Ort verschieden, Zeit gleich: Videokonferenzen, Software-Entwicklung, Messenger –Dienste, Chatrooms, Online-Gaming Ausgehend vom Parameter „Zeit“ können also synchrone, zeitgleiche, und asynchrone, zeitunabhängige Modi unterschieden werden. Wird der Aspekt der Zusammenarbeit betont, so dreht es sich um „Computer-augmented Collaborative Systems“, liegt der Schwerpunkt auf der Verarbeitung durch die Rechner, so spricht man von „Collaboration-augmented Computing Systems“. Für beide gilt immer, dass die rechnerunterstützte Zusammenarbeit zumindest eine soziale Aktivität oder Komponente beinhaltet. Ein weiteres, wesentliches Unterscheidungsmerkmal liegt besonders in der Anzahl der Teilnehmer: Gibt es genau deren zwei, so kann eine direkte Adressierung erfolgen – eine oft auch bei Amateuren eingesetzte „Spielerei unter Freunden“. Findet man Teilnehmergruppen vor, so sind Gruppenmanagement und eine Metainstitution zwingend erforderlich. Ohne solche Hierarchien wäre nicht definierbar, wer wann zu welcher Gruppe gehört und wie eine Gruppe zu adressieren ist. Als dritte Möglichkeit und Sonderform der Gruppe, die sich mehr und mehr zu einem weiteren Standard entwickelt, muss man auch den Broadcast, das „Senden an alle“, ins Kalkül ziehen. Ein nicht zu unterschätzendes Problem resultiert nun – übergeordnet - aus dem Blickpunkt der Datensicherheit: Soll man Kiebitze tolerieren, ja, sind sie sogar erwünscht, oder will man strikt unter sich bleiben? Es wäre nun freilich kein Artikel aus meinem Keyboard, wenn ich nicht auch direkt auf die technische Seite einer Videokonferenz eingehen würde... Und um verstehen zu können, was sich bei einer solchen eigentlich abspielt, sollte man zuerst über die besondere Struktur von Audio- und Videodateien etwas Bescheid wissen. Steinmetz: “Audio spielt für die Beschreibung und Erklärung der visuell dargestellten Informationen in einer Videokonferenz eine sehr wichtige Rolle. Oft ist Audio selbst viel wichtiger als Video. Daher ist eine qualitativ hochwertige Audioübertragung mit einer Voll-Duplex-Kommunikation und Echounterdrückung wünschenswert.“ Beim Duplexmodus können alle Teilnehmer gleichzeitig sowohl senden als auch empfangen, im Unterschied zur Simplex-Kommunikation, welche nur Senden oder Empfangen gestattet – vergleichbar etwa einem Telefon (duplex) und einem Funkgerät (simplex). Sprache, Musik oder hörbare Geräusche welcher Art auch immer, beruhen auf periodischer Kompression und Dekompression von Luft. Ein Mikrophon setzt dieselben in Wechselspannungen genau jener Frequenzen um, mit welcher auch die Luft schwingt. Diese Wechselspannungen werden über Verstärkerschaltungen zu Wechselströmen umgesetzt, die auf einem analogen Steinzeit-Tonbandgerät direkt magnetisch aufgezeichnet werden können. Grundlegend anders verhält sich die Sache, wenn man die Akustik in den Computer bringen möchte – man muss die Signale PCM-kodieren („Pulse Code Modulation“): Ein Analog-Digitalwander tastet das Signal, stark vereinfacht gesprochen, mit einer bestimmten Abtastrate oder Sampling-Frequenz ab und setzt es dieserart in Bits und Bytes um. Claude Elwood Shannon beschrieb diese Technik, bei der die Abtastfrequenz mindestens doppelt so hoch sein muss wie das frequenzmäßig höchste im Umkehrvorgang später dann zu reproduzierende Signal, theoretisch bereits in den Vierzigerjahren des vorigen Jahrhunderts. Und typischerweise arbeiten CD-Player ja mit einer Basic-Sampling-Frequency von 44,1 kHz, also dem doppelten des obersten hörbaren Bereichs von etwa 20 kHz beim Erwachsenen mittleren (meines) Alters, plus einer kleinen Reserve. Bei der hochqualitativen Audio-CD ergibt sich für eine „Datentiefe“ von 64 Bit pro Abtastwert die furchteinflößende Datenrate von 176,4 Kilobyte pro Sekunde. Telefonqualität ohne klangbestimmende, speichergierige Formanten – eine Stradivari klingt dann eben wie eine Zigarrenkiste mit Hals und Drähten - begnügte sich dagegen mit vergleichsweise lächerlichen 8 Kilobyte pro Sekunde aufgrund der Datenreduktion. Um die digitalen Spuren wieder analog hörbar zu machen bedarf es eines Digital-Analogwandlers, der softwaregestützt die Aufgabe des Dekodierens der „Lands“ und „Pits“ einer CD übernimmt. Es leuchtet nun jedermann ein, dass diese Datenmengen viel zu mächtig sind, um bei unseren (derzeit noch relativ) beschränkten Bandbreiten in Echtzeit übertragen werden zu können – und die Videodateien kommen in unserem Fall ja auch noch dazu! Man bedient sich daher unterschiedlicher Datenreduktions- und Kompressionsverfahren, bevor man die Daten auf die Reise schickt. Zum Vergleich: Eine Minute im unkomprimierten, unreduzierten CD-Audioformat (ISO oder Joliet) frisst satte 10,584 Megabyte auf, einer Minute im jedermann bestens bekannten mp3-Format dagegen dürstet nach nur etwa einem Zehntel dieser Einheit, der „komprimierte Telefonhörer“ benötigte ein einziges, bescheidenes Kilobyte pro Sekunde... Des Pudels Kern liegt bei diesen Technologien darin, einen vernünftigen Kompromiss aus hörbarer Qualität und speicherplatzhungriger Quantität zu finden. Und zu allem Überdruss sollte der Dekodierungsprozess nicht nur High-End-Rechnern der allerletzten Generation mühelos möglich sein. Auch in der digitalen Videotechnik muss man - wie beim analogen Film - von einem Einzelbild ausgehen. Ein digitales Bild wird durch zwei Parameter spezifiziert, und zwar einerseits durch die räumliche Auflösung in „Pixel mal Pixel“, jenem dimensionslosen Wert, auf den Hersteller von Digitalkameras in der Werbung so furchtbar gerne und marktschreierisch ihr Hauptaugenmerk legen, und andererseits durch die Farbkodierung, gemessen in Bits pro Pixel (Ein „Pixel“ ist nicht mehr und nicht weniger als ein beinahe dimensionsloser Punkt in einer mathematisch ziemlich aufwendig definierten „Matrix“, einer folglich ebenso dimensionslosen Fläche...). Je höher dieser Bitwert liegt, umso mehr Farben können kodiert werden – man spricht gerne von „Farbtiefe in Bits“. Und auch in der „abbildenden Kunst“ sind wir mit genau demselben Problem konfrontiert wie die Redner und Komponisten: Die Datenmengen werden ohne Kompression in Windeseile unerträglich umfangreich. Unkomprimierte Grafikformate wie etwa die bekannte Urmutter „Bitmap“ oder das im professionellen Grafikbereich gerne verwendete Tagged Image File Format („TIFF“) benötigen bis zum Hundertfachen – und wesentlich mehr - des Speicherbedarfs einer Joint Photographic Experts Group („JPEG“) Datei. Über besonders schlaue Algorithmen schreibt dieser Standard nämlich keine definierte Genauigkeit vor, was zu dramatischer Datenreduktion führt. Zur Erzeugung der für eine Videokonferenz benötigten Bilder bedient man sich meist sehr preiswerter Webcams mit einlinsigem Objektiv von minimaler Lichtstärke und CCD’s („Charge Couple Device“, ladungsgekoppelter Hauptchip einer Digitalkamera, bestehend aus einer Reihe lichtempfindlicher Speicherelemte) geringster Auflösung. Hohe Qualität ist ja nicht von Nöten, da dieselbe nur die Datenmengen steil nach oben katapultieren würde... Selbstverständlich ließe sich auch jede hochwertige, technisch anspruchsvolle Digicam zu diesem Zweck einsetzen – es ist ja auch nicht verboten, bei einem Ferrari einige Zündkerzen zu entfernen... Sind die Probleme mit Audio- und Video-Komprimierung endlich gelöst, so folgt die nächste Herausforderung auf dem Fuße – Goethe würde sagen: „Ein jeder Wunsch, der dir erfüllt, kriegt augenblicklich Junge.“ Man benötigt ein Datenformat, welches den Bildern das laufen beibringen kann und noch dazu im Stande ist, Audio- und Videodateien – selbstredend komprimiert – zu vereinen und zu synchronisieren... Und ein solches wäre beispielsweise das jedermann bekannte MPEG (Moving Picture Experts Group). Es existieren noch einige andere, da natürlich bis Dato die einzelnen Konzerne und Entwickler brav ihre jeweils eigenen Süppchen kochen. Das Prinzip ist aber allen gleich, man bedient sich der wohlfeilen Schichtentechnik - wie sich doch die Kreise immer wieder schließen... Ein komprimierter Audiostrom setzt sich in MPEG aus drei Ebenen zusammen, i.e. die Frames, die in die Audio Access Units (Zugriffseinheiten) gegliedert werden, und diese wiederum werden von den Slots als unterster Ebene aufgebaut. Die kleinstmögliche, vollständig dekodierbare Einheit komprimierter Daten stellt eine AAU dar. Alle in einem Frame enthaltenen AAU’s ergeben bei einer Abtastrate von 44,1kHz eine Spieldauer von 8,7 Millisekunden. Ein Videostrom besteht aus sechs Schichten: In der obersten, dem Sequence Layer, wird die Zwischenspeicherung der Daten mit Hilfe des sogenannten „Video-Buffer-Verifiers“ gesteuert. Darüber hinaus finden sich Einträge über die Bitrate (Qualität) und den für die Dekodierung notwendigen Speicherbedarf. Nicht immer entspricht die Reihenfolge der Bilder im Datenstrom der Reihenfolge der Bilder in der Anzeige. Im „Group of Pictures Layer“ wird ein Referenzbild zum Decoder geschickt, zwischen Datenstrom und Anzeige wird unterschieden. Der „Picture Layer“ beinhaltet ein komplettes Einzelbild. Die zeitliche Abfolge der Bilder wird über die Bildnummer festgelegt, und Reservedatenfelder für zukünftige Anwendungen sind hier implementiert. „Slice Layer“, „Macroblock Layer” und “Blocklayer” seien an dieser Stelle nur der Vollständigkeit halber erwähnt – in diesen Schichten finden sich Skalierungen, Quantisierungen und allerhand sonstige, hochkomplexe Algorithmen, die wir getrost den Kollegen von den Computerwissenschaften oder den Mathematikern überlassen können. Bis zu diesem Moment war, wohlgemerkt, die Rede von digitalen Tonfilmdateien, die man sich via DFÜ in aller Ruhe, Schritt für Schritt, bei Bedarf von einem Server downloaden, speichern, aufrufen und dekodieren, oder, entsprechende Hard- und Softwareausstattung vorausgesetzt, auch selber herstellen kann. Der Zeitfaktor war quasi sekundär. Unser Bergsteiger hätte nun etwa ein Drittel seines Wegs zurückgelegt, der Motorradfahrer würde mit vergleichsweise gemütlichen 100 km/h die Landstrassen unsicher machen. Von „Echtzeit-Streaming“ war noch nicht die Rede. Und um bei diesem Paradigma zu bleiben, hätte der Bergfex den Gipfelsieg vor Augen, die Tachonadel der imaginären Hoyasuka würde sich der 300 km/h-Marke nähern, so man die Dimension der möglichst geringen Zeitverzögerung bei nahezu unvorstellbar komplexen binären Vorgängen mit ins Kalkül zieht: Die analogen Signale von Mikrophon und Kamera müssen zuerst AD-gewandelt werden, es folgen Datenreduktion und Kodierung/Kompression über komplexeste Algorithmen (mathematische Beziehungen), Protokolle müssen beachtet und befolgt werden, Hardware-Netzwerke haben unter Kompensation menschlicher und technischer Unzulänglichkeiten überwunden zu werden, softwaretypische „Wanzen“ soll man auszumerzen. Auf der Empfängerseite läuft der Hase in exakt umgekehrter Richtung. So, und diesen ganzen Wust darf man nun noch mit der Anzahl der Teilnehmer respektive teilnehmenden Gruppen multiplizieren, da ja alle Beteiligten im Duplexmodus sowohl Sender als auch Empfänger sein können... Als Tüpfelchen auf dem i – ich habe es bereits erwähnt – könnte man noch die Möglichkeit einer Echtzeitverschlüsselung der Daten betreiben, so man Kompressionsalgorithmen für die Datensicherheit als unzureichend erachtet. Man gestatte mir, ein beliebtes, joviales geflügeltes Wort der EDV-Branche abzuwandeln: Es gilt nicht nur eine einzelne Kuh vom fragilen Eis zu holen, sondern gleich eine komplette argentinische Hazienda... In aller Kürze und möglichst „untechnokratisch“ erklärt, verlangen Realzeit-Prozesse grundsätzlich nach einem Server und schnellen, breitbandigen Netzen, einfache Client-Client-Verbindungen genügen diesen Ansprüchen nicht mehr. Dieser Server hat nun die rechnerisch äußerst anspruchsvolle Aufgabe, die „Zwischenaufbereitung“ der fließenden Daten zu übernehmen. Und abermals schließt sich ein Kreis, der interessierte Leser ahnt es bereits: Wir benötigen entsprechende Protokolle, damit unsere Videokonferenz nach vorgegebenen Regeln möglichst klaglos über die Bühne gehen kann. CCCP, das „Conference Control Channel Protocol, wäre etwa ein solcher Ansatz, (State-) Agreement-Protokolle schreiben spezielle Regeln, die sogenannten „Policies“ für den Zustand einer Sitzung vor (Initiator-of-Policies, Voting-Policies, Consistency Policies). Bill Gates als oberster Herrscher einer der größten Organisationen des Universums bezeichnet sich selbst gerne als „Softwarearchitekt“. Und wir sprechen in unserem Fall einer Videokonferenz mit Fug’ und Recht nicht länger von „Strukturen“, sondern analog zu Gates von einer höchst umfangreichen „Architektur zur Sitzungssteuerung“. Zum Abschluss erlaube ich mir abermals, Steinmetz zu zitieren, da unsere Meinungen einen ziemlich engen Parallelslalom fahren: „Multimedia-Anwendungen werden in Zukunft immer stärker auf verteilte Umgebungen ausgerichtet und mehrbenutzerfähig sein.“ Dieser Punkt sollte in der Zwischenzeit, wenn auch nicht fehlerfrei, erreicht sein – ein Musterbeispiel dafür, dass Computerliteratur ebenso schnell „partiell altert“ wie die Rechner selbst. „Multimedia-Anwendungen sind bisher stark plattformspezifisch und systemabhängig. Der Trend geht hin zu offenen Lösungen, so dass Anwendungen über verschiedene Plattformen hinweg portierbar sind.“ An dieser Forderung wird mit Hochdruck gearbeitet, die benötigten Protokolle werden bereits (aus)entwickelt, das Ziel steckt seit etwa einem Jahr nicht mehr in den Kinderschuhen und scheint bereits in greifbarer Nähe. „Die Mediennutzung wird im Gegensatz zu der bisherigen eher passiven Nutzung immer aktiver, d.h. der Benutzer kann und muss mehr bestimmen, welche Medien er wo, wie und wann konsumieren will. Die Medienkommunikation wird sich vom unidirektionalen zum bidirektionalen Informationsfluss orientieren.“ Und Collaborative Computing, das sei mir als Schlusswort gestattet, wird das wichtigste Werkzeug auf dem rasanten Weg dorthin sein! „Wir brauchen nicht so fortzuleben, wie wir gestern gelebt haben. Macht euch nur von dieser Anschauung los, und tausend Möglichkeiten laden uns zu neuem Leben ein.“ Christian Morgenstern ... link (1 comment) ... comment Montag, 10. November 2003
User & Windows
johannes_pechatschek_salzburg, 21:17h
Wo stünden wir heute ohne Wilhelm Röntgen, Otto Lilienthal, Samuel Morse, Giuliemo Marconi oder Claude Shannon? Lehrer der Menschheit, die sich allesamt nur einem Grundsatz bedingungslos unterworfen haben: ICH WILL den lebenden Menschen von innen betrachten, fliegen wie ein Vogel, wichtige Nachrichten sofort und ohne langsame Reiterdepesche übermitteln, es noch viel besser machen als mein Kumpel Sam und drahtlos quer über den Atlantik kommunizieren, einer Maschine das Denken beibringen...
Diese Einleitung soll nur Gedankenanstoß sein – wie verschwindend erscheinen gegen Röntgens Krebserkrankung oder Lilienthals Genickbruch doch die Problemchen, mit denen wir uns in der Multimedia-Vorlesung herumschlagen müssen... Auch die Medizin war vor 800 Jahren keine anerkannte Wissenschaft, die oft scharlatanerischen Umtriebe der Alchemisten sind wohl jedermann bekannt. Und dennoch kommt heute kein Mensch mehr auf die Idee, die Chemie, die Medizin oder die Kombination beider, die Pharmazie, in die tiefste Hölle zu wünschen. Man kann mir nun vorwerfen, dass ich, gelinde gesagt, maßlos übertreibe – nun gut, aber auf diese Art und Weise ist es einfach, dem geneigten Leser einen Spiegel vorzuhalten. Zieht man ein Resümee, bezogen auf unser neues Feld der multimedialen Betätigung, so haben wir es unter dem Strich doch verdammt leicht, oder? Und um diesen Kreis und die Einleitung zu schließen, möchte ich nur auf die beiden ursächlichen Aufträge einer Universität hinweisen: Forschung und Lehre – ersteres besonders über die Schiene des Experiments, und letzteres hoffentlich in der Selbstverständlichkeit und mit der Triebfeder der im ersten Absatz erwähnten Genies... Es ist nicht ganz einfach, den Ball zu fangen, den mir Professor Mittendorfer im Kommentar zu meinem Erstlingsartikel zugespielt hat – aber ich werde es nichtsdestotrotz versuchen. Leider, leider kann ich mich jedoch nicht mit einem Marconi oder Shannon messen, und so werde ich mich im ersten Teil meiner Ausführungen wieder einmal auf meine pragmatischen Qualitäten als alter Jagdhund verlassen. Im zweiten Teil wird ein hervorragender Kenner der Windows-Welt zu Wort kommen. Den exzellenten Ausführungen im ::Videokonferenz-FHTW-blog noch etwas hinzu fügen zu wollen scheint müßig – es dürfte von Anfang an jedem, der sich mit Datenfernübertragung etwas auskennt klar gewesen sein, dass es sich bei unserem Stolperstein primär um ein Bandbreitenproblem handeln muss. Meiner bescheidenen Einschätzung nach können die Probleme aber auch noch andere, zusätzliche Ursachen aufweisen - kleinere Stolpersteinchen sowie auch derbe Knüppel zwischen die Datenbeine, sozusagen... Glücklicherweise war ich an der Projektierung einiger Computerlehrsäle der WIFI's Linz und Innsbruck ursächlich als Key Account Manager meiner damaligen Firma beteiligt, weshalb mir Strukturen sehr großer heterogener Netzwerke kein Buch mit sieben Siegeln sind. „Heterogen“ bedeutet in diesem Kontext, dass verschiedene Betriebssysteme und Rechner unterschiedlicher Bauart eingesetzt werden – die Clients laufen allesamt unter Windows, die Hauptserver verlassen sich – hoffentlich - lieber auf Unix mit der entsprechenden Mainframetechnologie. („Homogen“ dagegen wäre etwa ein reines Microdoof-Netz - sorry Bill, das war ein Freudscher Verschreiber, oder warum sonst baut man bei Dir zu Hause lieber auf Unix-Server...) Selbstverständlich existieren nun unterhalb der Main-Nets auch eine ganze Menge Subnets – Netze innerhalb der Netze also, deren Datenströme sich selbstredend interaktiv beeinflussen wie die Elektronenbewegungen in den Nervensträngen und im Gehirn unseres Körpers. Und natürlich können auch die Unternetze wiederum hetero- oder homogen aufgebaut sein... Hand auf's Herz: Wer von uns hat noch nie einen größeren Bock im Zusammenhang mit Rechnern geschossen? Wer saß noch nie händeringend-schwitzend vor seinem Monitor, in der Hoffnung, die Maschine möge um Himmels Willen weiterarbeiten... Denn auch im EDV-Bereich fliegen natürlich die Späne dort, wo gehobelt wird, also latent oder offen beim User. Das mag sich nun anhören wie eine Plattitüde, dennoch wird dieser Umstand gerne unterschätzt, wenn nicht sogar negiert. Im Netzwerk-Alltag findet der stets hoffnungslos überarbeitete Systemanalytiker - der arme Teufel, der kommen muss, wenn sich alles in einem unübersehbaren Chaos verabschiedet hat - meistens mittlere Katastrophen vor, die als Funktion der Fehler über die Zeit exponentiell gewachsen sind... Und natürlich kommt es nicht sofort zum Supergau, wenn an irgend einem Rechner irgend jemand etwas „verschustert“ hat, nein, die Fehler summieren sich eben langsam, aber stetig, bis die Bits und Bytes irgendwann endgültig die weiße Fahne hissen, falls nicht konstant gegengesteuert wird. Die Liste der hausgemachten Todsünden reicht von „A“ wie „Abschalten des Virenscanners“ über "N" wie "Nichtbeachten der Anweisungen des Systemadministrators" bis „Z“ wie „(mutwilliges oder unbeabsichtigtes) Zerstören der empfindlichen Einstellungen in der Systemsteuerung und/oder der Registry“ – und sie ist so lang wie eine tibetanische Gebetsrolle. Leistungseinbußen, gravierende Fehlfunktionen und Totalabstürze in Teil- oder Gesamtnetzen aufgrund von Pilot’s Errors sind daher an der Tagesordnung... Allein das bisher gesagte birgt in der Praxis dermaßen viele Mausefallen, dass die Verwaltung eines wirklich großen Netzes nicht nur nach einem einzelnen hochausgebildeten, hauptberuflichen Systemadministrator verlangt, sondern nach einer ganzen Division echter Könner. Mein Kompliment an die Damen und Herren unseres ZID – ich weiß, wie nervenaufreibend euer Job dort sein kann... Doch diese selbstverschuldeten Ecken und Kanten jedweder Provenienz sind nur der Tragödie erster Teil. Wer sich berufen fühlt, sich mit Systemanalytik zu beschäftigen und sich bereits Basiskenntnisse erworben hat, dem möchte ich den „Networker’s Guide“ von Frank R. Walther wärmstens ans Herz legen. Die folgenden Ausführungen basieren größtenteils auf Walther und ich werde versuchen, meine Rolle als Übersetzer und Interpreter wahrzunehmen. Über diesen Weg sollte es mir eventuell möglich sein, ein gewisses Verständnis für die Komplexität der behandelten Materie zu wecken. Technik, und insbesondere Computertechnik, stellt eine der tragenden Säulen jeglicher multimedialen Arbeit dar. Es erscheint daher völlig legitim, diesen Obelisken wenigstens zu beleuchten, und daher erlaube ich mir, im zweiten Teil dieses Artikels auf Probleme des alles beherrschenden Betriebssystems „Windows“ kurz einzugehen. Dozent Brody stellte die Frage, ob Technik wohl besser ohne den Menschen funktioniere, am 27.10.03 mit einem süffisanten Lächeln in den Raum. Und ich will diese Frage – zumindest bezogen auf unsere Probleme in den Vorlesungen – ganz offen mit einem ebensolchen Lächeln verneinen, denn selbst wenn man den Benützer ausschließt – was klarerweise unmöglich ist – so bleiben noch immer die bugbehafteten Betriebssysteme der Windows-NT-Familie (Win NT, 2000, XP), für deren Fehler (oder „Bugs“, Wanzen) man die User einfach nicht verantwortlich machen darf. „Windows-Rechner tun nicht immer, was der Anwender oder System Operator will. Oft tun sie sogar Dinge, die ihnen strikt untersagt wurden.“ Frank R. Walther weiß, wovon er spricht. Seine Erfahrung, Seriosität und Professionalität sind international anerkannt. „Win-Server senden IP-Broadcasts, ohne dass der Sysop davon gewusst hätte.“ (Walther) "IP-Broadcast" stellt einen Sammelbegriff für das Übertragen von Nachrichten, leitungsgebunden oder auch drahtlos, dar. Es ist schlicht und ergreifend ein Trauerspiel, wenn sich der Server „verselbständigt“ und seinen Gebieter im Regen stehen lässt... "Win-Clients suchen im Internet nach Rechnern Ihrer Firma/Organisation" (ebd.) ...und werden natürlich in tausend Jahren nicht fündig – dafür gibt es mannigfaltige Ursachen, und darauf einzugehen würde zu weit führen. „Win-Rechner halten Internet-Router für WIN-Server und versuchen daher, dort draußen im Internet Namensauflösung zu betreiben.“ (ebd.) Ein „Router“, zu Deutsch „Wegwähler“, stellt so etwas wie einen Verknüpfungsrechner zwischen großen Netzwerken dar. Wegeinstellungen von Hand sind in Großnetzen nicht mehr möglich, ein Router übernimmt daher diese Aufgabe – fast – immer optimal. Falls es nun zu Verwechslungen und/oder Konflikten zwischen Server und Router kommt, folgen automatisch graue Haare. „Win-Rechner benutzen DNS, obwohl selbiges deaktiviert wurde.“ (ebd.) Der Domain Name Server übersetzt die symbolischen Internetadressen, wie z.B. www.mozart.at, in numerische IP-Adressen (z.B. 129.187.10.25). Hierbei dreht es sich um eine Frage der Einstellungen und des Konzepts des Gesamtsystems, ob und auf welchen Rechnern DNS aktiviert sein muss. Es bedarf allerdings keiner ausgeprägten Phantasie, zu erahnen, dass es niemals gesund sein kann, wenn ein Rechner nicht exakt das tut, was man ihm auferlegt... „Win-Treiber missachten alle Regeln der „TCP Sliding Window Flow Control“ und sorgen dafür, dass sämtliche WTS (Windows Terminal Server) extrem lange Antwortzeiten haben.“ (ebd.) Dem ist nichts hinzuzufügen... „Die Windows-Systemsteuerung „Netzwerk“ gleicht manches mal den Dörfern des berühmten Herrn Potemkin: Schöne Fassade. Nicht alles, was die Datenkommunikation ... steuert, erscheint in der Systemsteuerung. Und nicht alles, was man in der Systemsteuerung einträgt, hat den gewünschten Erfolg, da die Gesamtheit ... etwas ganz anderes bewirken kann als das, was einem bei der Konfiguration ... vorschwebte." (ebd.) Der Systemanalytiker Walther bezeichnet Windows durchaus nicht als schlechtes Betriebssystem, und dem kann ich nur beipflichten. (98% aller User wären wahrscheinlich ohne die Entwicklungen eines Bill Gates und seiner Mannen mit einem Computer hoffnungslos überfordert und sozusagen lost in Cyberspace...) Er zeigt und beweist aber auch ganz klar, was der Durchschnittsuser nur erahnen oder, weil es eben schick ist, auf Microsoft zu schimpfen, nachplappern kann: Windows itself macht Fehler, und zwar keine kleinen. Man sieht also, dass die Echtzeitübertragung so immenser Datenmengen, wie sie bei Videokonferenzen anfallen, ein ganz so einfaches Ding dann doch nicht ist. Und dennoch erachte nicht nur ich es für sicher, dass dieses Medium noch im Laufe des Jahres 2004 seinen absoluten Durchbruch schaffen wird. Betrachtet man die schwindelerregend rasante Entwicklung auf dem EDV-Sektor, so kann man zu keinem anderen Schluss kommen als Dr. Hans Herbert Schulze: „Trotz des großen Aufwands von Videokonferenzen werden sie sich durchsetzen, da dadurch andere Kosten für Reise, Unterbringung, Verpflegung usw. wegfallen. Videokonferenzen sind deshalb für viele Kongresse, die heute noch an einem Ort durchgeführt werden, die künftige Veranstaltungsform.“ (Lexikon Computerwissen, rororo, April 2000) Wie alles sich zum Netzwerk webt, Eins in dem andern wirkt und lebt! Wie Datenströme auf und nieder steigen Und sich die falschen Wege zeigen. Mit segenduftenden Schwingen Vom Server in den Client dringen, Elektrisch durch die Kabel klingen! Welch Schauspiel! Aber ach! ein Schauspiel nur Wo fass ich dich, Computerkreatur? www.goethe.at ... link (1 comment) ... comment Mittwoch, 29. Oktober 2003
TCP/IP oder der Zement...
johannes_pechatschek_salzburg, 20:13h
Liebe Kolleginnen und Kollegen,
nun ist es mir doch endlich gelungen, meinen inneren Schweinehund zu überwinden, und ich will tapfer versuchen, meine ersten Gehversuche in Richtung Internetjournalismus zu unternehmen. Obwohl ich mich bereits zu den etwas älteren Jagdhunden zählen darf (Matr.Nr. 81xxxxx, Dropout Ende der Achtzigerjahre, dann anderthalb Jahrzehnte aus Broterwerbsgründen keine Uni mehr von innen gesehen...), muss auch ich, ganz offen gestanden, eine Art Hemmschwelle überwinden. Dabei „fürchte“ ich mich grundsätzlich nicht vor der verwendeten Computertechnik oder dem bei manchen Kollegen/innen als abstrakte Kunst verrufenen HTML, da ich zwei Jahre meines Lebens darauf ver(sch)wendet habe, Computernetzwerke zu verscherbeln. Kopfzerbrechen bereitete mir dagegen die Themenwahl. Anfänglich wollte ich einige Zeilen über HTML und dessen Entwicklung „verbrechen“ - beim Durchstöbern der bereits bestehenden blogs wurde mir aber sehr schnell bewusst, dass dieses Unterfangen mit einem Rucksack voller Redundanzen verbunden sein würde, da hier schlicht und ergreifend zu viele und (viel) zu gute Leute anwesend sind, die über diese Materie schreiben und Hilfestellung anbieten. Und wie sagte schon Altvater Goethe: „Getret’ner Quark wird breit, nicht stark...“ Verursachte mir die Themenwahl bereits Kopfzerbrechen, so bewirken andere Überlegungen schon beinahe kalte Schweißausbrüche und den Griff zum virtuellen Valium-Schachterl: Wie werden meine hochgeschätzten Kollegen/innen auf mein Gestammel reagieren? Die sind doch allesamt viel, viel besser „drauf“ als ich armer Wurm... Wird man mich in der Luft zerreißen? Wird man sich hämisch grinsend bis ans Ende meiner Tage an meinem selbstverschuldeten Elend weiden? Oder werden gar der leitende Professor Mittendorfer und sein ausführender Assistent meine sofortige Verbannung aus Salzburg bei gleichzeitiger Erklärung meiner akademischen Vogelfreiheit veranlassen? Ihr seht also, liebe Kollegen/innen, dass auch ein alter Kämpfer wie ich durchaus von Albträumen umgetrieben werden kann, die bestimmt auch einigen von Euch wesentlich jüngeren nicht fremd sind... Sind der Entschluss gefasst und das Thema gewählt, so tut sich eine weitere Kardinalsfrage abgrundtief auf, an der ein Anfänger schlicht verzweifeln könnte: „Wie sag’ ich’s meinem Kinde“, oder anders ausgedrückt, auf welchem Niveau soll man nun schreiben? Welche Voraussetzungen für meinen Artikel erfüllen die Leser „mit Links“ und wo sind neun Zehntel überfordert? Über all’ diese Dinge weiß ich im Zusammenhang mit dem mir selbstauferlegten Thema nicht sehr viel, und deshalb möchte ich die Vollprofis und Informatiker unter Euch bitten, milde mit mir ins Gericht zu gehen und mich nicht gleich auf’s nächstbeste Rad zu spannen. Denjenigen, die sich ungefähr auf meinem Niveau bewegen, wünsche ich viel Spaß bei der Lektüre. Nun denn, und die zwei oder drei, die weniger Bescheid wissen als ich, die dürfen mir gerne ein Email mit Fragen schicken... Auf die Idee, über das Netzwerkprotokoll TCP/IP zu schreiben brachte mich die Vorlesung von Gastdozent Florian Brody am 27.10.03. Herr Brody verstand es meisterhaft, über diverse streaming-technische Probleme hinweg zu improvisieren, und erwähnte dabei auch ganz kurz das von Robert E. Kahn und Vinton G. Cerf entwickelte TCP/IP, jenen Zement, der – frei verballhornt nach Goethe once again - das Internet im Innersten zusammenhält. Auch in der Netzwerktechnik versteht man – ähnlich wie im Umgangsformenratgeber des Freiherrn von Knigge - unter einem „Protokoll“ im Prinzip nichts anderes als eine Art Verhaltenscodex, ein Regelwerk, an welches sich alle am Netz beteiligten Computer zu halten haben. Man könnte auch von standardisierten und akzeptierten Verhaltensweisen sprechen, nach deren Gesetzmäßigkeiten die Datenpakete oder „packets“ im Internet übertragen werden. Darüber hinaus stellt es nicht nur ein Regelwerk, sondern gleichzeitig ein Transportvehikel für die Daten dar. Und da TCP/IP aus wesentlich mehr als den beiden Namensgebern "Transport Control Protocoll" und "Internet Protocoll" besteht - wir haben es gleich mit einem ganzen Satz von Protokollen und Programmen zu tun - spricht man auch vom sogenannten TCP/IP-Stack oder von der TCP/IP Protocoll-Suite. TCP/IP wird gerne als das Protokoll der „offenen Systeme“ bezeichnet, ein Ausdruck, den man sich wohl aus der Chemie oder Biologie geborgt hat – auch der Mensch stellt ja ein offenes, biochemisch-physiologisches System dar. (Erst bei seinem Tode und dem Erlöschen der biochemischen Reaktionen wird es geschlossen.) Und die kürzeste Definition eines offenen Systems dürfte wohl jene nach Leiden und Wilensky sein: „Offene Systeme stellen eine standardbasierte Rechnerumgebung her!“ TCP/IP wurde allein deshalb zum Industriestandard, weil sich mit seiner Hilfe die „Big Four“ (Email, Datentransfer, Remote-Login und Surfing) unabhängig von der Hardware bewerkstelligen lassen. Doch die „Offenheit“ geht natürlich noch einige wesentliche Schritte weiter: Es ist nicht nur völlig egal, ob man einen Mac oder einen PC sein Eigen nennt, auch die verwendeten Betriebssysteme lassen unser TCP/IP völlig kalt (Unabhängigkeit von der Plattform). Und um die Allroundqualitäten vollends zu erfüllen, fragt TCP/IP nicht nach dem Transportmedium (althergebrachte Kupferstrippen, Glasfaserkabel oder elektromagnetische Wellen), es behandelt alle Hersteller gleich und lässt sich noch nicht einmal vom verwendeten Netzwerkmodell (Stern, Ring...) aus der Fassung bringen... Was hat es nun mit den einzelnen Komponenten des Stacks auf sich? Die theoretischen Voraussetzungen für ein grundlegendes Verständnis derselben – und da werden mir die Informatiker vielleicht Recht geben – würden den Rahmen einer kleinen Abhandlung wie dieser bei weitem sprengen. Wir werden ja sehen, vielleicht entwickelt sich eine rege Diskussion, vielleicht fängt eine Kollegin oder ein Kollege meinen Ball auf, vielleicht werde auch ich selber einen weiterführenden Beitrag verfassen – warten wir die Reaktionen und das Feedback ab. Ich werde mich daher fürs erste darauf beschränken, das auch dem TCP/IP zugrundeliegende netzwerkspezifische Schichtenarchitekturmodell in seinen Grundzügen zu beschreiben und mich gleichzeitig bemühen, es allgemein und nicht nur für Computerwissenschafter verständlich zu erklären. Ohne genauer darauf eingehen zu wollen basieren moderne Netzwerke auf einem „strukturierten Netzwerkschichtenmodell“ bestehend aus sieben Schichten, durch welche sich die Daten sozusagen durchfressen müssen – wir erinnern uns an die Geschichte vom Schlaraffenland... Zur Funktionserklärung von TCP/IP bedarf es allerdings nur deren fünf, es hat ja auch schon einige Jährchen auf dem Buckel. (Im Jahre 1982 wurde das alte NCP, „Network Control Protocoll“, durch TCP/IP abgelöst – die Entwicklung desselben begann jedoch bereits wesentlich früher! Der potentielle Nachfolger von TCP/IP, IPv6, und das sei nur der Vollständigkeit halber erwähnt, folgt dem Siebenermodell.) Die erste und unterste Schicht der Architektur stellt der „Physical Layer“ oder die Bitübertragungsschicht dar. Es dreht sich um eine rein hardwarespezifische Ebene, in welcher die elektronischen Signale verarbeitet und verwaltet werden. (Netzwerkkarte, Kabel usw.) In der zweiten Schicht, dem „Data Link Layer“, auch Sicherungsschicht genannt und ebenfalls hardware-relevant, werden die Daten in die berühmten „packets“ zerlegt, die Verkabelung wird verwaltet und Störeinflüsse wie Elektromagnetismus oder Sonnenfleckenaktivität werden korrigiert und kompensiert. In der dritten Schicht, dem „Network Layer“ greift TCP/IP – es handelt sich ja um Software - zum ersten mal aktiv ein. Die Netzwerkschicht erhält die Datenpakete von der Sicherungsschicht und leitet sie an die korrekte Zieladresse weiter, bei mehreren möglichen Wegen wird der beste ermittelt. Die Sicherungsschicht kann nun nicht gewährleisten, dass die packets in der richtigen Reihenfolge, in korrekter Zahl und unbeschadet an Ihrer Zieladresse ankommen – diesen Rückversicherungsauftrag für die Zuverlässigkeit eines Netzwerks übernimmt die Transportschicht. Auch TCP ist in ihr beheimatet. Der fünfte und oberste Layer ist nun besonders dick und kombiniert gleich drei Schichten der moderneren Torte, nämlich die Kommunikationssteuerungsschicht („Session Layer“), die Darstellungsschicht („Presentation Layer“) sowie die Anwendungsschicht („Application Layer“). IP ist in der K-Schicht angeordnet, alle übrigen Protokolle befinden sich in D und A. Der Terminus „Session“ bedeutet nicht mehr und nicht weniger, als dass eine Verbindung zweier Computer natürlich Grundvoraussetzung für Datentransfer ist. Erst nachdem eine Verbindung hergestellt ist, kann dieselbe auch verwaltet werden, und es kommen beispielsweise Sicherheitsmodule zum Tragen. Die D-Schicht ist zuständig für der Herstellung der Kompatibilität unterschiedlicher Betriebssysteme (Unix, Windows, Linux, Mac-OS...) und deren Dateiverwaltungssystemen. Die A-Schicht, schlussendlich, könnte man als die Schicht der User bezeichnen – ohne Application-Layer könnten wir keine Emails versenden oder Dateien transferieren. „Netzwerke und Protokolle sind untrennbar. Ohne Netzwerke haben Protokolle keinen Existenzgrund. Ohne Protokolle wären Netzwerke nur eine nutzlose Ansammlung teurer Maschinen. Und ohne TCP/IP wäre das Internet ein schöner Traum auf der Suche nach Verwirklichung.“ (Candace Leiden und Marshall Wilensky) ... link (2 comments) ... comment |
Online for 7696 days
Last update: 2003.12.07, 11:21 status
You're not logged in ... login
menu
search
calendar
recent updates
angenehm zu lesen...
... wie eigentlich alle Deine Texte. Anfangs noch von... by wolfgang_bauer_salzburg (2003.12.07, 11:21) Collaborative Computing
Marconi’s Traum ging in Erfüllung („Eines... by johannes_pechatschek_salzburg (2003.11.26, 15:51) gut, weiter so
aber ergänzen möchte ich die Anmerkung, dass... by Hans.Mittendorfer.Uni-Linz (2003.11.12, 18:14) User & Windows
Wo stünden wir heute ohne Wilhelm Röntgen,... by johannes_pechatschek_salzburg (2003.11.11, 20:22) Ein Genuss...
...dich zu lesen, wenn ich auch kurzerhand die Musik... by kristian_savic_salzburg (2003.10.29, 21:37) |