Diplomarbeit. Zur Erlangung des akademischen Grades Diplom-Ingenieur

Größe: px
Ab Seite anzeigen:

Download "Diplomarbeit. Zur Erlangung des akademischen Grades Diplom-Ingenieur"

Transkript

1 Diplomarbeit Zur Erlangung des akademischen Grades Diplom-Ingenieur Entwicklung eines Netzwerk-Interface zur Steuerung Datenkommunikation einer Netzwerkkarte Angefertigt von Martin Wodrich bei Prof. Dr.-Ing. Axel Hunger Institut für Mentechnik und Software-Engineering (IMSE) Abteilung Informatik, Informations- und Mentechnik Universität Duisburg-Essen, Campus Duisburg Duisburg, den 8. März 2005

2 2 Inhaltsverzeichnis Abbildungsverzeichnis... 4 Tabellenverzeichnis Einleitung Active Network Eigenschaften und Überblick Vergleich Active Networks gegenüber herkömmlichen passiven Netzwerkumgebungen Das Active Network Encapsulation Protocol (ANEP) Untersuchung bestehen Active Network Systeme Magician ANTS Switchware Netscript Zusammenfassung und Übersicht weiterer Active Network Systeme Zugriffsmöglichkeiten auf Netzwerkkarte unter Microsoft Windows Netzwerk-Bestandteile des Usermode Netzwerk-Bestandteile des Kernel-Mode Eignung für Active Network Zwecke Ablauf eines Netzwerkzugriffes Netzwerkzugriff vorbereiten Netzwerkzugriff eines Server (verbindungsorientiert) Netzwerkzugriff eines Client (verbindungsorientierent) Netzwerkzugriff eines Sen (verbindungslos) Netzwerkzugriff eines Empfänger (verbindungslos)... 23

3 Anforungen an Active Network Systemarchitektur Überblick über verschiedenen Komponenten Dateinamenskonventionen Zusammenarbeit aller Komponenten bei Netzwerkzugriffen Initialieren des Netzwerkstabels Anlegen eines Sockets Binden eines Sockets an eine Netzwerkadresse Aufnahme einer Verbindung durch einen Client Annehmen einer Netzwerkverbindung Daten senden Daten empfangen Möglichkeiten eines Execution Enviroment Schnittstellenbeschreibungen Windows Sockets Application Programming Interface (API) Windows Sockets 2.0 Service Provi Interface(SPI) Application Layer Active Network Monitor API Application Layer Active Network Protokoll Helper API Application Layer Active Network Execution Enviroment API Benung Application Layer Active Network Systemarchitektur Grenzen Application Layer Active Network Systemarchitektur Neuere und zukünftige Entwicklungen Ane Windows Versionen Portierbarkeit hier beschriebenen Ideen auf ane Platformen Zusammenfassung Anhänge Active Network Encapsulation Protocol (ANEP) TypeID Die Protokolle TCP/IP Protokollfamilie Literaturverzeichnis... 68

4 4 Abbildungsverzeichnis Abbildung 2.1 Überblick Active Networks... 7 Abbildung 2.2 Möglichkeiten eines Active Network... 8 Abbildung 2.3 NodeOS... 9 Abbildung 2.4 Aufbau eines ANEP-Pakets...9 Abbildung 2.5 Magician SmartPacket...11 Abbildung 2.6 Netscript Box-Struktur (Beispiel)...12 Abbildung 3.1 Windows Netzwerkstack (Usermode) Abbildung 3.2 Windows Netzwerkstack (Kernelmode)...16 Abbildung 3.3 Ablauf eines Netzwerkzugriffes Abbildung 4.1 Application Layer Active Network Systemarchitektur für Windows (Überblick) Abbildung 4.2 Socketadressstruktur TCP/IPv Abbildung 4.3 Socketadressstruktur TCP/IPv Abbildung 4.4 Initialisieren des Netzwerkstabels Abbildung 4.5 Laufzeitstruktur Monitor DLL...30 Abbildung 4.6 Anlegen eines Socket Abbildung 4.7 Ablaufdiagramm Bind und Connect...34 Abbildung 4.8 Annahme einer Verbindung...36 Abbildung 4.9 Berechnung Rate mit eine Anwendung versucht zu senden Abbildung 4.10 Daten senden (Teil 1) Abbildung 4.11 Daten senden (Teil 2) Abbildung 4.12 WSABUF-Struktur Abbildung 4.13 Befehle Nulladress-Maschine...43 Abbildung 4.14 Zusatzbefehle NAMH Abbildung 4.15 Paketformat NAMH Abbildung 6.1 Die TCP/IP Protokollfamilie... 67

5 5 Tabellenverzeichnis Tabelle 2.1 Active Network Systeme und ihre Execution Enviroments Tabelle 3.1 Zusammenfassung Netzwerkbestandteile...19 Tabelle 4.1 Dateinamen Tabelle 4.2 Protokolle und Ports... 33

6 1 Einleitung 6 1 Einleitung Derzeitige Netzwerkumgebungen transportieren rein passiv, ihnen übergebenen Daten. Dies bedeutet insbesone das keinerlei Anpassung des Datenvolumens an zur Verfügung stehende Bandbreite erfolgt. Im Gegensatz dazu bieten Application Layer Active Networks 1(ALAN) se Möglichkeit. Multimedia Dienste, welche ihre Daten für Clients mit verschiedenen Bandbreiten (insbesone auch an Clients mit relativ geringen Bandbreiten, wie z.b. Multimedia-Mobiltelefone) anbieten, müssen bei den herkömmlichen passiven Netzwerkumgebungen für jede zur Verfügung stehende Bandbreite angepasst werden. Der Ansatz Active Networks stellt eine dynamische Anpassung Daten durch das Netzwerk dar. Bei ALAN werden Daten auf dem Client an Netzwerkverbindung angepasst. Hierbei ist es erforlich Kontrolle über alle ausgehenden Netzwerkpakete zu erlangen um ein Ressource-Management und damit auch eine effektive Ausnutzung zur Verfügung stehenden Bandbreite des Systems zu handhaben. In ser Arbeit soll Zugriff auf Netzwerkschnittstelle art modifiziert werden, so dass durch ein Management-System Netzwerkpakete modifiziert und koordiniert werden können. Das Betriebssystem Microsoft Windows stellt für den Zugriff auf Netzwerkschnittstelle bereits verschiedene Schnittstellen bereit. Dabei stellt jede Schnittstellen des Betriebssystems eine ane Teilaufgabe innerhalb Ansteuerung Netzwerkschnittstelle dar. Das Kapitel 2 wird nach kurzem Vergleich herkömmlicher Netzwerkumgebungen gegenüber Active Networks auf bestehende Active Network Lösungen eingehen. Kapitel 3 wird neben Darstellung des bestehenden Netzwerkstabels von Windows, analysieren welche Modifikationsmöglichkeiten bestehen um Active Network Funktionalität in den Windows-Netzwerkstabel einzubrigen. Insbesone welche Komponenten hierzu modifiziert werden müssen. Schließlich erfolgt in Kapitel 4 Vorstellung meines Gesamtkonzeptes einer Application Layer Active Network Systemarchitektur für Windows. Zuletzt enthält Kapitel 5 eine kurze Zusammenfassung ser Arbeit. Dabei wird se Arbeit primär nur auf Version Windows 2000 und Windows XP des Windows Betriebssystems eingehen. Eine Betrachtung älterer Versionen wird nur am Rande erfolgen. 1 Application Layer Active Networks: aktive Netzwerke auf Anwendungsebene

7 2 Active Network Eigenschaften und Überblick 7 2 Active Network Eigenschaften und Überblick Dieses Kapitel stellt wesentlichen Unterschiede zwischen einer herkömmlichen passiven Netzwerkumgebung und einem Active Network dar, bevor es auf bestehende Active 2.1 Network Lösungen Vergleich Active herkömmlichen eingehen Networks passiven wird. gegenüber Netzwerkumgebungen Herkömmliche Netzwerkumgebungen transportieren Daten ohne sie an zur Verfügung stehende Bandbreite anzupassen. Insbesone ist es mit einem rein passiven Netzwerk nicht möglich Multimediadaten an Endgeräte mit geringer Bandbreite anzupassen. Active Networks erlauben ein benutzerspezifische Transcorung Daten und damit eine Anpassung an zur Verfügung stehende Bandbreite. Dies ist insbesone bei mobilen Endgeräten notwendig und sinnvoll. Abbildung 2.1 Überblick Active Networks (aus [BU01] S.2) Zusätzlich erlaubt ein Active Network eine reduzierte Entwicklungszeit für neue Netzwerkprotokolle, da Geräte Code zusammen mit den Daten erhalten und Daten mit Hilfe ses Codes verarbeiten können. Außerdem ist ein adaptives Überwachen und vorausschauendes Kontrollieren möglich ([BU01] S.2) Siehe auch Abbildung 2.1.

8 2 Active Network Eigenschaften und Überblick 8 Abbildung 2.2 Möglichkeiten eines Active Network (aus [BU01] S. 21) Weitere Vorteile eines Active Network Als weitere Vorteile eines Active Networks gelten Möglichkeit ein innovatives Sicherheitsmodel zu implementieren, ein virtuelles privates Netzwerk (VPN) abzusichern und Möglichkeit Netzwerkkomponenten aus Ferne zu aktualisieren und auch bei Ausfällen se aus Ferne zu diagnostizieren und zu reparieren ([BU01] S.21). Siehe 2.2 auch Das Active Abbildung Network 2.2. Encapsulation Protocol (ANEP) Das Active Network Encapsulation Protocol (ANEP) ist ein experimentelles Protokoll für Übertragung von Active Network Informationen über verschiedene Transportmen. ANEP erlaubt dabei sowohl Übertragung über bestehende Infrastruktur mittels IPv4 o IPv6 als auch Übertragung über den Link-Layer. Der verwendete Mechanismus ist dabei so weit wie möglich erweiterbar ausgelegt. Auch erlaubt ser Mechanismus Verwendung mehrerer sogenannter Execution Enviroments unabhängig voneinan. Execution Enviroment nennt man dabei Ausführungsumgebungen innerhalb des Betriebsystems eines Active Network Netzknotens. Ein solcher Netzknoten ist in Lage dynamisch Programme nachzuladen und auszuführen. Diese Programme nennt man Active Applications. (siehe [BU01] S.12 bzw. Abbildung 2.3)

9 2 Active Network Eigenschaften und Überblick 9 Abbildung 2.3 NodeOS (aus [BU01] S.12) Ein Active Network Packethea erlaubt dabei schnelle Auswahl einer geeigneten Umgebung zur Auswertung des Active Network Datenpaketes, sowie das Festlegen einer voreingestellten In Aktion, [UP04] wenn ist Auswertungsumgebung folgen nicht Packethea verfügbar ist. beschrieben: Abbildung 2.4 Aufbau eines ANEP-Pakets (aus [UP04]) Dabei sind alle Heafel größer als ein Oktet (=1 Byte = 8 Bit) in Big-EndianNotation2 zu verstehen. Dies gilt ebenfalls für alle Option-Hea. Die Versionnummer des Heas ist zeit immer 1. Dieses Feld wird immer dann geänt, wenn sich Aufbau des ANEP-Heas änt. Im Feld Flags wird zeit nur das höchstwertige Bit benutzt. Dieses signalisiert was zu geschehen hat, wenn ein Netzknoten TypeID eines ANEP-Packetes nicht kennt. Ist ses Bit auf 0 gesetzt, so soll ses Packet über eine Standardroutingregel weitergegeben werden, ansonsten soll es verworfen werden. 2 Big-Endian: höherwertiges Byte zuerst, im Gegensatz zu Little-Endian, welches zuerst das niedrigstwertige Byte überträgt

10 2 Active Network Eigenschaften und Überblick 10 Das Feld ANEP Hea Length spezifiziert Länge des Hea in 32 Bit Worten. Dies bedeutet, wenn keine Optionen verwendet werden, einen Wert von 2. Die TypeID bestimmt Umgebung in ses Active Network Datenpacket ausgewertet werden soll (siehe [UP04]). Eine Liste aktuell zugewiesenen TypeIds findet sich im Anhang Untersuchung bestehen Active Network Systeme Bestehende Active Network Systeme enthalten intelligente Router, nicht nur Datenpakete weiterleiten, sonn enthaltenen Daten anpassen. Dies geschied mit Hilfe verschiedener Ansätze. Dieses Unterkapitel wird auf einige ser Ansätze kurz eingehen Magician Magician ist ein Active Network System, das in Java geschrieben ist (kompatibel mit JDK und höher) und ein Execution Enviroment bereitstellt um in Java vorliegende SmartPackets (=Active Network Datenpakete) auszuführen (siehe [MA01]). Ein Magician SmartPacket liegt dabei in einem genau definierten Format vor (siehe Abbildung 2.5). Magician benutzt zur Übertragung Java Klassendefinitionen und Objekten, aus denen Active Network Datenpaket bei Magician bestehen, über das Netzwerk das ANEPFormat (siehe Kapitel 2.2). Das Feld Class Defintion TLV (siehe Abbildung 2.5) wird dabei dafür benutzt Klassendefinitionen zu übertragen, welche zur Rekonstruktuion des als Bytestrom im Feld Object Defintion TLV übertragenen Java Objekt nt. Jedes SmartPacket enthält mit dem Feld Type Identifier TLV eine eindeutige Nummer mit Hilfe ses SmartPackets übertragenen Active Application. Eine Komponente eines Magician-Netzknotens ist dabei ein sogenannter Routing Manager ein RIP ähnliches Routingprotokoll welches über das Senden von in SmartPackets enthaltenem Code Einträge in Routingtabellen änn, löschen o ergänzt. Dabei unterstützt ser Routing Manager auch eine Standardroutingregel für alle SmartPackets. Diese sucht den Weg mit den geringsten Kosten. Ein SmartPacket kann sen Standardmechanismus durch Implementierung eines eigenen Routingmechanismus überschreiben (siehe auch [BU00]). Magician überträgt Code und Daten im selben Active Network Paket (Capsule, siehe [BU01] S.13)

11 2 Active Network Eigenschaften und Überblick 11 Abbildung 2.5 Magician SmartPacket (aus [BU00] S.4) ANTS ANTS (Active Network Transport System; siehe [AN03]) ist ebenfalls ein Java basiertes Active Network System, welches ebenfalls Code und Daten im selben Paket überträgt. Dabei wurde ANTS auch für asymetrisches und dynamisches Routing entwicklet. Asymetrisches Routing bedeutet das Weg von Quelle zum Ziel eines Pakets nicht selbe ist, wie zwischen dem Ziel und Quelle. Damit ist also Hin- und Rückweg einer Verbindung verschieden (siehe [WE99] S.85). Bei Entwicklung von ANTS wird dabei auch berücksichtigt, das Daten eventuel von mehr als einem Empfänger benötigt werden. Dies wird in TCP/IP- Protokollfamilie(siehe Anhang 2) durch das Verfahren Multicast erledigt (siehe [WE99] S.85). ANTS kann dabei auch noch erweitert werden. Dies zeigt sich auch daran, das das aktuelle ANTS Versionnummer 2.0 hat (1.0 gab es auch, hatte aber kaum etwas mit dem heutigen ANTS 2.0 gemeinsam). Mögliche Erweiterungen sind auch ab Seite 101 von [WE99] erläutert.

12 2 Active Network Eigenschaften und Überblick Switchware Switchware ist ein hybrides Active Network System (siehe [BU01] S.13). Dies bedeutet das Code und Daten sowohl getrennt als auch gemeinsam übertragen werden können. Bei Entwicklung von Switchware wurde auch darauf geachtet, das Active Applications möglichst leichtgewichtig sind. Dies ist notwendig, da in Active Networks auch zeitkritischste Teil des Netzwerkes, Datenübertragung selbst, durch Software geschied. Eben durch Active Applications. Switchware implementiert dabei nicht nur normale Active Network Datenpakete sonn auch sogenannte Active Extentions, welche neue Protokolle o Funktionen implementieren können. Diese Active Extentions können dabei auf Router geladen werden und stellen neuen Funktionen dann für sehr viele Active Network Datenpackete bereit (siehe [AL98]) Netscript Netscript übertragt in seinen Active Network Datenpacketen nur Daten (Discrete, siehe [BU01] S.13 bzw. [SI01]). Dabei implementiert Netscript eine spezielle Programmiersprache zum Programmieren von Datenflußsteuerungen für Active Networks welche auf den Active Network Routern ausgeführt wird. Netscript-Programme führen dabei einfache Modifikationen an Datenpacketströmen durch. Dazu gehören z.b. Analyse und Klassifikation von Datenströmen, Datenströmen Analyse von und Pakethean, Multiplexen Routing (siehe und Demultiplexen von [SI01]). Netscript-Programme können dabei sowohl traditionelle Protokolle wie IP bzw. UDP als auch komplett neue Protokolle implementieren. Der Datenfluß innerhalb eines NetscriptRouters ist dabei durch Boxen mit verschiedener Funktion gegliet (siehe [SI01] S.540 Abbildung 2.6 Netscript Box-Struktur (Beispiel) bzw. Abbildung 2.6).

13 2 Active Network Eigenschaften und Überblick 13 (aus [SI01] S.540) Zusammenfassung und Übersicht weiterer Active Network Systeme Das Active Network System SmartPackets BBN ist ein Verfahren das wie Magician und ANTS Code und Daten innerhalb selben Pakete überträgt. Auch CANeS ist ein Tabelle 2.1 Active Network Systeme und ihre Execution Enviroments solches System (siehe Tabelle (aus 2.1). [BU01] S.13) Zusamengefasst ist zu sagen, das alle bisherigen Active Network Systeme für Router verschiedene Aspekte und Ansätze für Active Networks ausprobieren. Dabei werden auch verschiedene Ideen bezüglich Verteilung des Codes umgesetzt. Einige ser Systeme setzen auf Code und Daten in den gleichen Netzwerkpaketen, welches vorallem Vorteile bei relativ kleinen Codestücken hat, welche dann sehr flexibel einsetzbar sind. Ane Systeme setzen auf getrennte Verteilung von Code und Daten. Diese Systeme können sich dabei eine aufwendigere Sicherheitsstruktur leisten, ohne mit Problemen bei Leistungsfähigkeit des Netzes zu kämpfen. Nachteilig ist bei gleichzeitiger Verteilung von Code und Daten, das aufwendigere Codestücke zuviel Platz verbrauchen würden, bei getrennter Verteilung von Code und Daten leidet dagegen Flexibilität, da zu jedem Datenpacket immer auch ein dafür geeignetes Stück Active Network Code vorhanden sein muß. Dies kann bei getrennter Verteilung von Code und Daten nicht für jedes Datenpaket unterschiedlich gewählt werden. Es sind somit Systeme vorteilhaft beide Ansätze in sich vereinen, in dem sie sowohl Code und Daten getrennt, als auch gemeinsam übertragen können. Diese Systeme nennt man hybride Active Network Systeme.

14 2 Active Network Eigenschaften und Überblick 14 3 Zugriffsmöglichkeiten auf Netzwerkkarte unter Microsoft Windows Dieses Kapitel beschreibt den Aufbau des Netzwerkstabels von Windows, sowie welche Komponenten daraus sich modifizieren lassen um Active Network Funktionalität bereitzustellen. Außerdem beschreibt es den Ablauf eines Netzwerkzugriffes durch eine Netzwerkanwendung mit anschließen Betrachtung daraus ergebenen Konsequenzen auf tieferen Softwareebenen. Diese unterteilen sich in Usermode3 und Kernelmode4 auf daher auch in den einleitenden Unterkapiteln den Aufbau beschreiben 3.1 getrennt eingegangen Netzwerk-Bestandteile des wird. Usermode Der Usermode besteht bezüglich Netzwerkzugriffen aus dem Winsock API, das sich wie folgt zusammensetzt (siehe auch Abbildung 3.1): 16 Bit Winsock-Anwendungen greifen über das Windows Sockets 1.1 API auf Winsock.dll zu. 32 Bit Winsock-Anwendungen greifen entwe über das Windows Sockets 2.0 API auf Ws2_32.dll, Mswsock.dll und Wshelp.dll zu, o über das Windows Sockets 1.1 API auf Wsock32.dll zu. Die Wsock.dll und Wsock32.dll sind dabei nur zwecks Kompatibilität zu alten Anwendungen vorhanden, da sie letztendlich nur das Windows Sockets 2.0 API in das Windows Sockets 1.1 API wandeln. Die Ws2_32.dll greift über das Windows Sockets 2.0 Service Provi Interface auf Layered Service Provi bzw. wenn keine Layered Service Provi vorhanden sind direkt auf Base Service Provi. Diese unterteilen sich in Helper DLLs und Name Space DLLs. Dies ist allerdings für se Arbeit weitgehend unwichtig. Ebenso wie sie oben genannten verschiedenen Varianten Winsock-DLL. Sie werden hier nur Vollständigkeit halber genannt und um klarzustellen das in ser Arbeit vorgestellte Application Layer Active Network Lösung unabhängig von Art Anwendung ist, Windows Sockets Schnittstellen benutzt. Daher wird im gesamten weiteren Text ser Arbeit immer nur von Winsock DLL Rede sein. Gemeint ist dabei immer hier genannten Bibliotheken als Ganzes. 3 Usermode: Privilegebene Anwendungen bei den meisten monen Betriebssystemen. 4 Kernelmode: Privilegebene des Betriebssystems selbst. Nur in sem Modus/Privilegebene ist ein direkter Hardwarezugriff machbar.

15 3 Zugriffsmöglichkeiten auf Netzwerkkarte unter Microsoft Windows 15 Wichtig ist allerdings das Layered Service Provi auf ane Layered Service Provi o den Base Service Provin aufsetzen können und damit erlauben den Zugriff auf Base Service Provi abzufangen und zu modifizieren. Mit Hilfe Msafd.dll greifen Helper DLLs auf im Kernelmode vorhandenen Transportprotokolle zu ( [JO02], [MI02], [ND04] ). Abbildung 3.1 Windows Netzwerkstack (Usermode) (aus: [ND04] ) 3.2 Netzwerk-Bestandteile des Kernel-Mode Der Kernelmode besteht bezüglich Netzwerkzugriffen aus dem NDIS Interface (siehe Abbildung 3.2): Ein NDIS-Miniport-Treiber steuert direkt Hardware Netzwerkkarte an. NDIS Intermediate Treiber können sich zwischen Miniport Treiber und Protokoll Treibern befinden. Sie lassen sich für verschiedene Zwecke einsetzen. Diese sind Datenfilterung aus Sicherheitsgründen o anen Zwecken, Load Bancing, Erhöhung o Realisierung von Ausfallsicherheit, Überwachung und Sammlung von Daten zur Erstellung von Statistiken über Netzwerkzugriffe, sowie Anpassungen eines veralteten Protokoll/Transporttreibers an einen aktuellen Miniporttreiber. Ein NDIS Protokoll-Treiber stellt oberste Treiberebene im Kernelmode dar ([JO02], [MI02] ).

16 3 Zugriffsmöglichkeiten auf Netzwerkkarte unter Microsoft Windows 16 Weitere Arten von Treibern des Kernelmode sind Firewall-Hook-Treiber (oft als NDIS Intermediate Treiber realisiert( [MI02] )) sowie Filter-Hook-Driver von denen nur genau einer installiert werden kann und nur Entscheidung darüber realisiert werden kann, ob ein IP-Paket weitergeleitet,weggeworfen, o durchgelassen wird ohne Möglichkeit einer Manipulation. Tiefere Einblicke in den Kernelmode wie sie teilweise in Abbildung 3.2 gezeigt werden, sind für se Arbeit nicht relevant und werden daher nicht weiter erläutert. Abbildung 3.2 Windows Netzwerkstack (Kernelmode) (aus [ND04] )

17 3 Zugriffsmöglichkeiten auf Netzwerkkarte unter Microsoft Windows 3.3 Eignung für Active 17 Network Zwecke Wie zum Teil bei Vorstellung verschiedenen Treiberarten in Kapitel 3.1 und 3.2 anklang, eignen sich verschiedene Treiber unterschiedlich gut für Beeinflussung zu sendenden Daten nach Active Network Gesichtspunkten. Daher folgt jetzt eine systematische Bewertung entsprechenden Bestandteile. Winsock-DLL (siehe Kapitel 3.1) Als fester Bestandteil des Windows-Netzwerkstabels lässt sich Winsock-DLL nicht dazu verwenden, Active Network Layered Datenbeeinflußung zu Service (siehe realisieren. Provi Kapitel 3.1) Diese Treiberart eignet sich hervorragend dazu Zugriffe auf den Base Provi abzufangen o zu beeinflussen. Und damit ist s auch eine möglichen Teile des Netzwerkstabels von Windows um Active Network Datenbeeinflußung zu realisieren. Insbesone da noch keinerlei Protokollhea an Daten angefügt wurden, nach Modifikation Daten neu erzeugt Base wedren müssten. Provi (siehe Kapitel 3.1) Diese Komponente ist wieum fester Bestandteil des Netzwerkstabels von Windows. Er ist allerdings abhängig vom darunterliegenden Transportprotokolltreibers im Kernelmodus. Benutzt man einen anen Transportprotokolltreiber so kann man auch einen neuen Base Provi benutzen. Transportprotokolle (siehe Kapitel 3.2) Diese sind im allgemeinen zu komplex um sie extra für Active Network Belange neu zu schreiben. Zumal ein Eingriff an ser Stelle auch bedeutet das man Kontrolle über den gesamten Datenverkehr verliert, da Verkehr über ein anes bzw. über das herkömmliche Transportprotokoll abgewickelt wird, nicht durch das neu geschriebene Protokoll erfasst werden kann.

18 3 Zugriffsmöglichkeiten auf Netzwerkkarte unter Microsoft Windows 18 Intermediate Treiber (siehe Kapitel 3.2) Da sich se Treiber genau zwischen Transportprotokolltreiber und NDIS Miniporttreiber befinden, eignen sie sich sehr gut dazu fertige Pakete zu filtern (durchlassen, weiterleiten o wegwerfen) bevor sie mit Hilfe des Miniporttreibers auf Reise gehen bzw. nachdem sie mit Hilfe des Miniporttreibers empfangen wurden. Eine Veränung enthaltenen Daten ist allerdings nicht mehr so einfach möglich, da bereits fast alle Protokollhea (Ausnahme ist z.b. Ethernethea wenn Ethernet als Hardwareebene verwendet wird. Bei Verwendung von anen Hardwareprotokollen gilt Entsprechendes) angefügt sind und daher nach einer Modifikatiuon Daten agepasst werden müssten. Außerdem erlaubt ein solcher Treiber es den Funktionsumfang eines Miniporttreibers zu erweitern. NDIS Miniporttreiber (siehe Kapitel 3.2) Mit Hilfe ses Treibers werden fertigen Datenpakete über eine Netzwerkkarte gesendet bzw. empfangen. Da ser Treiber direkt für Ansteuerung Hardware verantwortlich ist, ist er ebenfalls abhängig von verwendeten Netzwerkkarte. Er ist daher nicht geeignet Active Network Datenbeeinflußung zu realisieren. NDIS Miniporttreiber werden in Regel nur von Hardwareherstellern (also dem Hersteller Netzwerkkarte geschrieben um Netzwerkkarte auch tatsächlich ansteuern zu können). Firewall-Hook (siehe Drivers Kapitel 3.2) Wie schon in Kapitel 3.2 geschilt handelt es sich hierbei oft nicht um eine eigne Treiberart, sonn nur um eine spezielle Verwendung des Intermediate Treibers. Filter-Hook (siehe Driver Kapitel 3.2) Auch se Treiberart unterstützt keine Datenbeeinflußung. Sonn erlaubt es nur Netzwerkpakete abzulehnen, durchzulassen o weiterzuleiten. Und ist damit als Active Network Treiber ungeeignet.

19 3 Zugriffsmöglichkeiten auf Netzwerkkarte unter Microsoft Windows 19 Damit ist nur ein Layered Service Provi o ein Intermediate Treiber überhaupt geeignet Active Network Funktionalität zu realisieren. Da es ein Layered Service Provi einfacher erlaubt se Möglichkeiten zu realisieren, wird auch genau ser dazu verwendet Active Network Funktionalität in Kapitel 4 zu implementieren. Insbesone da bei Verwendung eines Layered Service Provi nach Modifikation Daten keine Hea zusätzlich angepasst werden müssen. Die nachfolgende Tabelle (Tabelle 3.1) fasst ersten 3 Unterkapitel von Kapitel 3 zusammen Usermode um se Winsock-DLL Entscheidung - Bereitstellung von Sockets für Anw endungen Layered Provi - Beeinflußung und Abfangen noch zu verdeutlichen: Ungeeignet, da fester Bestandteil des Window s-netzstapels Geeignet von Anfragen an den Base Provi Base Provi - Weiterleitung von Anfragen an im Kernelmode befindliche Ungeeignet, da fester Bestandteil des Window s-netzstapels Transportprotokole Kernelmode Transportprotokole - Transportprotokole Intermediate Treiber - z.b. Filterung von fertig aufgebauten (stellen Netzw erkpakete zusammen) Netzw erkpaketen Miniport Treiber - Ansteuerung Netzw erkkarte Firewall-Hook Paketfilterung Filter-Hook Paketfilterung Ungeeignet, da fester Bestandteil des Window s-netzstapels Bedingt geeignet, da Netzw erkpakete ausgepackt bzw. eingepackt w erden müssten Ungeeignet, da genaue Funktion abhängig von Hardw are Netzw erkkarte -/- Ungeeignet, da nur begrenzte Funktionalität möglich Tabelle 3.1 Zusammenfassung Netzwerkbestandteile

20 3 Zugriffsmöglichkeiten auf Netzwerkkarte unter Microsoft Windows 3.4 Ablauf eines 20 Netzwerkzugriffes Eine Netzwerkanwendung muß mehrere wichtige Software-Schritte durchführen um tatsächlich auf das Netzwerk zuzugreifen. Abbildung 3.3 zeigt alle wesendlichen Schritte zusammenfassend auf ich in den nachfolgenden Unterkapiteln näher eingehen werde. Abbildung 3.3 Ablauf eines Netzwerkzugriffes

21 3 Zugriffsmöglichkeiten auf Netzwerkkarte unter Microsoft Windows Netzwerkzugriff vorbereiten Um einen Netzwerkzugriff durchzuführen muß eine Anwendung zuerst FunktionsBibliothek für Netzwerkzugriffe öffnen und initialieren. (Diese Bibliothek ist Winsock DLL und sie wird mit dem Aufruf Funktion WSAStartup(), welche in Winsock DLL enthalten ist für Benutzung vorbereitet). Anschließend muß für jede aufzubauende Verbindung ein Handle (Socket) angelegt werden. (Dies geschied über eine Funktionen socket() o WSASocket() Winsock Die DLL). weiteren Schritte hängen davon ab, ob ein verbindungsorientierter o verbindungsloser Netzwerkzugriff erfolgen soll. Bei einem verbindungsorientiertem Netzwerkzugriff unterscheidet man zwischen Client und Server (Ein Client verbindet sich zu einem Server, welcher ständig auf eingehende Anfragen wartet), während bei verbindungslosen Netzwerkzugriffen zwischen Sen und Empfänger unterschieden werden muß. Je ser Zugriffsarten bedingt unterschiedliche Software-Schritte Die Netzwerkzugriff für einen eines Server Server (verbindungsorientiert) notwendigen Schritte sind: Eine Serveranwendung muß für ihren Netzwerkzugriff den angelegten Handle (Socket) an eine Netzwerkadresse binden. (Dies geschied mit Funktion bind() aus Winsock DLL und bei TCP/IP (beide Versionen) ist damit sogenannte IP-Adresse gemeint). Anschließend den an eine Adresse gebundenen Handle in den Horchstatus bringen. (Dies geschied mit Funktion listen() ). Dann kann Serveranwendung auf eintreffende Verbindungswünsche warten und se dann annehmen. (Dies geschied mit Funktion accept() und je Aufruf nimmt eine Verbindung an. Während eine Verbindung besteht, können auch weitere Verbindungen angenommen werden und se nachdem sie angenommen wurden auch zur Datenübertragung genutzt werden. Dabei wird für jede angenommene Verbindung ein eignes Handle (Socket) automatisch angelegt. Aufgebaute Verbindungen können zum Daten senden und empfangen benutzt werden. (Daten werden mit send() gesendet und mit received() empfangen).

22 3 Zugriffsmöglichkeiten auf Netzwerkkarte unter Microsoft Windows 22 Wird eine Verbindung nicht mehr zur Datenübertragung benötigt, so wird sie beendet(hierfür gibt es mehr als eine Möglichkeit. Entwe senddisconnect() welches ein letztes Mal Daten WSACloseSocket() sendet und anschließend welches des Verbindung Handle beendet direkt o schließt.). Soll Serveranwendung beendet werden, o vorübergehend keine Anfragen beantworten so ist an Netzwerkadresse gebundenen Handle freizugeben. (Die Funktion WSAShutdown() Winsock DLL wird hierzu verwendet). Wird Funktion Winsock DLL endgültig nicht mehr benötigt so muß sie nach Benutzung aufgeräumt werden. (Die Funktion WSACleanup() führt s durch.) Netzwerkzugriff eines Client (verbindungsorientierent) Die für einen Client notwendigen Schritte sind dagegen nicht ganz so umfangreich. Ein Client muß für seinen Netzwerkzugriff mit Hilfe des angelegten Handle eine Verbindung zu einem Server aufbauen. (Die Funktion connect() Winsock DLL erledigt s). Danach kann er Daten senden und empfangen (Daten werden mit send() gesendet und mit received() empfangen). Das Beenden Verbindung und Aufräumen Winsock DLL geschied auf gleiche Weise wie bereits beim Netzwerkzugriff eines Servers beschrieben Netzwerkzugriff eines Sen (verbindungslos) Der Ablauf des verbindungslosen Sendes ist sehr einfach, da nach Anlegen des Handle (Socket) Daten mit sendto() direkt losgesendet werden können. Nach Benutzung muß das Handle dann nur noch freigeben werden. (Die Funktion WSAShutdown() Winsock DLL wird dazu auch bei verbindungslosen Netzwerkzugriffen benutzt). Auch nach verbindungslosem Netzwerkzugriff muß Winsock DLL nach Benutzung aufgeräumt werden. (Die Funktion WSACleanup() führt s durch.)

23 3 Zugriffsmöglichkeiten auf Netzwerkkarte unter Microsoft Windows Netzwerkzugriff eines Empfänger 23 (verbindungslos) Um verbindungslose Netzwerkzugriffe anzunehmen sind auch nur wenige Schritte notwendig. Die Netzwerkanwendung s durchführen will muß dazu einfach nur den angelegten Handle (Socket) an eine Netzwerkadresse binden. (Wie beim verbindungsorientierenten Server ist hierzu Funktion bind() aufzurufen). Danach kann sie schon Daten mit recvfrom() empfangen. Soll se Netzwerkanwendung beendet werden, so ist Handle nach Benutzung freizugeben. (Die Funktion WSAShutdown() Winsock DLL wird dazu auch bei verbindungslosen Netzwerkzugriffen benutzt). Und zuletzt ist wie immer Winsock DLL nach Benutzung aufzuräumen. (Die Funktion WSACleanup() führt s durch.)

24 3 Zugriffsmöglichkeiten auf Netzwerkkarte unter Microsoft Windows 24 4 Application Layer Active Network Systemarchitektur für Windows Dieses Kapitel beschreibt, erläutert und dokumentiert von mir realisierte Application Layer Active Network Systemarchitektur für Windows wie sie Abbildung 4.1 zeigt. 4.1 Die Anforungen neuen an Komponenten Active (fettgedruckte Network Beschriftung Systemarchitektur in Abbildung 4.1) des Netzwerkstabels müssen in Lage sein, abhängig von zur Verfügung stehenden Bandbreite, zu sendenen Daten so anzupassen, das ein mit geringer Bandbreite angebundenener Empfänger Multimediadaten weiterhin in Echtzeit erhalten kann. Dabei Abgriff ergeben Daten sich innerhalb folgene des Teilprobleme: Netzwerkstabels von Windows Um durch den Netzwerkstabel durchfließenden Daten abzugreifen, bevor sie an Netzwerkkarte gelangen, bietet sich wie bereits in Kapitel 3 geschilt, Treiberart Layered Service Provi an. Diese erlaubt allerdings nur eine genau festgelegte Aufrufschnittstelle (Windows Sockets 2.0 SPI) welche nicht erweiterbar ist. Transportprotokollabhängigkeit Datenstrukturen innerhalb des Netzwerkstabels Einige Datenstrukturen Winsock 2.0 API/SPI sind abhängig vom verwendeten Transportprotokoll. Diese Strukturen enthalten Informationen darüber welches Protokoll auf Anwendungsebene verwendet Anwendungsabhängige Jede Anwendung kann wird. Daten unterschiedliche Daten über unterschiedliche Anwendungsprotokolle senden. Dies muß bei Modifikation Daten berücksichtigt werden können. Datenvielfalt einer Anwendung Eine einzige Anwendung kann mit Hilfe eines einzigen Anwendungsprotokolls viele verschiedene Daten senden. Diese Systemarchitektur muß also in Lage sein, auf sich auf tatsächlich gesendeten Daten anzupassen.

25 25 Erweiterbarkeit Neuere Protokolle und Datentypen müssen einfach nachträglich implementierbar sein. 4.2 Überblick über verschiedenen Komponenten Abbildung 4.1 Application Layer Active Network Systemarchitektur für Windows (Überblick) Application (Anwendung) Sie braucht für den Zugriff auf neue Systemarchitektur nicht extra angepasst werden, da Schnittstelle zum System weiterhin das Windows Sockets API darstellt. Allerdings ist Verwendung eines gut für Modifikation geeigneten Datenformats vorteilhaft. So stellen verschlüsselte Daten ein Problem dar, se nicht analysierbar sind. Winsock DLL Die Winsock DLLs bleiben genauso erhalten, wie sie in aktuellen Windows Versionen enthalten Layered sind. Service Provi (kurz auch: LSP) LSPs können weiterhin in beliebiger Reihenfolge installiert werden, wie s in einer normalen Windows Installation Fall ist. Einer ser LSPs ist dann Application Layer Active Network Layered Service Provi.

26 Application Layer Active Network Layered 26 Service Provi Dieser LSP stellt Verbindung zwischen dem normalen Netzwerkstabel von Windows und den neu programmierten Komponenten Active Network Systemarchitektur für Windows dar. Als Dateiname habe ich ALAN_LSP.dll ausgewählt. Wie alle anen LSPs bietet er das Windows Sockets Service Provi Interface 2.0 an drüber liegenden Softwareebene (Winsock DLL o aner LSP) an und erwartet dasselbe Interface von darunter liegenden Softwareebene. Als Bindeglied zur den anen Komponenten Active Network Systemarchitektur greift er über das Application Layer Active Network Monitor API auf Application Layer Active Network Monitor DLL zu um durchlaufenden Daten durch anen Teile Systemarchitektur Application durchzuleiten. Layer Active Network Monitor DLL Dies stellt zentrale Komponente hier vorgestellten neuen Systemarchitektur dar. Er hat den Dateinamen ALAN_MON.dll. Alle Daten kommen erstmal hier an und werden von hier aus durch weitere Teile Systemarchitektur geleitet. Auch Entscheidungen darüber welche Teile s sind werden hier getroffen. Als dauerhafte Ablage für Konfigurationseinstellungen nt dabei Windows Registery. Um protokollabhängige Entscheidungen treffen zu können greift Application Layer Active Network Monitor DLL auf Application Layer Active Network Active Protokoll Helper zu. Die tatsächlichen Datenmodifikationen Application werden Layer durch Active Execution Network Enviroments Active durchgeführt. Protokoll Helper Diese DLLs helfen Application Layer Active Network Monitor DLL dabei das korrekte Execution Enviroment auszuwählen. Dies geschied in Form, das aus von Anwendung übermittelten Socketadressstruktur Teil ausgelesen wird auf das jeweilige Protokoll Anwendungsebene hindeutet. Bei TCP/IP ist s sowohl bei Version 4 (Dateiname des Helpers atcpip4.dll), als auch bei Version 6 (atcpip6.dll) sogenannte Portnummer (z.b. HTTP verwendet normalerweise Port 80). Die Socketadressstruktur (siehe auch Abbildung 4.2 und 4.3) ist jeweils abhängig davon welches Protokoll verwendet wird und daher ist für jedes Protokoll ein eigner Helper vorgesehen.

27 struct sockaddr_in { short sin_family; u_short sin_port; struct in_addr sin_addr; char sin_zero[8]; }; Abbildung 4.3 Socketadressstruktur TCP/IPv6 Abbildung 4.2 Socketadressstruktur TCP/IPv4 Application Layer 27 struct sockaddr_in6 { short sin6_family; u_short sin6_port; u_long sin6_flowinfo; struct in6_addr sin6_addr; u_long sin6_scope_id; }; Active Network Execution Enviroment Die Execution Enviroments führen tatsächliche Modifikation Daten durch. Sie können dabei mit Hilfe Monitor DLL auch weitere Execution Enviroments aufrufen. Dies ermöglicht einen sehr modularen Aufbau, insbesone bei komplexeren erweiterbaren Protokollen vorteilhaft ist. Das Execution Enviroment für ANEP (EE_ANEP.dll) demonstriert sen Aufbau. ANEP (Active Network Encaplulation Protokoll) ist ein Standardformat für Active Network Datenpakete. Wie das Paket zu interpretieren ist erst durch TYPE-Id feststellbar. Daher liest EE_ANEP.dll se TYPE-Id aus und ruft mit Hilfe Monitor DLL das für se TYPE-Id zuständige Execution Enviroment auf. Insgesamt ist allerdings zu sagen, genaue Funktion eines Execution Enviroments insgesamt beliebig ist. Fest ist nur Parameter des Aufrufs und Rückgabewerte an Monitor DLL. Möglich ist alles zwischen überhaupt keiner Funktion (EE_NOP.dll) und einer kompletten virtuellen Maschine (z.b. EE_NAMH.dll, eine Nulladressmaschine in Havardarchitektur realisiert). Base Service Provi Die Base Service Provi bleiben so erhalten wie sie bei einem aktuellen Windows ausgeliefert werden, da jegliche Funktion durch bereits genannten Komponenten realisiert 4.3 sind. Dateinamenskonventionen

28 28 Alle neuen Komponenten hier vorgestellten Systemarchitektur sind mit eindeutigen Dateinamen versehen: Der Application Layer Active Network Layered Service Provi heißt ALAN_LSP.dll. Die Application Layer Active Network Monitor DLL heißt ALAN_MON.dll. Die Application Layer Active Network Active Protokoll Helper haben Dateinamen mit einem a beginnen und danach den Protokollnamen enthalten (atcpip4.dll (für TCP/IPv4) und atcpip6.dll (für TCP/IPv6)). Application Layer Active Network Execution Enviroments haben Dateinamen aus dem Kürzel EE (für Execution Enviroment) einem Unterstrich _ und einem Kürzel für das Protokoll o Funktion des Execution Enviroment haben. So heißt das funktionslose Dummy-Execution Enviroment EE_NOP.dll (NOP für No Operation vgl. mit dem Prozessorbefehl gleichen Namens auch nichts weiter macht). Das Execution Enviroment für ANEP (Active Network Encaplulation Protokoll) heißt EE_ANEP.dll. Die virtuelle Nulladressmaschine mit Havardarchitektur dementsprechend EE_NAMH.dll. Weitere Dateinamen werden in ser Arbeit nicht verwendet da sie keine mit ser Arbeit fertiggestellten Module betreffen, da aber se Systemarchitektur modular aufgebaut ist, um leicht erweiterbar zu sein, sind weitere Dateinamen möglich. Insbesone sind weitere Protokoll Helper und Execution Enviroment möglich. Daher kann es keine endgültige Liste aller Dateinamen geben, wohl aber eine Liste aller verwendeten Dateinamen. Dies ist Tabelle 4.1. Layered Service Provi ALAN_LSP.dll Layered Service Provi für Application Layer Active Networks INSTLSP.exe Installationsprogramm für ALAN_LSP.dll Monitor ALAN_MON.dll Application Layer Active Network Monitor DLL MONTOR.exe Kleines Testprogramm das Datenzähler ausliest INSTALL.exe Installationsprogramm das Registeryeinträge ALAN_MON.dll für den Aufruf externer Module benötigt Active Protokol Helper atcpip4.dll Application Layer Active Network Active Protokoll Helper für TCP/IPv4 ATCPIP6.dll Application Layer Active Network Active Protokoll Helper für TCP/IPv6 Execution Enviroments EE_NOP.dll Execution Enviroment ohne Funktion außer das alle durchlaufenden Daten als modifiziert gelten EE_ANEP.dll Execution Enviroment für das Active Network Encaplulation Protokoll EE_NAMH.dll Virtuelle Nulladressmaschine Tabelle 4.1 Dateinamen 4.4 Zusammenarbeit aller Komponenten bei Netzwerkzugriffen

29 29 Alle se Komponenten arbeiten gemeinsam um gewünschte Funktionalität bereitzustellen. Wie sich se Zusammenarbeit darstellt findet sich in sem Unterkapitel Initialieren des Netzwerkstabels Benötigt eine Anwendung Netzwerkzugriff so öffnet sie Winsock DLL und initialiert se mit Hilfe Funktion WSAStartup selben DLL. Die Winsock DLL ladet automatisch jeweils benötigten Service Provi und initialiert se mit dem Aufruf ihrer Funktion WSPStartup(). Dies geschied auch beim Application Layer Active Network Layered Service Provi. Da Winsock DLL sen Aufruf durchaus mehrfach durchführen kann (für jede Anwendung einmal) muß ALAN_LSP auch erkennen, wie oft bereits seine Funktion WSPStartup() aufgerufen wurde (siehe Abbildung 4.4 ). Abbildung 4.4 Initialisieren des Netzwerkstabels Nur beim ersten Start darf er Aufräumfunktion CleanupEE() aus Monitor DLL aufrufen, da er sonst bestehende Netzwerk-Verbindungen stören würde. Ebenfalls nur beim ersten Aufruf darf Funktion ALANInit() Monitor DLL aufgerufen werden, da se ebenfalls ansonsten bestehende Netzwerk-Verbindungen stören würde.

30 30 Sie initialiert Laufzeitstruktur Monitor DLL (siehe Abbildung 4.5) in Verbindungsinformationen aller nach Active Network Gesichtspunkten beeinflußten Verbindungen gespeichert werden. Initialieren heißt hier das Speicher für Struktur geleert wird, um sicherzustellen das kein Datenmüll, von anen Anwendungen, sich in sem Speicher befindet, zu Fehlinterpretationen führen würde. // Laufzeitstruktur definieren typedef struct _active_network_handler { unsigned long bytes_in_send; // Statistik unsigned long bytes_out_send; unsigned long bytes_in_rec; unsigned long bytes_out_rec; unsigned long sendrate; // Letzte gemessene Senate unsigned long lastclock; // Zeit letzten Daten von Anwendung unsigned long lastsize; // Größe letzten Daten von Anwendung char ee_name[13]; // Name des Execution Enviroments char start; // Status 0=noch keine gültigen Informationen gespeichert // 1=ee_name enthält Protokolnummer+Sockettype // 2=ee_name enthät Name des zuständigen EE unsigned short id; // Verbindungs-ID aka Socket } active_network_handler; // Laufzeitstruktur anlegen active_network_handler active_network_handlers[65535]; Abbildung 4.5 Laufzeitstruktur Monitor DLL In ser Laufzeitstruktur werden neben Nummer des Sockets, Statusinformationen, Statistikinformationen vorallem auch Name des Execution Enviroments gespeichert. Außerdem Informationen über tatsächlich aufgetrettene Datenraten beim Senden, sowie Zeitpunkt und Größe des letzten Datenbuffers. Aus Sicherheitsgründen kann se Struktur nur über eine extra zu sem Zweck geschaffene Funktion durch eine Monitorapplication ausgelesen werden. Ein direkter Zugriff ist nicht möglich. Der Speicherbedarf Laufzeitstruktur, so wie sie von mir definiert wurde, beträgt für jeden möglichen Socket 44 Byte. Da 2^16-1 (65535) Sockets möglich sind, braucht se Struktur insgesamt Bytes (ca. 2,9 Mbyte). Nach Ende ser Initialierung Monitor DLL, und ab dem zweiten Aufruf sofort, übergibt Application Layer Active Network LSP weitere Arbeit an den darunter liegenden Service Provi (wie es je LSP nach getaner Aufgabe machen sollte) Anlegen eines Sockets

31 31 Um einen Socket anzulegen ruft eine Anwendung Funktion Socket() o WSASocket() Winsock DLL auf. Die Winsock DLL leitet sen Aufruf an Funktion WSPSocket(), des für das gewählte Netzwerkprotokoll zuständigen Service Provi, weiter. Der ALAN_LSP ruft, wenn er sen Aufruf erhält, Funktion NewID() Monitor DLL auf damit Monitor sen Socket als Verbindungsidentifikation speichern kann. Diese Speicherung erfolgt in Laufzeitstruktur Monitor DLL. Hierbei wird Teil des Verbindungseintrags benutzt später den Dateinamen des Execution Enviroments aufnimmt, da das Execution Enviroment zu sem Zeitpunkt noch nicht bestimmbar ist (dazu fehlt noch Nummer des Protokolls Anwendungsebene). Diese ist erst bestimmbar, wenn über sen Socket tatsächlich eine Verbindung aufgebaut wird. Beim Anlegen eines Socket ist nur Socket, Protokollfamilie, Sockettype (Stream o Datagramm) und Protokoll verfügbar (siehe auch Abbildung 4.6 ). Abbildung 4.6 Anlegen eines Socket Bei TCP/IP ist s:

32 Protokollfamilie: Sockettype: AF_INET (IPv4) AF_INET6 (IPv6) 32 o SOCK_STREAM (TCP) o SOCK_DGRAM (UDP) o (TCP) o SOCK_RAW (z.b. für ICMP) Protokoll: Um IPPROTO_TCP IPPROTO_UDP (UDP) IPPROTO_ICMP (ICMP) Binden den eines Socket an eine Sockets eindeutige an eine Netzwerkadresse Netzwerkadresse zu binden, ruft Netzwerkanwendung Funktion Bind() aus Winsock DLL auf. Diese leitet sen Aufruf an den zuständigen LSP weiter, indem sie Funktion WSPBind() aus sem aufruft. Ist s ALAN_LSP so ruft ser Funktion OpenID() aus Monitor DLL auf. Die Monitor DLL durchsucht daraufhin ihre Laufzeitstruktur nach den bei Anlegen des Sockets gespeicherten Informationen (siehe Kapitel 4.3.2) und sucht anschließend mit Hilfe ser Informationen in Windows Registery nach dem Dateinamen des Application Layer Active Network Active Protokoll Helpers in Lage ist Socketadressstruktur zu analysieren (siehe Abbildung 4.5 ). Wird kein passen Protokoll Helper gefunden, so werden alle in Laufzeitstruktur zu ser Verbindung gespeicherten Informationen verworfen, da eine Modifikation Daten bei Verwendung von auf Anwendungsebene unbekannten Protokollen nicht möglich ist. Wird dagegen ein passen Protokoll Helper gefunden, so wird sem Socketadressstruktur übergeben. Der Protokoll Helper sucht aus ser Struktur nun Nummer des auf Anwendungsebene verwendeten Protokolls heraus. Bei TCP/IP (sowohl bei Version 4 als auch bei Version 6) handelt es sich hierbei um Portnummer. Einige bekannte Protokolle Anwendungsebene und ihre TCPPortnummer finden sich in Tabelle 4.2. Mit dem Rückgabewert des Protokoll Helpers und den in Laufzeitstruktur hinterlegten Informationen sucht nun Monitor DLL das für se Verbindung zu verwendene Execution Enviroment. Findet Monitor DLL kein Execution Enviroment das für eingesetzen Protokolle

33 33 verwendbar ist, so werden alle Informationen in Laufzeitstruktur hinterlegt sind verworfen, anseits Laufzeitstruktur ftp-data ftp ssh telnet domain domain http pop3 nntp imap Imaps pop3s Active-net für wird 20/tcp 21/tcp 22/tcp 23/tcp 53/tcp 53/udp 80/tcp 110/tcp 119/tcp 143/tcp 993/tcp 995/tcp Dateiname weitere Execution Verwendung Enviroments in hinterlegt. File Transfer [Default Data] File Transfer [Control] SSH Remote Login Protocol Telnet Domain Name Server Domain Name Server World Wide Web HTTP Post Office Protocol - Version 3 Network News Transfer Protocol Internet Message Access Protocol imap4 protocol over TLS/SSL pop3 protocol over TLS/SSL (was spop3) Active Networks Tabelle 4.2 Protokolle und Ports (Auszüge aus [IA04] ) Die Arbeit Monitor DLL für sen Teilschritt ist damit beendet und Ausführung geht an den ALAN_LSP zurück, zuletzt noch Funktion WSPBind() des unter im liegenden Service Provi aufruft (siehe auch Abbildung 4.7 ) Aufnahme einer Verbindung durch einen Client Eine Netzwerkclient-Anwendung ruft um sich mit einem Server zu verbinden, Funktion connect() Winsock DLL auf. Die Winsock DLL leitet sen Aufruf an Funktion WSPConnect() des LSP weiter. Gelangt ser Aufruf an den ALAN_LSP so ruft ser Funktion OpenID() Monitor DLL auf. Die Monitor DLL sucht daraufhin in ihrer Laufzeitstruktur nach den beim Anlegen des Sockets (siehe Kapitel 4.3.2) hinterlegten Informationen und übergibt Socketadressstruktur ursprünglich Connect()Funktion Winsock DLL übergeben wurde, an den für das verwendete Protokoll geeigneten Protokol Helper. Die Bestimmung desselben geschied genauso wie im Kapitel bezüglich Serverzugriffe beschrieben. Der einzige Unterschied besteht darin, das Funktion bind() eigne Adresse inkl. Portnummer (bei TCP/IP) übergeben wird. connect() dagegen bekommt Adresse inkl. Portnummer (TCP/IP) des entfernten Servers zu dem Verbindung aufgebaut werden soll übergeben. Damit durchlaufen nur

34 Abbildung 4.7 Ablaufdiagramm Bind und Connect fest definierbare Adress-Informationen Monitor DLL und alle weiteren Komponenten 34

35 35 Application Layer Active Network Systemarchitektur für Windows. Insbesone bei Verwendung von TCP/IP wo Netzwerk-Clients dynamisch zugewiesene Portnummern einsetzen und nur Netzwerk-Serveranwendungen feste Portnummern verwenden. Die Monitor DLL sieht ausschließlich feste Portnummern Server. Daher reicht es bekannten Portnummern Server in Zweige Windows Registery einzutragen se Systemarchitektur zu Konfigurationszwecken einsetzt. Eine Konfigurationsänung ser Systemarchitektur ist bei Netzwerk-Clientanwendungen nicht notwendig. Für ane Protokolle als TCP/IP gilt das im letzen Abschnitt geschilte nicht direkt, aber entsprechend. Daher verzichte ich auf weiteres Eingehen auf ane Protokolle, zumal ich keine Protokoll Helper für ane Protokolle als TCP/IPv4 und TCP/IPv6 erstellt habe. Das weitere Vorgehen Monitor besteht wie auch schon in Kapitel geschilt darin das ein Execution Enviroment gesucht wird und Dateiname desselben in Laufzeitstruktur eingetragen wird und danach Arbeit an den darunterliegenden Service Provi übergeben wird (siehe Abbildung 4.7) Annehmen einer Netzwerkverbindung Um eingehende Verbindungswünsche anzunehmen ruft eine Netzwerk-Serveranwendung Funktion accept() Winsock DLL auf. Diesen Aufruf leitet Winsock DLL an Funktion WSPAccept() eines Service Provis weiter. Ist s ALAN_LSP so erstellt ser einen neuen Socket um eingehende Verbindung zu verwalten. Dieser Socket wird nicht nur an Winsock DLL o einen darüberliegenden Service Provi zurückgeben, sonn auch Funktion CopyID() Monitor DLL übergeben. Die Monitor DLL durchsucht nun ihre Laufzeitstruktur nach den Socketinformationen des Sockets mit bind() an eine Adresse gebunden wurde. Accept() wurde ser Socket als Parameter übergeben und ALAN_LSP hat ihn als Parameter von CopyID() an Monitor DLL weitergegeben. Findet Monitor DLL Socketinformationen so kann auch Daten anzunehmende Verbindung modifiziert werden. Daher legt Monitor DLL nun eine Kopie Socketinformation an. Dabei wird als Socket allerdings gerade neu erzeugte

36 36 Abbildung 4.8 Annahme einer Verbindung Socket eingetragen. Damit ist auch neuen Verbindung dasselbe Execution Enviroment zugeordnet wie allen anen Verbindungen ser Serveranwendung. Findet Monitor DLL keine Socketinformationen so können Daten anzunehmenden Verbindung nicht modifiziert werden. Diesen Sachverhalt hat Monitor DLL bereits beim Binden des ursprünglichen Sockets an Netzwerkadresse erkannt und daher Socketinformationen in Laufzeitstruktur verworfen. Die Konsequenz daraus ist, das für se Verbindung sich Active Network Systemarchitektur genauso verhält, wie als wenn sie nicht vorhanden wäre, und nur normalen Bestandteile des Windows Netzwerkstabels im Einsatz kommen würden.

37 37 In jedem Fall aber übergibt ALAN_LSP Aufgaben an darunter liegenden Service Provi und liefert am Winsock DLL einen Socket zurück unter dem angenommene Verbindung angesprochen werden Daten kann. senden Um nach dem Aufbau Verbindung Daten zu senden, ruft eine Netzwerkanwendung Funktion send() o WSASend() aus Winsock DLL. Beide Funktionen leiten ihren Aufruf an Funktion WSPSend() des zuständigen Service Provis weiter. Ist s ALAN_LSP so ruft ser Funktion Active_Network_Send() Monitor DLL auf. Daraufhin durchsucht Monitor DLL ihre Laufzeitstruktur nach dem Dateinamen des für se Verbindung zu verwendenen Execution Enviroment. Wird kein Eintrag zu ser Verbindung in Laufzeitstruktur gefunden, so übergibt Monitor DLL Sendebuffer direkt unveränt zurück an den ALAN_LSP. Vorher wird Gesamtgröße Sendebuffer, in Statistik Monitor DLL, als nicht veränte Bytes hochgezählt. Wird dagegen ein Eintrag zu ser Verbindung gefunden, so wird Größe Sendebuffer zu den rausgehend zu modifizierenden Bytes sowohl in Statistik Monitor DLL als auch im Statistikteil des Eintrags in Laufzeitstruktur (siehe Abbildung 4.5). Ist aktuelle Sendebufferstruktur allererste zu ser Verbindung gehörende Sendebufferstruktur so bedeutet s das noch keine Messung erreichbarer Datenübertragungsraten existiert und auch keine Messung Datenrate mit Anwendung versucht, Daten zu senden. Daher wird notgedrungen angenommen das mit beliebig hoher Datenrate gesendet werden kann. Es wird daher Gesamtgröße Sendebuffer auch als neue Gesamtgröße Sendebuffer angenommen. Wenn aktuelle Sendebufferstruktur nicht allererste ist, so existiert zumindest eine Zeitangabe darüber wann letzte Sendebufferstruktur mit welcher Größe gesendet wurde. Über aktuelle Zeit lässt sich damit Rate bestimmen mit Anwendung versucht zu senden (siehe Abbildung Abbildung 4.9 Berechnung Rate mit eine Anwendung versucht zu senden 4.9).

38 38 Lei liegt nicht unbedingt schon beim Senden zweiten Sendebufferstruktur ein Meßwert tatsächlich erreichbaren Datenrate vor, den ein Aufruf Winsock DLL und auch eines Service Provis um Daten zu senden o zu empfangen kann sowohl als Abbildung 4.10 Daten senden (Teil 1) sogenannter Blocking Call (dann kommt Anwendung erst wie nach Ende

39 39 Abbildung 4.11 Daten senden (Teil 2) Übertragung wie zum Zuge und kann daher auch weitere Datenbuffer erst danach auf den Weg bringen) o als sogenannter Overlapping Call (dann wird Abwendung direkt weiter ausgeführt, Datenübertragung erfolgt im Hintergrund). Liegt kein Meßwert tatsächlich erreichbaren Datenrate vor, weil Overlapping Calls verwendet wurden und noch keiner beendet wurde, so benutzt Monitor DLL ersatzweise den Konfigurationswert maxsockrate. Dieser kann durch eine Monitor Anwendung modifiziert werden. Ohne Monitor Anwendung ist ser Wert so gesetzt das er eine Datenleitung mit 128 kbit/sec Senate (z.b. ISDN mit Kanalbündelung von 2 Basiskanälen o T-DSL ohne erhöhten Upstream) 5 Die Produktnamen T-Com bezüglich T-DSL bezeichnen den Downstream, also Datenrate in Empfangsrichtung, hier geht es aber um Datenrate in Senichtung, auch Upstream genannt. annimmt.

40 40 Aus dem Meßwert erreichten Übertragungsrate, Datenrate mit Anwendung versucht zu senden, sowie Gesamtgröße aktuellen Sendebuffer errechnet Monitor DLL anzustrebene neue Gesamtgröße Sendebuffer (siehe Abbildung 4.11). Für weitere Sendevorgänge wird Größe und Zeit aktuellen Sendebuffer in Laufzeitstruktur eingetragen. Anschließend ruft Monitor DLL Funktion Execute() des in Laufzeitstruktur vermerkten Execution Enviroment auf. Die Funktionsweise ser Funktion wird in einem eignen Unterkapitel behandelt. Nachdem das Execution Enviroment Sendebuffer ( vorher zu einem großen Buffer zusamengefasst wurden) bearbeitet hat, adrt Monitor DLL in Größe des resultierenden Buffers zur Größe aller zum Senden modifizierten Buffer. Dies erfolgt sowohl in Laufzeitstruktur als auch in Gesamtstatistik Monitor DLL. Bevor Monitor DLL den modifizierten Buffer an den ALAN_LSP zurückgibt, wird ser wie in einzelnen Sendebuffer aufgeteilt. Dabei muß berücksichtigt werden, das Gesamtgröße aller Sendebuffer üblicherweise kleiner geworden ist. Dies bedeutet insbesone das Sendebuffer nicht mehr voll ausgenutzt werden o sogar ganz leer sein können. Die Größen Sendebuffer müssen daher angepasst werden. Da Funktion WSPSend() bzw. WSASend()/send() Sendebuffer als Area von WSABUF-Strukturen übergeben wird, bedeutet das Anpassen Sendebuffer-Größen, das Anpassen WSABUF-Strukturen (siehe Abbildung 4.12 ). typedef struct _WSABUF { u_long len; char FAR *buf; } WSABUF, FAR * LPWSABUF; Abbildung 4.12 WSABUFStruktur (aus [MI02]) Eine WSABUF-Struktur ( vom ALAN_LSP auch genauso an Monitor DLL weitergegeben wird, gesteht aus Größe des Buffers und einem Zeiger auf den Buffer, also Adresse des Buffers (siehe [MI02]). Zuletzt sendet ALAN_LSP modifizierten Sendebuffer an den darunterliegenden Serviceprovi und misst dabei erzielbare Datenrate, welche an Monitor DLL übergeben wird, um sie für als nächstes zu übertragenden Daten in Laufzeitstruktur zu speichern.

41 4.4.7 Daten 41 empfangen Um Daten zu senden ruft eine Netzwerkanwendung Funktion WSARecv() o Received() aus Winsock DLL auf. Dieser Aufruf wird an Funktion WSPRecv() weitergeleitet. Der ALAN_LSP leitet sen Aufruf an den darunter liegenden Service Provi weiter um den Datenempfang durchzuführen. Nachdem eigendliche Datenempfang vollzogen ist ruft ALAN_LSP Funktion Active_Network_Receive() auf. Diese Funktion ist für reine Funktion Application Layer Active Networks nicht notwendig, erlaubt allerdings weitere Einsatzbereiche, auf Modifikation von Daten basieren. Dazu kommt wie auch beim Senden von Daten ein Execution Enviroment zum Einsatz. Allerdings wird sem im Gegensatz zum Senden von Daten keine errechnete neue Buffergröße übergeben, sonn als neue Buffergröße alte Buffergröße. Dies geschied deshalb, da beim Empfang von Daten eine Verringerung Datenmenge nicht notwendig ist, ein Execution Enviroment allerdings immer als Parameter eine neue Buffergröße erwartet. Die Funktionalität Monitor DLL hinter Funktion Active_Network_Receive() ansonsten nahezu identisch mit Funktion Active_Network_Send() welche beim Senden eingesetzt wird. Da keine neue Buffergröße errechnet werden muß, erfolgt allerdings auch keine Berechnung von Datenübertragungsraten o -zeiten. Die Statistikwerte werden dagegen einfach in einem eignen Satz von Werten gespeichert. (Siehe Tabelle ). Die Datenbuffer liegen auch beim Empfang von Daten in Form von WSABUF-Strukturen (siehe Abbildung 4.12 ) vor und müssen daher auch beim Empfang für den 4.5 Aufruf eines Möglichkeiten Execution Enviroment eines zusammengefasst Execution werden. Enviroment Ein Execution Enviroment bekommt als Parameter einen Zeiger auf einen Datenbuffer, Größe des Datenbuffers, anzustrebene neue Größe des Datenbuffers und Datenübertragungsrichtung (als ob Daten gerade zum Senden bereitgestellt werden o gerade empfangen wurden und an Netzwerkanwendung weitergeleitet werden sollen). Als Ergebnis liefert eine Execution Enviroment immer neue Größe des Datenbuffers zurück. Der Datenbuffer selbst wird direkt an ursprünglichen Stelle modifiziert, da er als Zeiger übergeben wurde. Daher braucht ein Execution Enviroment keinen Datenbuffer als Ausgabeparameter, sonn nur als Eingabeparameter.

42 42 Die Möglichkeiten eines Execution Enviroment sind dabei vielfätig, wie es auch 3 Beispiel Execution Enviroments zeigen: EE_NOP.dll (NOP = No Operation => Keine Funktion) enthält nur Aufrufschnittstelle und gibt ansonsten einfach alte Größe des Datenbuffers, als neue Größe des Datenbuffers zurück. Eine Beeinflußung des Datenbuffers geschied nicht. Dieses Execution Enviroment eignet sich daher vorallem zur Darstellung Aufrufschnittstelle eines Execution Enviroments (das heißt also des Application Layer Active Network Execution Enviroment API; siehe Überblick in Abbildung 4.1), aber auch zu Testzwecken, da es keine Beeinflußungen des Datenbuffers durchführt. Für den normalen Betrieb hier vorgestellten Systemarchitektur ist ein Execution Enviroment, das nie eine Datenmodifikation durchführt nicht notwendig, da Daten auch dann nicht modifiziert werden, wenn gar kein Execution Enviroment für eine betreffende Verbindung gefunden werden kann. EE_ANEP.dll (ANEP = Active Network Encapsulation Protokoll) demonstriert Möglichkeit eines Execution Enviroment ein anes auszusuchen und indirekt über Monitor DLL aufzurufen. Dies erlaubt es, das ein Execution Enviroment eine Voranalyse Daten durchführt. Und mit Hilfe des Ergebnis ser Voranalyse ein für tatsächlich angetroffenen Daten spezialisiertes Execution Enviroment aufruft. Dies wird auch genau bei EE_ANEP.dll durchgeführt. (ANEP siehe Kapitel 2.2). Die EE_ANEP.dll sucht Type-ID aus dem Datenbuffer raus und sucht mit Hilfe ser Type-ID ein für se TypeID spezialisiertes EE aus. Die eigentliche Datenmodifikation geschied durch das spezialisierte EE. Existiert kein passendes spezialisiertes EE so erfolgt keine Datenmodifikation. EE_NAMH.dll (NAMH = Null Adress Maschine in Havard-Architektur) ist eine einfache virtuelle Maschine eine Nulladress Maschine implementiert, ähnlich jenigen wie sie im Skript Datenverarbeitung I im Kapitel Mikroprogrammierung [GE98] beschrieben ist. Allerdings benutzt hier benutzte Nulladress Maschine Havardarchitektur, s bedeutet das alle Speicherbereiche getrennt voneinan sind (Code,Daten und Stack) im Gegensatz zur von Neumann Architektur welche für Code, Daten und Stack nur einen gemeinsamen Speicher vorsieht. Außerdem mußten einige Befehle(Opcodes) zusätzlich eingeführt werden um Übergabewerte in virtuelle Maschine einzugeben und Rückgabewerte auszugeben. Dies ist ein Befehl um Länge des Datenbuffers auf den

43 43 Stack zu schreiben (PUSH len), einen um gewünschte neue Länge auf den Stack zu schreiben (PUSH newlen) und einen um tatsächliche neue Länge vom Stack zu laden und virtuelle Maschine zu beenden (POP ret). Dabei sind len,newlen und ret wie Prozessorregister für besone Zwecke aufzufassen. Sie veränn o lesen dabei Abbildung 4.13 Befehle Nulladress-Maschine direkt entsprechenden Übergabe- bzw. (aus Zusätzliche Rückgabewerte [GE98] Befehle Abbildung 4.14 Zusatzbefehle NAMH EE_NAMH.dll. S.47) NAMH:

44 44 Abbildung 4.15 Paketformat NAMH Das Execution Enviroment EE_NAMH.dll erwartet als Datenbuffer ein ANEP-Packet (siehe Kapitel 2.2) dessen Nutzinhalt den in Abbildung 4.15 abgebildeten Aufbau entspricht. Länge des Code als vorzeichenlose Ganzzahl in Big Endian Notation, gefolgt von Länge Daten in Big Endian Notation. Anschließend Code (sofern Codelänge >0 ist) und zuletzt Daten (sofern Datenlänge >0). Dabei muß mindestens eine beiden Längen größer 0 sein, um sinnvoll bearbeitet zu werden. Das Execution Enviroment fängt allerdings fehlerhafte Datenbuffer ab und versucht sie nicht zu bearbeiten. Wird nur Code gesendet, so wird ser für spätere Verwendung mit Hilfe zu sem Zweck eingerichteten Funktion in Monitor DLL gespeichert. Wird dagegen nur Daten gesendet, so wird zum Bearbeiten ser Daten vorher gespeicherte Code verwendet. Da NAMH nur 13 Bit für Adressierung bereitstellt, ist Größe eines damit bearbeitbaren Datenbuffers auf 8192 Bytes beschränkt. Der Code zur Bearbeitung verwendet wird, kann dabei ebenfalls maximal 8192 Bytes groß sein. Diese Größen sind aufgrund Havard-Architektur unabhängig voneinan zu sehen und Beschränkung besteht nicht darin das für Code+Daten nur 8192 Bytes zur Verfügung stehen. Dies gilt nur für ses spezielle EE. Die Schnittstelle zwischen Monitor DLL und Execution Enviroment erlaubt grundsätzlich Datenbuffer bis zu 2^32 Bytes (=4 GByte). Dies muß allerdings nicht für alle Execution Enviroments intern gelten. Kann ein Execution Enviroment keine 4 GByte bearbeiten, so muß es dennoch in Lage sein mit einer übergebenen Datenbuffergröße von bis zu 4 GByte fehlerfrei umgehen zu können. Dies bedeutet das Größe des Datenbuffers getestet werden muß und bei einem zu großen Datenbuffer das Execution Enviroment einfach nur als neue Länge alte Länge ausgibt und ansonsten keine Modifikation durchführt. Dies ist notwendig um sicherzustellen, das unter keinen Umständen Daten einfach zerstört werden o Systemstabilität durch Bufferüberläufe beeinträchtigt wird.

45 Schnittstellenbeschreibungen In sem Unterkapitel werden alle internen und externen Schnittstellen Application Layer Active Network Systemarchitektur für Windows beschrieben. Teilweise wurden sie bereits in früheren Kapiteln angerissen, hier finden sich allerdings systematisch alle Schnittstellen erkläutert Windows Sockets Application Programming Interface (API) Das Windows Sockets API ist Schnittstelle mit eine Netzwerkanwendung auf Winsock DLL zugreift. Die in ser Arbeit beschriebene Systemarchitektur veränt se Schnittstelle nicht. Da sie aber in ser Arbeit noch nicht detaliert beschrieben wurde, aber nicht unwichtig ist, hier ihre Funktionen (siehe [MI03] Windows Sockets Functions) in einem kurzen Überblick: reinkommenden Verbindungswunsch Funktionskatalog: accept() Nimmt einen an AcceptEx() einen Socket an Nimmt den reinkommende Verbindungswunsch an und liefert dabei sowohl Adresse des lokalen und des entfernten Systems zurück. Außerdem empfängt se Funktion den ersten Block von Daten, Client gesendet bind() Verbindet hatte. einen Socket mit einer lokalen Netzwerkadresse closesocket() Schließt einen vorhandenen Socket. connect() Stellt über eine bestimmten Socket eine Verbindung her ConnectEx() Stellt eine Verbindung her und sendet einen ersten Block an DisconnectEx() Daten Beendet eine Verbindung, so das verwendete Socket freeaddrinfo() Gibt weiter eine Adressinformation zugewiesen gai_strerror() Hilft bei verwendet wurde Ausgabe werden mit wie von kann. getaddrinfo() frei. Fehlermeldungen

46 GetAcceptExSockaddrs() 46 Analysiert Ausgabe von AcceptEx() und liefert dabei Adressinformationen des lokalen und entfernten Systems zurück. GetAddressByName() Liefert Netzwerkadressinformationen getaddrinfo() Protokollunabhängiges Wandeln eines Hostnames in eine zurück. Netzwerkadresse gethostbyaddr() Liefert den Hostnamen zu einer Netzwerkadresse. gethostbyname() Liefert den Hostnamen aus einer Hostdatenbank zurück gethostname() Liefert den Hostnamen des lokalen Computers zurück getnameinfo() Namesauflösung von einer Netzwerkadresse zu einem Hostnamen getpeername() Liefert zu einem Socket Adressinformationen des entfernten getprotobyname() Liefert Endes Protokollinformationen zu Protokollnamen getprotobynumber() Liefert zurück Protokollinformationen zu Protokollnumber getservbyname() einem einer zurück Liefert Serviceinformationen zu einem Servicenamen und Protokoll getservbyport() dito zu einem Port und Protokoll getsockname() Liefert zu einem Socket den lokalen Hostnamen getsockopt() Liefert zu einem Socket gesetzten Optionen zurück htonl() Wandelt eine Zahl vom Typ vorzeichenlose lange Ganzzahl (u_long) von Bytereihenfolge des lokalen Computers (bei x86 ist s Little Endian) in Bytereihenfolge von TCP/IP (Network Byte Or o auch htons() Big Endian genannt) dito für eine Zahl vom Typ vorzeichenlose kurze Ganzzahl inet_addr() (u_short) Wandelt eine Zeichenkette (String) eine IPv4 in Punktschreibweise (z.b ) enthält in Binärform um, wie sie für diverse ane Funktionen Winsock inet_ntoa() Wandelt DLL eine IP-Adresse Punktschreibweise nötig im Binärformat, ist. in um

47 ioctlsocket() Steuert den listen() Bringt einen ntohl() Wandelt lange 47 Ein/Ausgabemodus Socket eine Zahl Ganzzahl in vom in den Typ lokalen eines Sockets Horchstatus vorzeichenlose Bytereihenfolge des Computers ntohs() dito für eine Zahl vom recv() Empfängt recvfrom() Empfängt ein Datagram und speichert Quelladresse select() Stellt den Status eines o mehrerer Sockets fest send() Sendet sendto() Sendet setsockopt() Setzt shutdown() Beendet socket() Erzeugt einen Socket an einen bestimmten Daten Typ über Daten kurze einen über Socket einen Socket ein Datagram Optionen Service zu Überträgt TransmitPackets() Überträgt eine im einem Socket eines Sockets Datenübertragung Provi TransmitFile() gebunden Datei Speicher Ganzzahl über ist einen befindliche Socket Daten einen über Socket WSAAccept() wie Accept, aber mit Zusatzfunktionen wie z.b. QoS WSAAddressToString() wandelt alle Komponenten einer SOCKADDR-Struktur in ein menschenlesbares Zeichenketten-Format WSAAsyncGetHostByAddr() wie GetHostbyaddr, aber asynchron WSAAsyncGetHostByName() wie GetHostbyName, aber asynchron WSAAsyncGetProtoByName() wie GetProtobyname, aber asynchron WSAAsyncGetProtoByNumber() wie GetProtobynumber, aber asynchron WSAAsyncGetServByName() wie GetServbyname, aber asynchron WSAAsyncGetServByPort() wie GetServbyport, aber asynchron WSAAsyncSelect() Fort Windows nachrichtenbasierte Benachrichtigungen zu Netzwerkereignissen für einen Socket WSACancelAsyncRequest() Bricht an einen noch nicht vollendeten Netzwerkzugriff WSACleanup() asynchronen ab. Beendet Nutzung Winsock DLL durch eine Netzwerkanwendung WSACloseEvent() Beendet einen Ereignis Objekt Handler

48 connect(), aber 48 WSAConnect() wie WSACreateEvent() Erzeugt WSADuplicateSocket() Erzeugt eine Struktur, mit ein neuer Socket einen Beschreiber mit Ereignis für ein QoS-Optionen Objekt teilbaren Handler Socket erzeugt werden WSAEnumNameSpace kann. Liefert Informationen über vorhandene Namesräume Provis() WSAEnumNetworkEvents() Durchsucht zu einem Socket Netzwerkereignisse und löscht aufgezeichneten WSAEnumProtocols() Liefert aufgetrettenen alle Netzwerkereignisse. Informationen zu allen verfügbaren Transportprotokollen WSAEventSelect() Spezifiziert eine Ereignisobjekt mit einem Satz von Netzwerk WSAFDIsSet() Ereignissen Spezifiziert ob ein Socket in einem Satz von Socket WSAGetLastError() Beschreibern enthalten ist. Liefert den Fehlerstatus zum letzten fehlgeschlagenen Zugriff WSAGetOverlappedResult() Liefert WSAGetQOSByName() Eine WSAGetServiceClassInfo() Liefert das eines Overlapping QOS-Struktur eines Zugriffs initialisieren Classeninformationen Service WSAGetServiceClassName Ergebnis zu einem Namespace speziellen Provis Liefert den Namen eines Service ByClassId() WSAHtonl() Wie Htonl() WSAHtons() Wie Htons() WSAInstallServiceClass() Registriert eine Service Klasse in einem Namensraum WSAIoctl() Kontrolliert WSAJoinLeaf() Erklärt Teilnahme an einer Multipoint Sitzung den Modus eines Socket (Multicast!) WSALookupServiceBegin() Initialisiert WSALookupServiceEnd() Gibt den eine bei WSALookupServiceBegin() WSALookupServiceNext() WSALookupServiceNext() Liefert Clientsuche angeforten benutzten Service Handler und frei Informationen

49 WSANSPIoctl() 49 Entwickelt für Ein/Ausgabekontrollaufrufe zu einem registrierten Namensraum WSANtohl() wie Ntohl() WSANtohs() wie Ntohs() WSAProviConfigChange() Benachrichtigt Anwendung, Provieinstellung wenn sich veränt sie hat WSARecv() wie Recv() WSARecvDisconnect() beendet eine Netzwerkverbindung und enpfängt dabei noch letzte Daten wie Recv() WSARecvEx() ähnlich WSARecvFrom() wie WSARecvMsg() Empfängt WSARemoveServiceClass() Entfernt WSAResetEvent() Setzt den Status eines spezifischen Ereignisobjekts Recvfrom() Daten und eine Steuerinformationen Serviceklasse zurück WSASend() wie Send() WSASendDisconnect() Sendet letzte Daten und beendet dann Verbindung WSASendTo() wie WSASetEvent() Setzt den Status eines spezifischen Ereignisobjekts WSASetLastError() Setzt WSASetService() Registriert o entfernt aus Windows Registery Sendto() den Fehlercode einen Service aus einem o mehreren Namesräumen WSASocket() wie Socket() WSAStartup() Beginn Benutzung Winsock DLL durch eine Anwendung WSAStringToAddress() Konvertiert einen nummerischen String in eine SOCKADDR-Struktur WSAWaitForMultipleEvents() Liefert einen o alle spezifizierten Ereignisobjekte zurück sich im gesetzten Zustand befinden

50 50 Folgene Funktionen sind veraltete (aber noch vorhandene) Winsock 1.1 Funktionen: (sie werden daher hier nur Vollständigkeit halber genannt, aber nicht erläutert) EnumProtocols() GetAddressByName() GetNameByType() GetService() GetTypeByName() SetService() Diese Funktionen waren in Winsock 1.1 enthalten, sind aber in aktuellen Version (sie 2.2 sind daher auch nicht nur über mehr das Winsock enthalten: 1.1 API erreichbar) WSACancelBlockingCall() WSAIsBlocking() WSASetBlockingHook() WSAUnhookBlockingHook() Windows Sockets 2.0 Service Provi Interface(SPI) Das Windows Sockets 2.0 Service Provi Interface (siehe [MI02] und [MI03]) wird von jedem Service Provi als Aufrufschnittstelle nach oben angeboten. Der oberste Service Provi bietet es somit Winsock DLL an. Je ane Service Provi seinem Vorgänger in Kette. Damit ergibt sich Schichtung Service Provi. Ein Base Service Provi ist dabei immer unterste Service Provi in Kette. Layered Service Provi heißen alle Service Provi über dem Base Service Provi in Kette angeordnet sind. (Siehe Abbildung 4.1). Service Provi sind dabei Dynamic Link Librarys (DLL) mit nur einem einzigen direkt exportierten Einsprungpunkt (das heißt nur eine einzige Funktion ist direkt aufrufbar). Dieser Einsprungpunkt gehört immer zur Funktion WSPStartup(). Alle im untenstehenden Funktionskatalog stehenden Funktionen stehen erst nach Aufruf von WSPStartupex() über eine Funktionstabelle zur Verfügung. Die Aufgabe je Funktion ergibt sich meist aus Tatsache das meisten Funktionen Winsock DLL nur den benötigten Service Provi suchen und dann dessen fast gleichnamige Funktion aufrufen. Dabei eine Funktion in Winsock DLL xy() o WSAxy() heißt mit Funktion WSPxy() eines Service Provis. Daher findet

51 51 sich in untenstehendem Funktionskatalog auch keine Funktionsbeschreibung. Sie lässt sich beim Winsock API (Kapitel 4.5.1) entnehmen. Als Layered Service Provi erwartet Application Layer Active Network Layered Service Provi somit mindestens einen weiteren Service Provi unter sich in Kette Service Provi. Die meisten Funktionen reicht ALAN_LSP dabei nur an den drunterliegenden Service Provi durch. Einige wenige Funktionen rufen vor dem Durchreichen an den drunterliegenden Service Provi Funktionen Monitor DLL auf um Active Network Funktionalität bereitzustellen. Der ALAN_LSP benutzt dabei das mit ser Systemarchitektur neu eingeführte Application Layer Active Monitor API. Funktionskatalog eines Windows Sockets 2.0 Service Provis: WSPAccept() WSPGetQOSByName() WSPAddressToString() WSPIoctl() WSPAsyncSelect() WSPJoinLeaf() WSPBind() WSPListen() WSPCancelBlockingCall() WSPRecv() WSPCleanup() WSPRecvDisconnect() WSPCloseSocket() WSPRecvFrom() WSPConnect() WSPSelect() WSPDuplicateSocket() WSPSend() WSPEnumNetworkEvents() WSPSendDisconnect() WSPEventSelect() WSPSendTo() WSPGetOverlappedResult() WSPSetSockOpt() WSPGetPeerName() WSPShutdown() WSPGetSockOpt() WSPSocket() WSPGetSockName() WSPStringToAddress() WSPAccept() und WSPJoinLeaf() ruft CopyID() aus Monitor DLL auf. WSPBind() und WSPConnect() ruft dagegen OpenID() auf. WSPCleanup() ruft wenn es letzte Instanz des ALAN_LSP ist ALANCleanup() auf. WSPCloseSocket() und WSPShutdown() rufen immer CloseID() aus Monitor DLL auf. WSPSocket() erstellt über den Aufruf von NewID() eine neue Verbindungs-ID. Das Initialisieren des ALAN_LSP mit WSPStartupex() initialisiert über den Aufruf von ALANInit() auch Monitor DLL. Dies allerdings nur beim ersten Aufruf des ALAN_LSP.

52 52 Die Daten sendenen Funktionen WSPSend(), WSPSendto() und WSPSenddisconnect() lassen ihre Daten alle über Funktion Active_Network_Send() vor dem Senden modifizieren. Ebenso lassen alle Daten empfangenden Funktionen (WSPRecv(), WSPRecvFrom() und WSPRecvDisconnect()) ihre Daten vor dem Weitergeben an darüberliegenden Softwareschichten erstmal noch durch Active_Network_Receive() Application Funktion bearbeiten. Layer Active Network Monitor API Das Monitor API gliet sich in 3 Teile, alle 3 von Monitor DLL stammen: Funktionen dafür bestimmt sind vom Application Layer Active Network Layered Service Provi aufgerufen zu werden, Funktionen von einer Monitor Anwendung (dem Mangmentsystem) aufgerufen werden können, Hilfsfunktionen von Execution Enviroments genutzt werden können sowie Funktionen Strukturen in Windows Registery Funktionen ALANInit() anlegen für den bzw. dabei helfen. Layered Service Provi: Initialisiert Laufzeitstruktur und breitet sie zur ersten Benutzung vor ALANCleanup() Räumt NewID() Erzeugt einen neuen Eintrag in Laufzeitstruktur OpenID() Bestimmt das Laufzeitstruktur zu einer auf. Verbindung benötigte Execution Enviroment und trägt es in den mit NewID() erzeugten CloseID() Eintrag in Laufzeitstruktur Entfernt einen nicht mehr benötigten Eintrag aus CopyID() ein. Kopiert Laufzeitstruktur einen Eintrag, unter einer weiteren Verbindungsnummer benötigt wird (wird bei Servern benötigt für jeden verbundenen Client einen eignen Socket offen halten, vom Socket abgeleitet wird, beim CleanupAA() Starten des Servers angelegt wurde) Löscht alle in Windows Registery hinterlegten Active Applications (s sind kleine Programme ein Execution Enviroment hinterlegen kann, um damit für später durchfließende Daten zu verwenden).

53 Active_Network_Send() Bearbeitet übergebenen Senden nach Active_Network_Receive() dito, für Active_Send_Rate() Funktion um Active 53 Datenbuffer Network Gesichtspunkten. empfangene vor dem Datenbuffer gemessene Senate in Laufzeitstruktur einzutragen und damit bei späteren Sendevorgängen calcrate() zu berücksichtigen Berechnet Datenraten und berücksichtigt dabei, das Millisekundenzäher von Windows alle 49,7 Tage einen Überlauf hat. Dies bedeutet bei Datenübertragungen kurz vor dem Überlauf beginnen und kurz nach demselben beendet werden, das Zeitdifferenz nicht einfach durch zeit2-zeit1 berechnet werden kann. Diese Funktionen von einem Funktion Management berücksichtigt System benutzt genau werden Interne s. können: Variablen: bytes_send Gesendete Bytes bytes_pass_send Gesendete Bytes nicht modifiziert werden konnten bytes_in_send Gesendete Bytes vor dem Modifizieren bytes_out_send Gesendete Bytes nach dem Modifizieren bytes_received Empfangende (über alle bytes_pass_received Empfangende bytes_in_received Empfangende Bytes vor dem Modifizieren bytes_out_received Empfangende Bytes nach dem Modifizieren maxnicrate Maximal mögliche Datenrate, ist Datenrate mit Bytes Bytes (über alle nicht Verbindungen) Verbindungen) modifiziert wurden Netzwerkkarte maximal arbeiten kann. Dieser Wert wird für einen Plausibilitätstest verwendet. Alle Messwerte Datenrate über sen Wert liegen, werden als Fehlmessungen gewertet und deshalb durch sen Wert ersetzt. Standardwert ist (Bytes/sec) was für Upstreamrate eines T-DSL 1000 Anschlußes T-Com entspricht bzw. einer Verbidnung über 2 ISDN-Basiskanäle.

54 defaultsockrate 54 Standard-Datenrate mit gesendet wird bevor bei overlapping ein Messwert existiert. Wird verwendet da bei Overlapping Sendevorgang unabhängig von Ausführung Netzwerkanwendung im Hintergrund erfolgt. Funktionskatalog: Die Registerfunktionen erlauben das Hochzählen Zähler, ohne das se Zähler durch gleichzeitige Datenübertragungen inkonsitent werden. Obige Variablen sollten daher niemals direkt veränt werden, sonn nur ausgelesen werden. Zum Änn immer nur folgenden Funktionen RegisterSend() Zähler für gesendete RegisterReceive() Zähler für empfangende RegisterSend_pass() Zähler für nutzen: Bytes hochzählen. Bytes hochzählen nicht modifizierbare Bytes hochzählen nicht modifizierbare Bytes hochzählen (Senden) RegisterReceive_pass() Zähler für (Empfang) RegisterSend_in() Zähler für zu modifizierende Bytes hochzählen zu modifizierende Bytes hochzählen (Senden) RegisterReceive_in() Zähler für (Empfang) RegisterSend_out() Zähler für modifizierte Bytes hochzählen (Senden) RegisterReceive_out() Zähler für modifizierte Bytes hochzählen (Empfang) ALANSuspend() Netzwerkzugriffe aussetzen ALANResume() Netzwerkzugriffe ResetStat() Alle SetStat() Die SaveStat() Alle Zähler gleichzeitig und damit konsistent auslesen ALANEnumStruct() Laufzeitstruktur vorübergehend wie Zähler Zähler auf zurücksetzen bestimmte auslesen. zulassen Der Werte setzen Rückgabewert ser Funktion ist Nummer des nächsten Eintrags in Struktur. Ist kein weiterer Eintrag mehr vorhanden ist Rückgabewert 0. Damit lässt sich leicht Laufzeitstruktur zyclisch auslesen.

55 Funktionen für SubExecute() 55 Execution Enviroments: Aufruf eines Execution Enviroment durch ein anes Execution nbothbo16() Wandeln Enviroment von (siehe mehreren kurzen Kapitel 4.4) Ganzzahlen von Netzwerk Bytereihenfolge (Big Endian) in Little Endian hbotnbo16() Wandelt mehrere kurze Ganzzahlen in Big Edian um. SaveAA() Speichert eine Active Application für spätere Verwendung RestoreAA() Ladet zwischen. eine Active Enviroment Application zwecks in Ausführung ein zur aktueller mkalanstr() Execution Modifikation Eingabedaten Wandelt eine ganze Zahl in eine Zeichenkette ganze Zahl in Hexadezimalschreibweise enthält. Funktion zur Einrichtung von wichtigen Strukturen in Windows Registery: SetupALAN() Erzeugt verwedendete SetupALANAPH() durch se Struktur in Systemarchitektur Registery Trägt einen neuen ALAN Protokoll Helper in Registery ein. Damit wird ein neues Transportprotokoll SetupALAN_EE() Systemarchitektur bekannt gegeben. Trägt ein neues Execution Enviroment ein, welches durch das Ergebnis Analyse Adressdaten durch einen ALAN Protokoll Helper bestimmt werden soll. SetupALAN_Chain() Trägt ein neues Execution Enviroment ein, welches durch ein anes Execution Enviroment aufgerufen werden Application Layer Active soll. Network Protokoll Helper API Das ALAN Protokoll Helper API besteht ausschließlich aus Funktion Subprotokoll() welche von einem ALAN Protokoll Helper zur Verfügung gestellt wird. Diese Funktion erwartet als Eingabe eine SOCKADDR-Struktur und liefert daraus Nummer des Protokolls welches auf Anwendungsebene benutzt werden soll zurück. Bei TCP/IP ist s sowohl bei TCP/IPv4 als auch bei TCP/IPv6 Portnummer.

56 56 (Portnummern se Tabelle 4.2). Dabei ist zu beachten das Protokoll Helper für TCP/IPv4 nicht für TCP/IPv6 benutzt werden kann, sonn ein aner ist. Siehe Tabelle 4.1, SOCKADDR-Strukturen von TCP/IPv4 und TCP/IPv6 siehe Abbildung 4.2 und 4.3) Application Layer Active Network Execution Enviroment API Ein Execution Enviroment bietet über das Application Layer Active Network Execution Enviroment API nur Funktion Execute() an. Dieser Funktion wird als Argumente einen Zeiger auf den zusammengefügte Datenbuffer, seine Länge, gewünschte neue Länge, ID dazu gehörigen Verbindung, sowie ob es sich um einen zu versendenen Datenbuffer handelt o um einen gerade empfangenen Datenbuffer. Bei Datenbuffern gerade empfangen wurden ist gewünschte neue Länge immer gleich aktuellen Länge des Datenbuffers. Das Argument neue Länge ist hier nur um des einheitlichen Aufrufs wegen vorhanden. Ein Verkleinern eines Empfangsbuffers ist eher nicht notwendig. Wohl aber auch möglich, wenn gewünschte Größe doch kleiner als aktuelle Größe gesetzt würde. Die Monitor DLL führt s aber nicht durch. Als Rückgabewert liefert ein Execution Enviroment Der immer veränte Datenbuffer neue wird Länge stehts des an Datenbuffers alten Stelle zurück. belassen. 4.7 Benung Application Layer Active Network Systemarchitektur Die Komponenten Application Layer Active Network Systemarchitektur sind so aufgebaut, das sie normalerweise nach einmaliger Konfiguration alles alleine und automatisch machen können. Konfiguriert werden müssen alle Zuordnungen zwischen Protokollen und Protokollhelpern, sowie zwischen Protokollen und Execution Enviroments. Außerdem muß Monitor Dll, maximal mögliche Sende-Datenübertragungsrate kennen, um Fehlmessungen zu erkennen, sowie einen Defaultwert als Ersatzwert, für Zeit wo noch kein Meßwert realen Übertragungsrate existiert. Außerdem stellt ALAN Systemarchitektur auch einige statistische Daten, über bearbeitetemn Daten, bereit. Diese Statistikdaten auszuwerten und Konfiguationswerte einzustellen sind Aufgaben des Management-Systems. Um se Einstellungen aufzunehmen besitzt Monitor DLL einen speziellen Satz von Einsprungpunkten und exportierten Variablen (siehe auch Kapitel 4.6.3).

57 maxnicrate ist dabei Beispiel: T-DSL Die auf Senate 1000 (Senate 128 Variable maxnicrate ist in Byte KBit/sec also auf pro 57 Sekunde was 16 KByte/sec den Wert zu setzen. entspricht) zu setzen. Dies ist allerdings auch gleichzeitig Defaultwert, den se Variable auch ohne gezielte Einstellen hat. Defaultsockrate ist angenommene Senate, bevor eine echte Messung tatsächlichen Datenrate existiert. Der Wert ist ebenfalls in Byte pro Sekunde anzugeben. Standardmäßig steht er ebenfalls auf Einmalig beim Installieren hier beschriebenen Systemkomponenten ist Struktur Windows Registery Zweige für Active Network über den Aufruf von SetupALAN einzurichten. Diese Funktion kennt keine Parameter und braucht nur einmal aufgerufen werden. Das Registrieren eines neuen Protokollhelpers um ein neues Transportprotokoll zu unterstützen, wird mit Funktion SetupALANAPH durchgeführt. Dieser Funktion sind als Zahl zu übergeben: Die Protokollfamilie, Sockettype sowie das zu benutzende Transportprotokoll. Als weiterer Parameter kennt se Funktion nur einen Dateinamen als 13 Zeichen umfassendes Feld von Zeichen. Das letzte Zeichen ist dabei das Zeilenende das als 0-Byte zu übergeben ist. Execution Enviroments werden je nach dem ob sie als direkt durch Wahl eines Anwendungsprotokolls angesprochen werden sollen o über ein anes Executions Enviroment mit Funktion SetupALAN_EE o mit Funktion SetupALAN_Chain registiert. Die Funktion SetupALAN_EE registriert dabei für Auswahl über ein Anwendungsprotokoll und erwartet als Parameter Protokollfamilie, den Sockettype, das zu benutzende Transportprotokoll, sowie das zu benutzende Anwendungsprotokoll, gefolgt vom Dateinamen des Execution Enviroments. SetupALAN_Chain erwartet dagegen einen internen Namen für das Execution Enviroment das ein anes aufrufen soll als Feld von Zeichen, ein Zeichen das als Nummer des aufzurufenden Execution Enviroments aufzufassen ist, sowie dem Dateinamen des aufzurufenden Execution Enviroments.

58 Grenzen Application Layer Active Network Systemarchitektur Nicht in jedem Fall ist hier vorgestellte Systemarchitektur in Lage eine Modifikation zu versendenen Daten wie gewünscht durchzuführen. In sem Unterkapitel werden alle Fälle aufgezählt und erläutert bei s Unbekannte Fall ist. Transportprotokolle Da Monitor DLL über Protokoll Helper SOCKADDR-Struktur des verwendeten Transportprotokoll kennen muß, den Verbindungen das jeweils passende Execution Enviroment zuzuordnen, ist eine Modifikation nicht möglich, wenn das Transportprotokoll unbekannt ist. Unbekanntes Protokoll auf Anwendungsebene Auch, wenn zwar ein passen Protokoll Helper vorhanden ist, aber kein für das Protokoll das auf Anwendungsebene eingesetzt wird geeignetes Execution Enviroment vorhanden ist gelingt Modifikation nicht. Das Execution Enviroment hat Aufgabe Modifikationen durchzuführen, welche durch Monitor DLL und weitere Komponenten ser Systemarchitektur vorbereitet wurden, daher ist ohne EE keine Modifikation möglich. Kein passendes Unter-Execution Enviroment Benutzt ein Execution Enviroment, Möglichkeit je nach Art Daten ein weiteres Execution Enviroment zu starten, so muß für jede Art von Daten durch das Execution Enviroment laufen, auch ein Execution Enviroment existierten, welches Daten wirklich bearbeiten kann. Ist s nicht Fall, so gibt es Daten durch kein Execution Enviroment bearbeitet werden können, und damit unbearbeitet gesendet bzw. empfangen werden. Verbindungslose Netzwerkzugriffe Der ALAN_LSP misst Zeitdauer Datenübertragung, um daraus zu berechnen, wie viel Datendurchsatz erreicht werden kann. Dies passiert darauf das verbindungsbezogene Netzwerkzugriffe erst als gelungen gelten, wenn Übertragung wirklich durchgeführt ist. Verbindungslose Netzwerkzugriffe gestalten sich art, das einfach drauf los gesendet wird. Dabei existiert keinerlei Sicherheit ob ein Datenpaket überhaupt ankommt, geschweige den wann. Daher ist Datenübertragung bei verbindungslosen

59 59 Netzwerkzugriffen beendet, sobald Datenbuffer an unter dem ALAN_LSP befindliche Softwareschicht übergeben wurde. Die gemessene Zeitdauer ist daher praktisch immer sehr klein, eventuell sogar fast immer kleiner als 1 ms, was minimalen Zeitauflösung bei Windows vorhandenen Zeitzähler entspricht. Datenbuffer von verbindungslosen Netzwerkzugriffen können daher praktisch nicht sinnvoll modifiziert Broadcast, werden. Multicast und Anycast Broadcasts (siehe [NE02]) sind Netzwerkzugriffe vorallem innerhalb eines lokalen Netzwerkes alle erreichbaren Netzwerkstationen ansprechen. Dies geschied im Wessendlichen durch Drauflossenden Datenpakete ins Netz. Damit ist wie bereits bei verbindungslosen Netzwerkzugriffen keine effektive Modifikation Daten möglich. Zumal Broadcasts üblicherweise auch verbindungslos sind. Multicasts (siehe [NE03] sind Netzwerkzugriffe eine spezielle Gruppe von Netzwerkstationen anspricht, sich dazu anmelden. Der eigentliche Sendevorgang geschied allerdings ähnlich wie bei Broadcasts durch drauflossenden Datenpakete. Multicast Anycast ist (siehe ein [NE01]) eine ist eine modifizierte Form bei neu TCP/IPv6 von eingeführte Broadcast. Form von Netzwerkzugriffen, wo ein Netzwerkrechner aus einer Gruppe von gleichartigen Rechnern benutzt wird, ohne das anforne Rechner dazu selbst ein spezielles Mitglied ser Gruppe auswählen muß. Die Auswahl geschied automatisch durch Komponenten des Netzwerkes. Dies beeinträchtigt Funktion ser Systemarchitektur nicht, soweit nicht bereits ein aner Grund vorliegt, eine Modifikation von Daten erschwert o ausschließt. Unicast Unicast (siehe [NE04]) ist normale Art eines Netzwerkzugriffs, wo eine Netzwerkstation eine ane anspricht. Dies ist daher auch Art von Netzwerkzugriffen wofür se Systemarchitektur entworfen wurde. Sofern keine oben genannten Gründe vorliegen, spricht daher nichts gegen Modifikation zu sendenen Daten nach Active Network Gesichtspunkten.

60 4.9 Neuere und zukünftige 60 Entwicklungen Dieses Unterkapitel stellt kurz frische und zukünftige Windows Versionen vor und erläutert kurz, welche Änungen für das hier vorgestellte Application Layer Active Network System relevant sind, Windows Am se XP hat Windows Versionen Microsoft das mit sich bringen. Servicepack Servicepack 2 zu Windows 2 XP als Netzwerkinstallationspaket für IT-Spezialisten und Entwickler veröffentlicht. Mit sem Servicepack haben sehr viele Änungen in Windows Einzug gehalten. Insbesone auch im Bereich des Netzwerkstapels. Diese Arbeit kann sich nicht im einzelnen mit je ser Änungen beschäftigen, da zum Zeitpunkt Veröffentlichung ses Servicepacks se Arbeit bereits sehr weit fortgeschritten war. Die bei Microsoft zum Servicepack 2 dokumentierten Änungen umfassen allerdings nicht das Windows Sockets Service Provi Interface (siehe [MI04]). Da ses einzige für Funktion in ser Arbeit beschriebenen Systemarchitektur von Windows benötigte Schnittstelle ist, ist davon auszugehen das Funktion Application Layer Active Network Systemarchitektur durch das Servicepack 2 von Windows XP nicht Windows beeinträchtigt 2003 wird. Server Microsoft hat auch bei Windows 2003 Server keine Änung des Windows Sockets Service Provi Interface durchgeführt. Damit ist se Systemarchitektur auch bei Windows 2003 Server einsetzbar. Windows Longhorn Für Windows Longhorn, nächste große Windows Version sind sehr einschreitende Änungen angekündigt [CT03]. Allerdings sind bisher nur wenige Hinweise darauf zu finden, welche Auswirkungen se Änungen tatsächlich haben. Bekannt ist allerdings das Ausführungsschicht von Windows sich in mindestens zwei Teile teilt und se beiden Teile mehr o weniger unanhängig voneinan arbeiten werden [CT03]. Dies deutet zumindest auf größe Änungen hin, welche auch den Netzwerkstabel betreffen können. Insbesone ist damit eine Änung an den für in ser Arbeit vorgestellte Systemarchitektur wichtigen Systemschnittstellen nicht undenkbar.

61 Windows Bit Edition Die in ser Arbeit vorgestellte Systemarchitektur wurde auf einem aktuellen Windows XP entwickelt. Also einem 32-Bit-Windows. Dies zeigt sich insbesone durch viele Speicherlimits, darauf zurückzuführen sind, das ein 32-Bit-System 4 GByte Gesamtspeicher direkt adressieren kann. Davon sind allerdings nur 2 GB für eine Anwendung direkt verfügbar. 64-Bit-Systeme wie Intel Itanium und AMD64-CPUs können dagegen sehr viel mehr Speicher bereitstellen. Davon würde unter Umständen auch ein Application Layer Active Network 64 System profitieren können. Dies ginge allerdings nur nach Anpassung Limits im Quellcode hier beschriebenen Module Systemarchitektur. Aufgrund Tatsache das, das Windows Sockets Service Provi Interface beim Schritt zu 64-Bit nicht veränt wurde, wäre eine einfache 64-Bit Version auch durch einfaches neucompilieren denkbar. Eine genauere Betrachtung habe ich allerdings nicht durchgeführt Ane Windows Versionen Bisher hat se Arbeit nur aktuelle und zukünftige Windows Versionen betrachtet. Dieses Unterkapitel wird auch noch kurz frühere und weniger bekannte Windows- Versionen betrachten. (Winsock Versionen außer für NT3.x siehe auch [JO02] Tabelle 1-1). Windows 1.0 bis Windows 3.11 Windows war bis einschließlich Version 3.11 von Haus aus nicht netzwerkfähig. Die Benutzung von Netzwerkanwendungen setze daher propritäre Treiber von anen Herstellern voraus. Daher ist eine Veränung Treiberarchitektur zum Realisierung von Active Network Funktionalistät eher nicht realisierbar. Diese Windows Versionen sind allerdings auch schon so alt, das sie praktisch nicht mehr relevant Windows sind. 95 Mit Windows 95 zog erstmals ein Netzwerkstabel in Windows ein. Dies war Windows Sockets 1.1. Dies war daher noch Windows Netzwerkstabel in ser Arbeit betrachtet und modifiziert wurde.

62 62 Später war allerdings ein Update Winsock DLL erhältlich. Dieses realisiert erstmal Winsock 2.0 Schnittstelle und dabei auch das Service Provi Interface, welches in ser Arbeit benutzt wird um sich in den Netzwerkstabel einzuklinken, und Active Network Funktionalität zu implementieren. Es ist daher anzunehmen das nach dem Update Winsock Windows auch Module 98 ser Arbeit und einsetzbar Windows sind. ME Windows 98 und Windows ME wurde bereits mit neuen Winsock DLL ausgeliefert und haben daher bereits den monen Netzwerkstabel, Vorausetzung für in ser Arbeit beschriebene Active Windows Network Systemarchitektur NT ist. 3.x Alle Windows NT Versionen Versionslinie 3 enthalten nur einen Netzwerkstabel nach Winsock Spezifikation 1.1 (siehe [TA04]) und sind daher nicht für Realisierung ser Systemarchitektur Windows geeignet NT. 4.0 Windows NT in Version 4.0 enthält bereits den für se Arbeit vorausgesetzen Netzwerkstabel nach Winsock Spezifikation 2.2 und ist daher auch geeignet Active Network Datenmodifikation durchzuführen. Windows CE Das Windows für PDAs enthält lei nur einen Netzwerkstack nach Winsock 1.1 Spezifikation und ist daher nicht geeignet hier vorgestellten Softwaremodule zu nutzen. PDAs können also nur indirekt von ser Systemarchitektur profitieren, in dem sie einen Server ansteuern welcher mit einem anen monen Windows-Versionen arbeitet. Windows 2000/XP/2003 Diese Systemarchitektur ist für Windows 2000 und Windows XP entworfen worden. Daher ist es selbstverständlich für Benutzung mit Windows 2000 und Windows XP geeignet. Windows 2003 als neuere Windows-Version war bereits im letzten Unterkapitel Thema und ist auch geeignet.

63 Portierbarkeit hier beschriebenen Ideen auf ane Platformen Zuletzt noch einige Gedanken zur Umsetzung Ideen, hinter hier beschriebenen Systemarchitektur, auf ane Platformen als aktuelle Windows Versionen. Winsock 1.1 Die Winsock 1.1 Spezifikation enthält keine dokumentierte Schnittstelle zur Erweiterung Fähigkeiten Winsock DLL. Insbesone existiert das Konzept eines Layered Service Provi nicht (siehe [TA04]). Dies ist erst in Spezifikation Winsock 2.2 enthalten. Es wären allenfalls Lösungen denkbar Winsock DLL durch eine eigne Version ersetzen. Dies gilt nicht für Winsock 1.1 Anwendungen auf einem Windows mit Winsock 2.2 DLL. In sem Falle wird das Winsock 1.1 API nur zu Kompatibiltätszwecken genutzt. Die Winsock 1.1 DLL auf einem System mit Winsock 2.2 übersetzt Winsock 1.1 Aufrufe nur in Winsock 2.2 API-Aufrufe. Es wird also auf Systemen mit Winsock 2.2 DLL auch bei Verwendung des Winsock 1.1 API ein Layered Service Provi benutzt. Siehe auch Abbildung 4.1. Der oben beschriebene Sachverhalt gilt nur für Windows Versionen ausschließlich MSDOS Winsock und 1.1 Windows DLL installiert bis haben. Version 3.11 Für MSDOS und Windows bis einschließlich Version 3.11 existiert kein standardisierter Netzwerkstapel. Dies ist allerdings für das Finden eines wirklich zuverlässigen Weges nützlich, um in sen Netzwerkstabel Active Network Funktionalistät einzubauen. Die vorhandenen propritären Netzwerkstabel für se Betriebsysteme sind primär dafür gedacht Netzwerkclients Betriebsysteme, auch mit sen nicht alten Betriebsystemen von zu betreiben. Microsoft stammen Die Ideen hinter ser Arbeit lassen sich am leichtesten auf Betriebsysteme portieren, bereits eine standardisierte Schnittstelle zur Erweiterung des Netzwerkstabels haben. Betriebsysteme mit Netzwerkfunktionalität einem enthält, monolytischen würden wohl Kernel einen (z.b. Linux), Kernelpatch auch benötigen, um Schnittstellen zur Realisierung von Active Network Funktionalistät bereitstellen zu können. Da s nicht Gegenstand ser Arbeit ist, werde ich daher nicht weiter eingehen.

64 5 Zusammenfassung 64 5 Zusammenfassung Active Networks erlauben im Gegensatz zu herkömmlichen passiven Netzwerkumgebungen Anpassung Daten an zur Verfügung stehende Bandbreite. Dies bietet insbesone bei Übertragung von Multimediadaten Vorteile. Dies gilt besons bei Verwendung von Netzwerkclients mit geringer Bandbreite z.b. Multimedia-Mobiltelefone. Gewöhnliche Active Networks setzen dabei auf mehr o weniger intelligente Router, welche Active Network Datenpakete anpassen. Da hierbei Router unter Umständen fremden und damit nicht vertrauenswürdigen Programmcode ausführen müssen gibt es erhebliche Vorbehalte gegenüber ser Idee. Als Alternative zu intelligenten Routern gibt es Idee Application Layer Active Networks. Diese beinhalten keine intelligenten Router sonn realisieren ihre Active Network Funktionalität durch Anpassung zu sendenen Datenpakete auf dem Netzwerkserver. In ser vorliegenden Arbeit wurde ein solches System für Windows 2000 und Windows XP entwickelt. Dieses setzt auf das für sen Zweck sehr gut geeignete Konzept Layered Service Provi auf. Dies ist ein wichtiger Teil Windows Sockets 2.0 Architektur. Diese Architektur erlaubt fast beliebige Erweiterungen Funktionalität Winsock DLL mit Hilfe genannten Layered Service Provi. Als Vorteil ser Treiberart gegenüber weiteren zu Erweiterungszwecken benutzbaren Treibern ist zu sehen, das Layered Service Provi keine Neuerstellung von Netzwerkpakethean erforlich machen. Dies erlaubte Realisierung eines Systems das fast unabhängig von verwendeten Netzwerkprotokollen gewünschte Funktionalität bereitstellt. Einzig später in den Netzwerkpakethean unterzubringenden Informationen müssen gelesen werden um eigentlichen Daten ädaquat anpassen zu können. Um s umzusetzen ist das in ser Arbeit entwickelte und vorgestellte Active Network System modular aufgebaut. Alle protokoll- o datenabhängigen Teile können durch ane Teile ausgetauscht o mit weiteren Modulen ergänzt werden. Dies erlaubte eine fast unbegrenzte Erweiterbarkeit auf neue o schon vorhandene, aber in ser Arbeit noch nicht realisierte Protokolle.

65 6 Anhänge 65 6 Anhänge Hier noch einige zusätzliche Materialien für den Gesamtzusammenhang Active Networks 6.1 Active nützlich Network Encapsulation sind. Protocol (ANEP) TypeID Das Active Network Encapsulation Protocol (ANEP) verwendet zur Unterscheidung verschiedenen Active Network Verfahren sogenannte TypeIDs. Diese sind bei Active Networks Assigned Number Authority (ANANA, ) registriert. Unter [AN04] findet sich folgene Liste mit bereits registrierten TypeIDs: Assigned TypeIds: # Org Reserved for future use (Reserved) UKans UKans UKans UKans User packets Management packets Test TypeId 1 Test TypeId ISI ISI ISI Active signaling tests Active signaling tests Active signaling tests 18 MIT ANTS UPenn UPenn UPenn UPenn PLAN Reserved-1 Reserved-2 Reserved-3 23 Reserved BBN BBN BBN BBN BBN Reserved 31 Columbia Columbia Columbia Columbia Columbia NetScript program deployment packets NetScript packet traffic NetScript management traffic Reserved-1 Reserved U U U U U ANTS ANTS ANTS ANTS ANTS of of of of of Purpose Spanner CENCOMM CENCOMM CENCOMM CENCOMM Washington Washington Washington Washington Washington

66 6 Anhänge TASC/UMass TASC/UMass TASC/UMass TASC/UMass Reserved Reserved 47 MIT DS Reserved SRI SRI SRI SRI SRI Reserved Lucent Reserved LORIA LORIA LORI LORIA LORIA 75 Reserved 77 ICSI Berkeley Reserved ETH Zurich ETH Zurich Reserved 86 Wash U, StL Reserved Com 3Com 3Com 3Com Reserved UPenn UPenn UPenn UPenn Multicast data packets Multicast control packets Multicast session packets Reserved ANCORS daemon Reserved-1 Reserved-2 Reserved-3 Reserved-4 ANAIS ANAIS ANAIS ANAIS ANAIS - Management1 Management2 Data Multicast reserved MO messengers Anet Anet simulation DAN 3Com 3Com 3Com 3Com Experimental Experimental Experimental Experimental SANE/OS SANE/OS SANE/OS SANE/OS Reserved ICU Korea ICU Korea ICU Korea Reserved CMU ANGLE testbed ANGLE testbed ANGLE testbedd CS.CMU (ref. Christopher Lin)

67 6 Anhänge Utah antsr Reserved ISI ASP EE 140 ISI/TASC Team 1 Demo Technion DIAN system 6.2 Die Protokolle TCP/IP Protokollfamilie Abbildung 6.1 zeigt verschiedenen Schichten TCP/IP-Protokollfamilie. Schicht 1 und 2 sind dabei hardwäreabhängigen Schichten eigentlich nicht zu TCP/IP gehören, da TCP/IP hier auf se aufsetzt. Schicht 3 beinhaltet in erster Linie das Internetprotokoll IP, auf welches Schicht 4 Protokolle (TCP und UDP) aufsetzen. Im Gegensatz zum OSI-Reverenzmodell beinhaltet TCP/IP-Protokollfamilie keine Schicht 5 und 6. Die Anwendungsprotokolle auf Schicht 7 setzen direkt auf Schicht 4 Protokolle auf. Abbildung 6.1 Die TCP/IP Protokollfamilie (aus [SY04])

Diplomarbeit. Zur Erlangung des akademischen Grades Diplom-Ingenieur

Diplomarbeit. Zur Erlangung des akademischen Grades Diplom-Ingenieur Diplomarbeit Zur Erlangung des akademischen Grades Diplom-Ingenieur Entwicklung eines Netzwerk-Interface zur Steuerung der Datenkommunikation einer Netzwerkkarte Angefertigt von Martin Wodrich bei Prof.

Mehr

Application Layer Active Network

Application Layer Active Network Folie 1 Application Layer Active Network Vortrag zur Diplomarbeit Entwicklung eines Netzwerk-Interface zur Steuerung der Datenkommunikation einer Netzwerkkarte geschrieben und gehalten von Martin Wodrich

Mehr

Projekt: Web-Server. Foliensatz 9: Projekt Folie 1. Hans-Georg Eßer, TH Nürnberg Systemprogrammierung, Sommersemester 2014

Projekt: Web-Server. Foliensatz 9: Projekt Folie 1. Hans-Georg Eßer, TH Nürnberg Systemprogrammierung, Sommersemester 2014 Sep 19 14:20:18 amd64 sshd[20494]: Accepted rsa for esser from ::ffff:87.234.201.207 port 61557 Sep 19 14:27:41 amd64 syslog-ng[7653]: STATS: dropped 0 Sep 20 01:00:01 amd64 /usr/sbin/cron[29278]: (root)

Mehr

Verteilte Systeme - Java Networking (Sockets) -

Verteilte Systeme - Java Networking (Sockets) - Verteilte Systeme - Java Networking (Sockets) - Prof. Dr. Michael Cebulla 30. Oktober 2014 Fachhochschule Schmalkalden Wintersemester 2014/15 1 / 36 M. Cebulla Verteilte Systeme Gliederung Grundlagen TCP/IP

Mehr

Netzwerk-Programmierung in C

Netzwerk-Programmierung in C 1 / 26 Netzwerk-Programmierung in C Oliver Bartels Fachbereich Informatik Universität Hamburg 2 Juli 2014 2 / 26 Inhaltsverzeichniss 1 IPv4 und IPv6 Wie werden Daten verschickt? 2 3 Verbindungsaufbau ohne

Mehr

LAN & Internet. Grundlagen Netzwerke LAN-2. Saarpfalz-Gymnasium. Router. Router LAN-3. Router. Kommunikation in Rechnernetzen

LAN & Internet. Grundlagen Netzwerke LAN-2. Saarpfalz-Gymnasium. Router. Router LAN-3. Router. Kommunikation in Rechnernetzen Kommunikation in Rechnernetzen Grundlagen Netzwerke Als Folge des Sputnik-Schocks 1957 wurde Ende der 60er-Jahre von einer Projektgruppe des amerikanischen Verteidigungsministeriums (ARPA) ein Computer-Netz

Mehr

Netzwerk-Programmierung. Netzwerke. Alexander Sczyrba Michael Beckstette.

Netzwerk-Programmierung. Netzwerke. Alexander Sczyrba Michael Beckstette. Netzwerk-Programmierung Netzwerke Alexander Sczyrba Michael Beckstette {asczyrba,mbeckste}@techfak.uni-bielefeld.de 1 Übersicht Netzwerk-Protokolle Protkollfamilie TCP/IP Transmission Control Protocol

Mehr

Verteidigung der Diplomarbeit 3D-Netzwerk-Visualisierung

Verteidigung der Diplomarbeit 3D-Netzwerk-Visualisierung 1 Verteidigung der Diplomarbeit 3D-Netzwerk-Visualisierung Stefan Ziegler 11. März 2005 INHALTSVERZEICHNIS 2 Inhaltsverzeichnis 1 Aufgabe 3 2 Umsetzung 4 3 Struktur 5 4 Paketverarbeitung 8 5 Grafische

Mehr

Rechnernetze Übung 11. Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juni 2012

Rechnernetze Übung 11. Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juni 2012 Rechnernetze Übung 11 Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juni 2012 IP: 192.168.43.9 MAC: 02-55-4A-89-4F-47 IP: 216.187.69.51 MAC: 08-48-5B-77-56-21 1 2 IP: 192.168.43.15 MAC:

Mehr

Client-Server mit Socket und API von Berkeley

Client-Server mit Socket und API von Berkeley Client-Server mit Socket und API von Berkeley L A TEX Projektbereich Deutsche Sprache Klasse 3F Schuljahr 2015/2016 Copyleft 3F Inhaltsverzeichnis 1 NETZWERKPROTOKOLLE 3 1.1 TCP/IP..................................................

Mehr

Netzwerk-Programmierung. Netzwerke.

Netzwerk-Programmierung. Netzwerke. Netzwerk-Programmierung Netzwerke Alexander Sczyrba Michael Beckstette {asczyrba,mbeckste}@techfak.uni-bielefeld.de Übersicht Netzwerk-Protokolle Protkollfamilie TCP/IP Transmission Control Protocol (TCP)

Mehr

Netzwerke. Netzwerk-Programmierung. Sven Hartmeier.

Netzwerke. Netzwerk-Programmierung. Sven Hartmeier. Netzwerk-Programmierung Netzwerke Sven Hartmeier shartmei@techfak.uni-bielefeld.de Übersicht Netzwerk-Protokolle Protokollfamilie TCP/IP Transmission Control Protocol (TCP) erste Schritte mit sockets Netzwerk-Programmierung

Mehr

UDP User Datagramm Protokoll

UDP User Datagramm Protokoll UDP User Datagramm Protokoll Marco Gerland Janina de Jong Internet Protokolle WS 03 / 04 1/31 Einführung IP Datagramme werden durchs Internet geroutet abh. von der IP Adresse Anhand der Ziel IP Adresse

Mehr

Themen. Transportschicht. Internet TCP/UDP. Stefan Szalowski Rechnernetze Transportschicht

Themen. Transportschicht. Internet TCP/UDP. Stefan Szalowski Rechnernetze Transportschicht Themen Transportschicht Internet TCP/UDP Transportschicht Schicht 4 des OSI-Modells Schicht 3 des TCP/IP-Modells Aufgaben / Dienste: Kommunikation von Anwendungsprogrammen über ein Netzwerk Aufteilung

Mehr

Das Internet-Protocol. Aufteilung von Octets. IP-Adressformat. Class-A Netzwerke. Konventionen für Hostadressen

Das Internet-Protocol. Aufteilung von Octets. IP-Adressformat. Class-A Netzwerke. Konventionen für Hostadressen Das Internet-Protocol Das Internet Protocol (IP) geht auf das Jahr 1974 zurück und ist die Basis zur Vernetzung von Millionen Computern und Geräten weltweit. Bekannte Protokolle auf dem Internet Protokoll

Mehr

Rechnernetze Übung 11

Rechnernetze Übung 11 Rechnernetze Übung 11 Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juli 2011 Herr Müller (Test GmbH) Sekretärin (Super AG) T-NR. 111 T-NR. 885 Sekretärin (Test GmbH) Herr Meier (Super

Mehr

PROJEKTIEREN DER HW UND DER VERBINDUNGEN...

PROJEKTIEREN DER HW UND DER VERBINDUNGEN... Inhaltsverzeichnis 1 PROJEKTIEREN DER HW UND DER VERBINDUNGEN... 2 1.1 KONFIGURATION DER HW... 2 1.2 KONFIGURATION DER VERBINDUNGEN... 3 1.2.1 Konfiguration UDP- Verbindung...3 1.2.2 Konfiguration TCP

Mehr

S.M. Hartmann GmbH IT Solutions

S.M. Hartmann GmbH IT Solutions S.M. Hartmann GmbH 82008 Unterhaching Prager Straße 7 www.smhsoftware.de S.M. Hartmann GmbH IT Solutions Software für den modernen Handel SMH-Connect/400 Version V6.0 Beschreibung SMH-Connect: iseries

Mehr

Übung - Mit Wireshark eine UDP-DNS-Aufzeichnung untersuchen

Übung - Mit Wireshark eine UDP-DNS-Aufzeichnung untersuchen Übung - Mit Wireshark eine UDP-DNS-Aufzeichnung untersuchen Topologie Lernziele Teil 1: Wireshark für das Erfassen von Paketen vorbereiten Auswahl einer geeigneten Netzwerk-Schnittstelle, um Pakete zu

Mehr

1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells.

1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells. Übung 7 1.) Nennen Sie Aufgaben und mögliche Dienste der Transportschicht (Transport Layer) des ISO/OSI-Schichtenmodells. 2.) Charakterisieren Sie kurz das User Datagram Protokoll (UDP) aus der Internetprotokollfamilie

Mehr

II

II II I II I II I II I Bei der Kommunikation zwischen Rechnern sind bestimmte Regeln notwendig, die vor allem die Datenformate und deren zeitliche Reihenfolge festlegen. Diese Regeln werden als Kommunikationsprotokolle

Mehr

Wo geht's lang: I Ro R u o t u i t n i g

Wo geht's lang: I Ro R u o t u i t n i g Wo geht's lang: IP Routing Inhalt Was ist Routing? Warum ist Routing notwendig? Funktion von IP-Routing: -TCP/IP zur Kommunikation im Internet -IP-Datagramme -Was ist ein IP-Router? Inhalt Routingprotokolle:

Mehr

Netzwerkprogrammierung unter Linux und UNIX

Netzwerkprogrammierung unter Linux und UNIX Netzwerkprogrammierung unter Linux und UNIX Bearbeitet von Stefan Fischer, Walter Müller 2. Auflage 1999. Buch. XII, 228 S. Hardcover ISBN 978 3 446 21093 6 Format (B x L): 14 x 20,9 cm Gewicht: 329 g

Mehr

Verteilte Systeme - 1. Übung

Verteilte Systeme - 1. Übung Verteilte Systeme - 1. Übung Dr. Jens Brandt Sommersemester 2011 1. Rechnerverbünde Kommunikationsverbund: Beispiele: E-Mail (SMTP, POP/IMAP), Instant Messaging (XMPP, IRC, ICQ,...), Newsgroups (NNTP)

Mehr

Verteilte Systeme - Java Networking (Sockets) 2 -

Verteilte Systeme - Java Networking (Sockets) 2 - Verteilte Systeme - Java Networking (Sockets) 2 - Prof. Dr. Michael Cebulla 06. November 2014 Fachhochschule Schmalkalden Wintersemester 2014/15 1 / 30 Michael Cebulla Verteilte Systeme Gliederung Wiederholung:

Mehr

Administrator-Anleitung

Administrator-Anleitung Administrator-Anleitung für die Typ 1 Installation der LEC-Web-Anwendung auf einem Microsoft Windows XP / VISTA Rechner (Einzelplatz) Ansprechpartner für Fragen zur Software: Zentrum für integrierten Umweltschutz

Mehr

Folgen Sie diesen Anweisungen Schritt für Schritt, um das ZETA DLMS-Terminal 2011 zu installieren und in Betrieb zu nehmen.

Folgen Sie diesen Anweisungen Schritt für Schritt, um das ZETA DLMS-Terminal 2011 zu installieren und in Betrieb zu nehmen. Kurzanleitung ZETA DLMS-Terminal 2011 Folgen Sie diesen Anweisungen Schritt für Schritt, um das ZETA DLMS-Terminal 2011 zu installieren und in Betrieb zu nehmen. 1. Installation des ZETA DLMS-Terminals

Mehr

Rechnern netze und Organisatio on

Rechnern netze und Organisatio on Rechnernetze und Organisation Assignment A3 Präsentation 1 Motivation Übersicht Netzwerke und Protokolle Rechnernetze und Organisatio on Aufgabenstellung: Netzwerk-Protokoll-Simulator 2 Motivation Protokoll-Simulator

Mehr

Technische Dokumentation RouterInfo

Technische Dokumentation RouterInfo Technische Dokumentation RouterInfo Version 1.0 Daut Musolli und Alexander Rieke Inhalt Einleitung... 1 Technische Details... 1 Konsolenanwendung... 1 Klassendiagramm... 2 Klassen... 2 Grafische Benutzeroberfläche...

Mehr

HowTo: VPN mit PPTP und dem Windows VPN-Client Version 2007nx Release 3

HowTo: VPN mit PPTP und dem Windows VPN-Client Version 2007nx Release 3 Inhalt 1 Konfiguration der Appliance... 4 1.1 Erstellen von Netzwerkobjekten im Securepoint Security Manger... 4 1.2 Erstellen von Firewall-Regeln... 5 1.3 PPTP-Konfiguration... 6 1.4 Benutzer einrichten...

Mehr

SNMP und der MIB- Browser von MG-Soft

SNMP und der MIB- Browser von MG-Soft SNMP und der MIB- Browser von MG-Soft 1. SNMP 1.1 Was ist SNMP 1.2 Historie von SNMP 1.3 Einordnung in das OSI-Modell 1.4 Die Architektur von SNMP 1.5 Kommunikation von SNMP 1.6 SNMP-PDUs PDUs 2. MIB und

Mehr

Netzwerk Linux-Kurs der Unix-AG

Netzwerk Linux-Kurs der Unix-AG Netzwerk Linux-Kurs der Unix-AG Benjamin Eberle 13. Juli 2016 Netzwerke mehrere miteinander verbundene Geräte (z. B. Computer) bilden ein Netzwerk Verbindung üblicherweise über einen Switch (Ethernet)

Mehr

Grundlagen der Rechnernetze. Internetworking

Grundlagen der Rechnernetze. Internetworking Grundlagen der Rechnernetze Internetworking Übersicht Grundlegende Konzepte Internet Routing Limitierter Adressbereich SS 2012 Grundlagen der Rechnernetze Internetworking 2 Grundlegende Konzepte SS 2012

Mehr

WindowsPro Windows, Virtualisierung und Cloud für Profis

WindowsPro Windows, Virtualisierung und Cloud für Profis WindowsPro Windows, Virtualisierung und Cloud für Profis Lizenzen am Terminal-Server mit NetMan Desktop Manager verwalten Andrej Radonic, 02.07.2013 Bei vielen Softwareherstellern gelten komplexe Lizenzbedingungen,

Mehr

ARP, ICMP, ping. Jörn Stuphorn Bielefeld, den 4. Mai Mai Universität Bielefeld Technische Fakultät

ARP, ICMP, ping. Jörn Stuphorn Bielefeld, den 4. Mai Mai Universität Bielefeld Technische Fakultät ARP, ICMP, ping Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät TCP/IP Data Link Layer Aufgabe: Zuverlässige Übertragung von Rahmen über Verbindung Funktionen: Synchronisation,

Mehr

TCP/IP-Protokollfamilie

TCP/IP-Protokollfamilie TCP/IP-Protokollfamilie Internet-Protokolle Mit den Internet-Protokollen kann man via LAN- oder WAN kommunizieren. Die bekanntesten Internet-Protokolle sind das Transmission Control Protokoll (TCP) und

Mehr

shri Raw Sockets Prof. Dr. Ch. Reich

shri Raw Sockets Prof. Dr. Ch. Reich shri Raw Sockets Prof. Dr. Ch. Reich Szenario: Verschicken einer gespooften Ping-Message IP-Source-Adresse ist Adresse des Opfers Nachrichtenformat: IP-Header (normal, außer IP-Source-Address ist einstellbar)

Mehr

Browser mit SSL und Java, welcher auf praktisch jedem Rechner ebenso wie auf vielen mobilen Geräten bereits vorhanden ist

Browser mit SSL und Java, welcher auf praktisch jedem Rechner ebenso wie auf vielen mobilen Geräten bereits vorhanden ist Collax SSL-VPN Howto Dieses Howto beschreibt wie ein Collax Server innerhalb weniger Schritte als SSL-VPN Gateway eingerichtet werden kann, um Zugriff auf ausgewählte Anwendungen im Unternehmensnetzwerk

Mehr

Sicherheitsdienste für große Firmen => Teil 2: Firewalls

Sicherheitsdienste für große Firmen => Teil 2: Firewalls Seite 21 Sicherheitsdienste für große Firmen => Teil 2: Firewalls Sicherer Zugang zum World Wide Web (HTTP, FTP etc.) Sicherer Übergang zum Internet: Firewalls und Intrusion Detection Verzeichnisdienste

Mehr

Protokolle des IPX/SPX-Pakets

Protokolle des IPX/SPX-Pakets Protokolle des IPX/SPX-Pakets Das IPX-Protokoll Das SPX-Protokoll Zweck von IPX und SPX IPX-Adressen zuweisen IPX/SPX und das OSI-Modell Distanzvektor-Routing: RIP & SAP Verbindungszustand-Routing: NLSP

Mehr

Modul 123. E-Mail und FTP. Unit 6. E-Mail (pop / smtp), FTP (activ/passive Mode) FTP-Server mit Microsofts IIS

Modul 123. E-Mail und FTP. Unit 6. E-Mail (pop / smtp), FTP (activ/passive Mode) FTP-Server mit Microsofts IIS Modul 123 Unit 6 (V1.1) E-Mail und FTP Zielsetzung: E-Mail (pop / smtp), FTP (activ/passive Mode) FTP-Server mit Microsofts IIS Technische Berufschule Zürich IT Seite 1 Grundlagen : Das Store-and-Forward

Mehr

Systemanforderungen Manufacturing Execution System fabmes

Systemanforderungen Manufacturing Execution System fabmes Manufacturing Execution System fabmes Das Manufacturing Execution System fabmes bemüht sich trotz hoher Anforderungen an die Datenverarbeitung möglichst geringe Anforderungen an die Hardware zu stellen.

Mehr

Frank Nussbächer. IP-Tables. Was sind IP-Tables? Unterschied zwischen IP-Tables und IP-Chains

Frank Nussbächer. IP-Tables. Was sind IP-Tables? Unterschied zwischen IP-Tables und IP-Chains IP-Tables Was sind IP-Tables? Unterschied zwischen IP-Tables und IP-Chains Auf den ersten Blick scheinen ipchains und IP-Tables fast ähnlich. Beide Methoden verwenden für die Paketfilterung Regelketten,

Mehr

Grundlagen Firewall und NAT

Grundlagen Firewall und NAT Grundlagen Firewall und NAT Was sind die Aufgaben einer Firewall? Welche Anforderungen sind zu definieren? Grundlegende Funktionsweise Technische Varianten NA[P]T Portmapping Übungsaufgabe Quellen im WWW

Mehr

Microsoft ISA Server 2004

Microsoft ISA Server 2004 Microsoft ISA Server 2004 Marcel Zehner Leitfaden für Installation, Einrichtung und Wartung ISBN 3-446-40597-6 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-40597-6

Mehr

Übungsblatt 4. (Router, Layer-3-Switch, Gateway) Aufgabe 2 (Kollisionsdomäne, Broadcast- Domäne)

Übungsblatt 4. (Router, Layer-3-Switch, Gateway) Aufgabe 2 (Kollisionsdomäne, Broadcast- Domäne) Übungsblatt 4 Aufgabe 1 (Router, Layer-3-Switch, Gateway) 1. Welchen Zweck haben Router in Computernetzen? (Erklären Sie auch den Unterschied zu Layer-3-Switches.) 2. Welchen Zweck haben Layer-3-Switches

Mehr

Internet Routing am 14. 11. 2006 mit Lösungen

Internet Routing am 14. 11. 2006 mit Lösungen Wissenstandsprüfung zur Vorlesung Internet Routing am 14. 11. 2006 mit Lösungen Beachten Sie bitte folgende Hinweise! Dieser Test ist freiwillig und geht in keiner Weise in die Prüfungsnote ein!!! Dieser

Mehr

Adressierung eines Kommunikationspartners in der TCP/IP-Familie

Adressierung eines Kommunikationspartners in der TCP/IP-Familie Adressierung eines Kommunikationspartners in der TCP/IP-Familie! Wenn Daten geroutet werden, müssen sie: 1. zu einem bestimmten Netzwerk 2. zu einem bestimmten Host in diesem Netzwerk 3. zu einem bestimmten

Mehr

.NET Networking 1. Proseminar Objektorientiertes Programmieren mit.net und C# Matthias Jaros. Institut für Informatik Software & Systems Engineering

.NET Networking 1. Proseminar Objektorientiertes Programmieren mit.net und C# Matthias Jaros. Institut für Informatik Software & Systems Engineering .NET Networking 1 Proseminar Objektorientiertes Programmieren mit.net und C# Matthias Jaros Institut für Informatik Software & Systems Engineering Agenda Motivation Protokolle Sockets Anwendung in.net

Mehr

UDP-, MTU- und IP- Fragmentierung

UDP-, MTU- und IP- Fragmentierung UDP-, MTU- und IP- Fragmentierung Jörn Stuphorn stuphorn@rvs.uni-bielefeld.de Universität Bielefeld Technische Fakultät Stand der Veranstaltung 13. April 2005 Unix-Umgebung 20. April 2005 Unix-Umgebung

Mehr

Vorlesung SS 2001: Sicherheit in offenen Netzen

Vorlesung SS 2001: Sicherheit in offenen Netzen Vorlesung SS 2001: Sicherheit in offenen Netzen 2.2 Transmission Control Protocol - TCP 2.3 User Datagram Protocol - UDP Prof. Dr. Christoph Meinel Informatik, Universität Trier & Institut für Telematik,

Mehr

Client-Server-Prinzip

Client-Server-Prinzip Client-Server-Prinzip Kommunikation im Internet erfolgt nach dem Client-Server-Prinzip: Client sendet eine Anfrage (fordert eine Dienstleistung an) Server sendet die Antwort (bietet eine Dienstleistung

Mehr

Installation LehrerConsole (Version 7.2)

Installation LehrerConsole (Version 7.2) Dr. Kaiser Systemhaus GmbH Köpenicker Straße 325 12555 Berlin Telefon: (0 30) 65 76 22 36 Telefax: (0 30) 65 76 22 38 E-Mail: info@dr-kaiser.de Internet: www.dr-kaiser.de Installation LehrerConsole (Version

Mehr

ESTOS XMPP Proxy

ESTOS XMPP Proxy ESTOS XMPP Proxy 4.1.12.22953 4.1.12.22953 1 Willkommen zum ESTOS XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Diagnose... 6 1.4 Proxy Dienst... 6 1.5 Server-Zertifikat...

Mehr

ESTOS XMPP Proxy

ESTOS XMPP Proxy ESTOS XMPP Proxy 4.1.18.27533 4.1.18.27533 1 Willkommen zum ESTOS XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Diagnose... 6 1.4 Proxy Dienst... 6 1.5 Server-Zertifikat...

Mehr

Site-To-Site VPN Anleitung IAAS Smart <-> IAAS Premium. Version: 1.0

Site-To-Site VPN Anleitung IAAS Smart <-> IAAS Premium. Version: 1.0 Site-To-Site VPN Anleitung IAAS Smart IAAS Premium Version: 1.0 Inhaltsverzeichnis Inhaltsverzeichnis... ii 1 Einleitung... 3 2 Vorraussetzungen... 4 2.1 IPFire Firewall... 4 2.2 vcloud Director...

Mehr

An Open Interface for Network Programming under Microsoft Windows. DI. Dr. Peter René Dietmüller

An Open Interface for Network Programming under Microsoft Windows. DI. Dr. Peter René Dietmüller Windows Sockets An Open Interface for Network Programming under Microsoft Windows DI. Dr. Peter René Dietmüller Institut für Informationsverarbeitung und Mikroprozessortechnik Johannes Kepler Universität

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

Alternative Architekturkonzepte

Alternative Architekturkonzepte Alternative Architekturkonzepte Motivation: Suche nach einer Gesamtstruktur meistens: dominante nichtfunktionale Eigenschaften legen Architektur fest Antrieb: Architekturziel Ziel: globale Betrachtung

Mehr

Transmission Control Protocol (TCP)

Transmission Control Protocol (TCP) Transmission Control Protocol (TCP) Verbindungsorientiertes Protokoll, zuverlässig, paketvermittelt stream-orientiert bidirektional gehört zur Transportschicht, OSI-Layer 4 spezifiziert in RFC 793 Mobile

Mehr

Modul 117. OSI-Referenzmodell

Modul 117. OSI-Referenzmodell Modul 117 Modulbezeichnung: Kompetenzfeld: Kompetenz: - und Netzinfrastruktur für ein kleines Unternehmen realisieren Network Management 6.3. Kennt den Zweck und die Funktion der Schichtenmodelle( OSI

Mehr

Service & Support. Vergabe der IP-Adresse über die serielle Schnittstelle und Zugriff auf das Web Based Management (WBM)

Service & Support. Vergabe der IP-Adresse über die serielle Schnittstelle und Zugriff auf das Web Based Management (WBM) Deckblatt Vergabe der IP-Adresse über die serielle Schnittstelle und Zugriff auf das Web Based Management (WBM) OSM (Optical Switch Module) / ESM (Electrical Switch Module) FAQ Juni 2011 Service & Support

Mehr

Netzwerktechnologien 3 VO

Netzwerktechnologien 3 VO Netzwerktechnologien 3 VO Univ.-Prof. Dr. Helmut Hlavacs helmut.hlavacs@univie.ac.at Dr. Ivan Gojmerac gojmerac@ftw.at Bachelorstudium Medieninformatik SS 2012 Kapitel 3 Transportschicht 3.1 Dienste der

Mehr

Phion Netfence Firewall Mag. Dr. Klaus Coufal

Phion Netfence Firewall Mag. Dr. Klaus Coufal Phion Netfence Firewall Mag. Dr. Klaus Coufal Übersicht I. Konzepte II. Installation und Konfiguration III. High Availability IV. Firewall V. VPN Server VI. Management Center VII. Addons Mag. Dr. Klaus

Mehr

Themenschwerpunkt: Rechnernetze und Netzwerkdesign

Themenschwerpunkt: Rechnernetze und Netzwerkdesign Themenschwerpunkt: Rechnernetze und Netzwerkdesign Aufgabe 1: Nennen Sie den wesentlichen Vorteil eines Netzwerkes mit Bus-Topologie? Lösung: Wesentlicher Vorteil der Bus-Topologie ist der geringe Verkabelungsaufwand

Mehr

2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen

2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen 2. Kommunikation und Synchronisation von Prozessen 2.2 Kommunikation zwischen Prozessen Dienste des Internets Das Internet bietet als riesiges Rechnernetz viele Nutzungsmöglichkeiten, wie etwa das World

Mehr

IP Internet Protokoll

IP Internet Protokoll IP Internet Protokoll Adressierung und Routing fürs Internet von Stephan Senn Inhalt Orientierung: Die Netzwerkschicht (1min) Aufgabe des Internet Protokolls (1min) Header eines Datenpakets (1min) Fragmentierung

Mehr

EIBPORT 3 VPN SSL Nutzung mit OpenVPN-Client

EIBPORT 3 VPN SSL Nutzung mit OpenVPN-Client BAB TECHNOLOGIE GmbH EIBPORT 3 VPN SSL Nutzung mit OpenVPN-Client Datum: 11. Oktober 2016 DE BAB TECHNOLOGIE GmbH 1 OPTIMALE DATENSICHERHEIT Um bei Internet-Zugriffen auf EIBPORT 3 eine ausreichende Datensicherheit

Mehr

Vorlesung SS 2001: Sicherheit in offenen Netzen

Vorlesung SS 2001: Sicherheit in offenen Netzen Vorlesung SS 2001: Sicherheit in offenen Netzen 2.1 Internet Protocol - IP Prof. Dr. Christoph Meinel Informatik, Universität Trier & Institut für Telematik, Trier Prof. Dr. sc. nat. Christoph Meinel,

Mehr

ISA Server 2004 IP-Einstellungen definieren - Von Marc Grote

ISA Server 2004 IP-Einstellungen definieren - Von Marc Grote Seite 1 von 6 ISA Server 2004 IP-Einstellungen definieren - Von Marc Grote Die Informationen in diesem Artikel beziehen sich auf: Microsoft ISA Server 2004 Einleitung ISA Server 2004 bietet die Option

Mehr

TCP/UDP. Transport Layer

TCP/UDP. Transport Layer TCP/UDP Transport Layer Lernziele 1. Wozu dient die Transportschicht? 2. Was passiert in der Transportschicht? 3. Was sind die wichtigsten Protkolle der Transportschicht? 4. Wofür wird TCP eingesetzt?

Mehr

Installation von MS SQL-Server 2014 Express

Installation von MS SQL-Server 2014 Express ALGE 2016 SQL Server Installation Inhaltsverzeichnis Installation von MS SQL-Server 2014 Express...1 Datenbank für Remote- Zugriff vorbereiten...6 Windows Firewall Konfiguration...9 Falls Sie ein Englischsprachiges

Mehr

Konfigurationsanleitung Access Control Lists (ACL) Funkwerk. Copyright Stefan Dahler - www.neo-one.de 13. Oktober 2008 Version 1.0.

Konfigurationsanleitung Access Control Lists (ACL) Funkwerk. Copyright Stefan Dahler - www.neo-one.de 13. Oktober 2008 Version 1.0. Konfigurationsanleitung Access Control Lists (ACL) Funkwerk Copyright Stefan Dahler - www.neo-one.de 13. Oktober 2008 Version 1.0 Seite - 1 - 1. Konfiguration der Access Listen 1.1 Einleitung Im Folgenden

Mehr

Damit zwischen den verschiedenen Rechnern überhaupt ein Austausch möglich ist, muss man sich über das was und wie verständigen.

Damit zwischen den verschiedenen Rechnern überhaupt ein Austausch möglich ist, muss man sich über das was und wie verständigen. Webanwendungen Protokolle Damit zwischen den verschiedenen Rechnern überhaupt ein Austausch möglich ist, muss man sich über das was und wie verständigen. So wurde eine Sammlung von Vereinbarungen zusammengestellt,

Mehr

Vermittlungsschicht ( network layer )

Vermittlungsschicht ( network layer ) Vermittlungsschicht ( network layer ) ggf. Auswahl eines Subnetzes für die folgende Übertragungsstrecke Auswahl eines guten Transportweges (Routing) im gewählten Subnetz statisch: fest für alle Pakete

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

IP routing und traceroute

IP routing und traceroute IP routing und traceroute Seminar Internet-Protokolle Dezember 2002 Falko Klaaßen fklaasse@techfak.uni-bielefeld.de 1 Übersicht zum Vortrag Was ist ein internet? Was sind Router? IP routing Subnet Routing

Mehr

Python Programmierung. Dipl.-Ing.(FH) Volker Schepper

Python Programmierung. Dipl.-Ing.(FH) Volker Schepper Python Programmierung String Operationen i = 25 text1 = "Ich bin " text2 = " Jahre alt" print (text1 + str(i) + text2) print ("ich bin", i, "Jahre alt") print ("ich bin %s Jahre alt" % i) >>> Ich bin 25

Mehr

Service & Support. Security Status des CP1628 über die Online-Ansicht des Security Configuration Tool (SCT) ermitteln

Service & Support. Security Status des CP1628 über die Online-Ansicht des Security Configuration Tool (SCT) ermitteln Deckblatt Security Status des über die Online-Ansicht des Security Configuration Tool (SCT) ermitteln und Security Configuration Tool FAQ Juli 2012 Service & Support Answers for industry. Fragestellung

Mehr

ProAccess SPACE 3.0. Für weitere Informationen wenden Sie sich bitte an Ihren SALTO Partner oder:

ProAccess SPACE 3.0. Für weitere Informationen wenden Sie sich bitte an Ihren SALTO Partner oder: ProAccess SPACE 3.0 SALTO stellt mit diesem Dokument seinen Kunden und Partnern eine Checkliste für die Netzwerk- und IT-Voraussetzungen der Web-basierten Managementsoftware ProAccess SPACE bereit. Es

Mehr

7. OSI-Modell als Rollenspiel

7. OSI-Modell als Rollenspiel 7.1 Rollen Mit Hilfe eines Rollenspiels soll der gesamte Ablauf der Anfrage einer Webseite bei einem Web-Server dargestellt werden. An einer Web-Anfrage sind folgende Rollen beteiligt: 1. User 2. Browser

Mehr

Faronics System Profiler Standard Benutzerhandbuch

Faronics System Profiler Standard Benutzerhandbuch 1 2 Letzte Anderung: Mai 2009 1999-2009 Faronics Corporation. Alle Rechte vorbehalten. Faronics, Deep Freeze, Faronics Core Console, Faronics Anti-Executable, Faronics Device Filter, Faronics Power Save,

Mehr

AK-Automatisierungs und Kommunikationstechnik TI Technische Informatik. NWT Netzwerktechnik

AK-Automatisierungs und Kommunikationstechnik TI Technische Informatik. NWT Netzwerktechnik Netzwerk Programmierung Ein großer Teil von dem, was Netzwerkprogramme tun ist ganz simpler input und output: also bytes verschieben von einem System zu einem anderen. Bytes bleiben Bytes. Die Daten zu

Mehr

... relevante Ports für Streaming bzw. Remote Control!

... relevante Ports für Streaming bzw. Remote Control! ... relevante Ports für Streaming bzw. Remote Control! Wenn Sie mit der Installation des IO [io] 8000 / 8001 beginnen, ist es am sinnvollsten mit einem minilan zu beginnen, da dies mögliche Fehlrequellen

Mehr

Cablelink. Bedienungsanleitung. to fax

Cablelink. Bedienungsanleitung.  to fax Cablelink Bedienungsanleitung E-mail to fax 1 Inhaltsverzeichnis Einführung 2 Fax-Versand via Druckertreiber 3 Fax-Versand via E-Mail 9 Faxbericht 12 einführung Mit dem Dienst E-Mail to Fax ist es möglich,

Mehr

HowTo SoftEther Site-2-Site (Client-Bridge)

HowTo SoftEther Site-2-Site (Client-Bridge) HowTo SoftEther Site-2-Site (Client-Bridge) Dieses Beispiel zeigt wie ein Standort (Client-Bridge), mittels Layer 2 des OSI-Schichtmodell, sicher via SoftEther VPN zu einem VPN-Server verbunden wird, um

Mehr

Enterprise JavaBeans Überblick

Enterprise JavaBeans Überblick Enterprise JavaBeans Überblick 1. Überblick Java EE 5 und Komponententechnologien 3. Enterprise JavaBeans Architektur 4. Ressourcen Management und Primäre Services 5. Java Persistence: Entity Manager 6.

Mehr

R-ADSL2+ Einrichthinweise unter Windows 98

R-ADSL2+ Einrichthinweise unter Windows 98 Verwenden Sie einen externen Router? Dann folgen Sie bitte der Anleitung des Routers und NICHT unseren zur Einrichtung einer Internetverbindung unter Windows 98! Mit dieser Installationsanleitung möchten

Mehr

R-ADSL2+ Einrichthinweise unter Windows 98/ME

R-ADSL2+ Einrichthinweise unter Windows 98/ME Verwenden Sie einen externen Router? Dann folgen Sie bitte der Anleitung des Routers und NICHT unseren zur Einrichtung einer Internetverbindung unter Windows 98/ME! Mit dieser Installationsanleitung möchten

Mehr

4. Network Interfaces Welches verwenden? 5. Anwendung : Laden einer einfachen Internetseite 6. Kapselung von Paketen

4. Network Interfaces Welches verwenden? 5. Anwendung : Laden einer einfachen Internetseite 6. Kapselung von Paketen Gliederung 1. Was ist Wireshark? 2. Wie arbeitet Wireshark? 3. User Interface 4. Network Interfaces Welches verwenden? 5. Anwendung : Laden einer einfachen Internetseite 6. Kapselung von Paketen 1 1. Was

Mehr

7 TCP/IP-Dienste konfigurieren

7 TCP/IP-Dienste konfigurieren 7 TCP/IP-Dienste konfigurieren In diesem Kapitel lernen Sie die Begriffe Ports,Sockets und Connections kennen (LPI 1: 109.1). den Zusammenhang der Ports von TCP/IP-Diensten mit der Datei /etc/services

Mehr

Computeranwendung in der Chemie Informatik für Chemiker(innen) 5. Internet

Computeranwendung in der Chemie Informatik für Chemiker(innen) 5. Internet Computeranwendung in der Chemie Informatik für Chemiker(innen) 5. Internet Jens Döbler 2003 "Computer in der Chemie", WS 2003-04, Humboldt-Universität VL5 Folie 1 Dr. Jens Döbler Internet Grundlagen Zusammenschluß

Mehr

IPSec-VPN site-to-site. Zyxel USG Firewall-Serie ab Firmware-Version Knowledge Base KB-3514 September Zyxel Communication Corp.

IPSec-VPN site-to-site. Zyxel USG Firewall-Serie ab Firmware-Version Knowledge Base KB-3514 September Zyxel Communication Corp. Zyxel USG Firewall-Serie ab Firmware-Version 4.20 Knowledge Base KB-3514 September 2016 Zyxel Communication Corp. IPSEC-VPN SITE-TO-SITE Virtual Private Network (VPN) erstellt einen sicheren, verschlüsselten

Mehr

Übung 3 - Ethernet Frames

Übung 3 - Ethernet Frames Übung 3 - Musterlösung 1 Übung 3 - Ethernet Frames Booten Sie auf dem Security-Lab PC das Windows XP Betriebsystem und tätigen Sie ein Login mit: Username: Password: 1 MAC Adressen seclab strongswan Bestimmen

Mehr

Handbuch der Routing-Protokolle

Handbuch der Routing-Protokolle Handbuch der Routing-Protokolle Eine Einführung in RIP, IGRP, EIGRP, HSRP, VRRP, OSPF, IS-IS und BGP Bearbeitet von Wolfgang Schulte Neuerscheinung 2016. Taschenbuch. 305 S. Paperback ISBN 978 3 8007 4066

Mehr

Grundkurs Routing im Internet mit Übungen

Grundkurs Routing im Internet mit Übungen Grundkurs Routing im Internet mit Übungen Falko Dressler, Ursula Hilgers {Dressler,Hilgers}@rrze.uni-erlangen.de Regionales Rechenzentrum der FAU 1 Tag 4 Router & Firewalls IP-Verbindungen Aufbau von IP

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Seminar The Protocols that Run the Internet

Seminar The Protocols that Run the Internet Seminar The Protocols that Run the Internet Internet Security - Anonymous Connections: Onion Routing Inhalte Einleitung Funktionsweise von Onion Routing Fazit 2 Warum Onion Routing Onion Routing entstand

Mehr