Netzwerksimulation/0000755000175000017500000000000010756143355013155 5ustar vogvogNetzwerksimulation/Makefile0000644000175000017500000000116210756145107014612 0ustar vogvogNAME = Netzwerksimulation VIEWPDF = evince custom-default: viewpdf $(NAME).dvi: \ $(patsubst graphics/originals/%.dia,graphics/%.eps,$(wildcard graphics/originals/*.dia)) \ $(patsubst graphics/originals/%.svg,graphics/%.eps,$(wildcard graphics/originals/*.svg)) include /usr/share/latex-mk/latex.gmk graphics/%.eps: graphics/originals/%.dia dia -e $@ $< graphics/%.eps: graphics/originals/%.svg inkscape -E $@ $< $(NAME)/%: % mkdir -p $(dir $@) cp -a $< $@ $(NAME).tgz: $(addprefix $(NAME)/,Makefile $(NAME).tex $(wildcard graphics/originals/*.dia graphics/originals/*.svg)) tar cvv $(NAME) | gzip -9 > $@ Netzwerksimulation/Netzwerksimulation.tex0000644000175000017500000011612610754624252017622 0ustar vogvog\documentclass[fontsize=12pt, paper=a4]{scrartcl} \usepackage{textcomp} \usepackage[dvips]{rotating} \usepackage[latin1]{inputenc} %\usepackage{ngerman} \usepackage[ngerman]{babel} \usepackage[T1]{fontenc} %\usepackage[fixlanguage]{babelbib} \usepackage{graphicx} \usepackage{multicol} \usepackage{hyperref} %\usepackage{fancyhdr} \headheight 70pt \frenchspacing \tolerance 1414 \hbadness 1414 \emergencystretch 1.5em \hfuzz 0.3pt \vfuzz \hfuzz \widowpenalty=10000 \raggedbottom %Now, we define custom keywords \newcommand{\enumlist}[2]{\begin{list}{#2{#1}.} {\usecounter{#1} \partopsep 6pt \topsep 8pt \itemsep 1pt \parsep 0pt \itemindent 0pt}} %End of defining custom keywords %Dokumentbeginn \begin{document} %Wir aktivieren Counter fr die EnumLists \newcounter{Lcount} \newcounter{Lcount2} %Nun beginnt das eigentliche Dokument \date{\today{}} \author{Volker Grabsch \and Martin Schrder} \title{% Netzwerksimulation\\ \large{Projekt im Rahmen der VL "`Grundlagen der Rechnerkommunikation"'}\\ \normalsize{Projektgruppe: Bort} } \maketitle \abstract{% Dieses Dokument beschreibt im Folgenden die grundlegenden Prinzipien und Funktionsweisen des Projektes fr die Vorlesung "`Grundlagen der Rechnerkommunikation"' des Wintersemesters 07/08 der Projektgruppe "`Bort"'. Dies umfasst eine kurze Beschreibung des benutzten Frameworks, gefolgt von der abstrakten Darstellung der verwendeten Algorithmen, geordnet nach den jeweiligen Netzwerkschichten. } \tableofcontents \newpage \section{Framework} Fr das Projekt wurde das C++ Simulationsframework OmNet++ in der Version 3.2 verwendet\footnote{Siehe: \url{http://www.omnetpp.org/}}. Dabei handelt es sich um einen objektorientierten, modularen Netzwerksimulator mit diskretem Ereignismodell\footnote{Wortlaut der OmNet++ Dokumentation entnommen.}. Fr die Zwecke unseres Projektes wurden nur die folgenden Eigenschaften des Frameworks verwendet: \enumlist{Lcount}{\arabic} \item Aufbau eines Graphen mit gerichteten Kanten, d.h. Simplexverbindungen zwischen einzelnen Knoten. Dies wird als Abstraktion fr Netzwerkschichten, Computer, usw. genutzt. \item Transport einer abstrakten Nachricht entlang genau einer Kante / Simplexverbindung, bzw. an den Knoten selbst, u.U. mit Zeitverzgerung. \item Anhngen von C++ Objekten an diese Nachrichten als Abstraktion fr den Inhalt eines Datenpakets. \item Einlesen von Parametern aus der Umgebung in Form von primitiven Datentypen bzw. XML-Dateien. \end{list} All diese Eigenschaften wurden komplett in der Klasse \texttt{Layer} gekapselt\footnote{Siehe Dateien \texttt{Layer.cc} und \texttt{Layer.hpp}.}, womit sich die eigentliche implementierte Funktion der Netzwerkschichten komplett von OmNet++ trennen lsst. Die einzige Ausnahme hiervon sind einige wenige Administrationsfunktionen, die von Omnet vorausgesetzt werden, die aber die Funktion weder beeinflussen noch begnstigen.\\ Darauf aufbauend werden durch die Klasse \texttt{Layer} die folgenden Funktionalitten implementiert und fr die erbenden Klassen bereitgestellt: \enumlist{Lcount}{\arabic} \item Duplexverbindungen zwischen Layern und Knoten \item numerischer Zugriff auf diese Verbindungen \item senden und empfangen von abstrakten Paket-Objekten\footnote{Objekten, die die Klasse \texttt{Packet} implementieren.} entlang der Verbindungen zur nchsthheren bzw. -niedrigeren Schicht \item erstellen, abbrechen und empfangen von Timeouts \end{list} % Die Klasse \texttt{Packet} wird von allen verwendeten Paketklassen der einzelnen Netzwerkschichten geerbt und implementiert die folgenden, von OmNet++ vllig unabhngigen Funktionen: \enumlist{Lcount}{\arabic} \item Speichern von Ziel- und Quelladdresse sowie Paketgre als primitiver numerischer Wert. \item Speichern eines Pakettyps zur einfachen Identifikation der Art des jeweiligen Pakets. \item Speichern der Referenz auf ein weiteres \texttt{Packet}-Objekt als Abstraktion der mehrfachen Verschachtelung von Paketen. \end{list} \section{Netzwerkschichten} Die Darstellung der Implementation der einzelnen Netzwerkschichten gliedert sich in jeweils zwei Unterabschnitte -- eine Beschreibung des verwendeten Paketformats und eine Beschreibung der Ablufe in der jeweiligen Schicht. Eine grobe bersicht kann man den Flussdiagrammen im letzten Abschnitt entnehmen. Wie man darin sieht, sind die einzelnen Schichten strikt linear ausgelegt, d.h. Pakete werden nur von einer Schicht an die entweder nchsthhere, oder -tiefere bergeben. Dabei werden unbekannte bzw. unerwartete Pakete einfach nach nach "`oben"' oder "`unten"' weitergereicht, was es technisch gesehen ermglicht einen einzelnen PC sowohl als Nameserver, Standard-Gateway, Router und Dateidienst/-clienten zu benutzen. In den implementierten Beispielen werden jedoch die einzelnen Rechner nur, wie in der Projektaufgabenstellung gefordert, in einer einzigen Rolle benutzt. \subsection{Bitbertragungs-/Sicherungsschicht} Als physikalische Schicht wurden ein an Token-Ring angelehntes Protokoll implementiert. Wie in der Aufgabenstellung gefordert sind dadurch sowohl ein Token-Ring-Zugriff als auch eine Punkt-zu-Punkt-Verbindung unter Umgehung des Token-Ring-Protokolls mglich. \subsubsection{Token-Ring -- Paketformat} Das von unserem Token-Ring-Protokoll verwendete Paketformat weist die folgenden Felder auf. Dabei werden die nicht fett gedruckten Felder aus der allgemeinen Packetklasse bezogen, die somit nicht direkt in den angegebenen Quelldateien vorkommen, sondern aus der Klasse \texttt{Packet} stammen und nur in der angegebenen Art und Weise benutzt werden: \enumlist{Lcount}{\arabic} \item Hardwareadresse des Quelladapters (im Folgenden Quell-MAC genannt) \item Hardwareadresse des Zieladapters (im Folgenden Ziel-MAC genannt) \item Paketgre, Kopf + angehngte Daten (Pakete der hheren Schichten) \item \textbf{Token-Ring Frame Typ}, legt fest ob es sich um ein Token- oder Daten-Frame handelt. \end{list} % Der Token-Ring-Pakettyp wird in den Datei \texttt{TokenRingPacket.hpp} implementiert. \subsubsection{Token-Ring -- Schicht} Das verwendete Protokoll reagiert wie folgt auf von auen ankommende Pakete: \begin{enumerate} \item Zuerst wird getestet, ob es sich berhaupt um ein Token-Ring Paket handelt. Wenn nicht, wird es einfach unbearbeitet an die nchsthhere Schicht weitergereicht. \item Es wird der Pakettyp bestimmt, d.h. ob es ein Token- oder Daten-Frame ist. \item Wenn es sich um ein Token-Frame handelt, \begin{enumerate} \item wird aus dem Sendepuffer ein Paket entnommen, (Sollte der Puffer leer sein, so wird das Token wieder nach unten, in diesem Fall auf das virtuelle Kabel, gesendet.) \item wird ein internes Flag gesetzt, dass diese Schicht im Besitz des Tokens ist, und \item wird das entnommene Paket in ein Data-Frame verpackt und anstelle des Tokens nach unten gesendet. \end{enumerate} \item Wenn es sich um ein Daten-Frame handelt: \begin{enumerate} \item Wenn die Quell-MAC des Pakets diesem Adapter entspricht und das interne Token-Flag gesetzt ist\footnote{Eigentlich wre es nur notwendig auf den Besitz des Tokens zu testen, der gewhlte Weg hat aber diagnostische Vorteile.}, so wird das Flag zurckgesetzt und ein neues Token nach unten gesendet. \item Wenn die Ziel-MAC des Pakets diesem Adapter entspricht, so wird das Paket entpackt und das enthaltene Paket, falls vorhanden, an die nchste Schicht weitergereicht. \item Wenn keins von beidem der Fall ist, wird das Daten-Frame unverndert nach unten gereicht. \end{enumerate} \end{enumerate}\medskip % Wenn das Paket jedoch von einer hheren Schicht kommt, so wird es einfach in einen dafr vorgesehenen Datenpuffer mit FIFO Zugriff kopiert.\medskip\\ % Die Implementation des beschriebenen Protokolls erfolgt in den Dateien \texttt{Token\-Ring\-Layer.hpp} und \texttt{Token\-Ring\-Layer.cc}.\medskip\\ % Es sei zudem angemerkt, dass sich dieses Protokoll nicht um die initiale Einspeisung des ersten Tokens, dessen Wiederherstellung im Fehlerfall oder der Ringbildung kmmert. Diese Funktionalitt wird jeweils durch einen als "`Token-Ring-MAU"' bezeichneten Hub erledigt, an den ein jeder Token-Ring Adapter angeschlossen werden muss. Dieser ist in den Dateien \texttt{TokenMAULayer.hpp} und \texttt{TokenMAULayer.cc} implementiert. \subsection{Vermittlungsschicht} Die Vermittlungsschicht wurde von uns in zwei Hlften geteilt. Die erste, die Gateway-Schicht, ist fr die Auflsung von Netzwerk-Adressen nach (rein lokalen) MAC-Adressen zustndig. Im Folgenden nennen wir Netzwerk-Adressen der Krze halber "`IPs"'. Die Gateway-Schicht entscheidet, ob ein Paket fr den Host selbst bestimmt war, oder an den Standard-Gateway zur erweiterteten Wegewahl weitergeleitet werden muss. Sie nimmt somit eine zu ARP und IP hnliche Rolle ein. Die zweite Hlfte besteht aus der Routing-Schicht. Sie leitet die von oben und unten ankommenden Pakete dem jeweils korrekten nchsten Router oder dem tatschlichen Ziel zu. Auerdem wird in ihr ein zuschaltbares Routing-Protokoll implementiert, welches Routing-Informationen sammelt und an die benachbarten Router verteilt. \subsubsection{Gateway -- Paketformat} Das von unserer Gateway-Schicht verwendete Paketformat weist die folgenden Felder auf, wobei die nicht fett gedruckten Felder erneut aus der allgemeinen Packetklasse bezogen werden: \enumlist{Lcount}{\arabic} \item Hardwareadresse des Quelladapters (im Folgenden Quell-MAC genannt) \item Hardwareadresse des Zieladapters (im Folgenden Ziel-MAC genannt) \item \textbf{Netzwerkadresse des Quelladapters} (im Folgenden Quell-IP genannt) \item \textbf{Netzwerkadresse des Zieladapters} (im Folgenden Ziel-MAC genannt) \item Paketgre, Kopf + angehngte Daten (Pakete der hheren Schichten) \item \textbf{Keepalive-Flag}, legt fest ob das Paket regulr ist, oder ob es sich nur um die Information an andere handelt, dass die Schicht / der Knoten noch aktiv ist. \end{list} Der Gateway Pakettyp wird in den Datei \texttt{GatewayPacket.hpp} implementiert. \subsubsection{Gateway -- Schicht} Das verwendete Protokoll reagiert wie folgt auf ein von einer niedrigeren Schicht ankommendes Paket: \begin{enumerate} \item Zuerst wird anhand des Pakettyps getestet, ob das Paket ein Gateway-Paket ist. Wenn nicht, wird es unverndert und direkt an die nchsthhere Schicht weitergeleitet. \item Sonst wird getestet, ob es sich bei den Paket um ein Keep-Alive handelt. Wenn ja, so wird die interne MAC/IP Tabelle mit den Daten des empfangenen Paketes ergnzt und das Paket verworfen. \item Handelt es sich hingegen um ein regulres Paket, entscheidet die Ziel-IP ber die weitere Vorgehensweise: \begin{enumerate} \item Ist sie entweder eine Broadcast-IP oder die eigene IP, so wird das Paket entpackt, und der Inhalt, sofern vorhanden, an die nchste Schicht gesendet. \item Ist die eingetragene IP des Standard-Gateways ungleich 0, wird der Inhalt des Pakets in ein neues Gateway-Paket verpackt, und nach unten an die MAC-Adresse des Standard-Gateways weitergereicht. \item Wenn kein Standard-Gateway definiert wurde (also dessen IP gleich 0 ist), wird das Paket entpackt und nach "`oben"' weitergereicht, um vom Routing-Layer behandelt zu werden. \end{enumerate} \end{enumerate} % Kommt das Paket jedoch von einer hheren Schicht, so wird versucht, die Ziel-IP des Pakets zu einer Ziel-MAC aufzulsen. Dabei wird eine Broadcast-IP durch eine Broadcast-MAC aufgelst. Wenn das IP/MAC-Paar aufgelst werden konnte, so wird das Paket mit diesen Daten nach "`unten"' gesendet. Konnte kein passendes IP/MAC-Paar gefunden werden, so wird das Paket an die MAC des Standard-Gateways gesendet. Sollte kein Standard-Gateway definiert sein, wird das Paket verworfen.\bigskip Die IP/MAC-Tabelle wird durch die von anderen Knoten empfangenen als Keep-Alive markierten Gateway-Pakete befllt. Ein solches Paket wird von einer jeden Gateway-Schicht in regelmigen Abstnden gesendet. Die Tabelle wird dabei in gewissen regelmigen Zyklen von alten Eintrgen befreit.\medskip Die Gateway-Schicht wird in den Dateien \texttt{Gate\-way\-Layer.hpp} und \texttt{Gate\-way\-Layer.cc} implementiert. \subsubsection{Routing -- Paketformat} Das von unserem Routing-Protokoll zur Kommunikation zwischen den Routern verwendete Paketformat weist die folgenden Felder auf: \enumlist{Lcount}{\arabic} \item Netzwerk-Adresse des Quelladapters (im Folgenden Quell-IP genannt) \item Netzwerk-Adresse des Zieladapters (im Folgenden Ziel-IP genannt) \item Paketgre, Kopf + angehngte Daten (Pakete der hheren Schichten) \item \textbf{Routingtabelle}, enthlt eine Kopie der Routingtabelle eines Routers. \item \textbf{Dirty-Flag}, zeigt an, ob sich die bergebene Routingtabelle seit der letzten Kommunikation verndert hat. \end{list} Pakete die nur geroutet werden, werden in ein Standardpaket verpackt, wobei die Addressfelder Netzwerk-Addressen sind, in denen das nchste bentigte Zwischenziel und die Ursprungsquelle eingetragen wird. Der Routing-Pakettyp wird in den Datei \texttt{Rou\-ting\-Packet.hpp} implementiert. \subsubsection{Routing -- Schicht} Das von uns fr die Router-zu-Router Kommunikation eingesetzte Routingprotokoll basiert im Wesentlichen auf einem Distance-Vector-Verfahren. Dabei gilt die Latenz zum nchsten Router in der Kette vom momentanen Router zum Ziel als Ma fr die Distanz. Mit anderen Worten: Der erste Router, der Informationen ber einen Knoten liefert, wird in der Tabelle gespeichert. Informationen von anderen oder ber andere Router werden ignoriert, bis der gegebene Eintrag in einer gewissen Zeit nicht mehr erneuert wird\footnote{Dies unterscheidet den benutzten Algorithmus von "`klassischem"' Distance-Vector-Routing, da stets nur eine Verbindung pro Ziel gespeichert wird, und zwar die heuristisch beste.}. Die Routingtabelle enthlt zudem auch die IPs aller lokal an den Router angeschlossenen Rechner, wobei bei einem IP-Adresskonflikt stets die lokale IP bevorzugt wird. Um die IP-Adressen der lokalen Knoten herauszufinden, sendet die Routing-Schicht, sofern das oben genannte Routingprotokoll aktiviert ist, im regelmigen Abstand Echo-Pakete an die Broadcast-IP ber alle vorhandenen Ausgnge, die in eine tiefere Schicht fhren. Ein Knoten mit nicht aktivierter Routingschicht antwortet mit einem eigenen als Antwort markiertem Echo-Paket an die IP des Knotens, der das Echo versendet hat. Diese Echo-Pakete sind um einzelnes Feld erweiterte Standardpakete, wobei die Adressen Netzwerkadressen (IPs) sind. Die Erweiterung ist ein einziges Flag, das identifiziert, ob das Paket eine Echo-Anfrage oder Echo-Antwort ist. Der Router nimmt alle Antworten auf das Echo als lokale Adressen in seine Routingtabelle auf. Empfngt jedoch ein anderer Router eine Echo-Anfrage, so versendet er zustzlich noch ein oben beschriebenes Routing-Paket, welches eine Kopie seiner eigenen Routingtabelle enthlt. Diese Tabelle wird von dem Urpsrungs-Router verarbeitet, indem alle noch unbekannten Adressen zur eigenen Tabelle hinzugefgt werden. Die vorhandenen Adressen, die mit dem gespeicherten physischen Ausgang verbundenen sind, werden so markiert, dass sie nicht beim nchsten Lschvorgang entfernt werden. Auf diese Art und Weise wird sichergestellt, dass sich nderungen schrittweise durch das gesamte Netz verteilen. Um einen guten Kompromi aus nderungsgeschwindigkeit und Netzbelastung zu erreichen, wird die Wartezeit zwischen dem Aussenden einer neuer Reihe an Echo-Paketen bei vorgenommenne nderungen auf ein gewisses Minimum reduziert. Bei ausbleibender nderung wird die Wartezeit exponentiell bis zu einem gewissen Maximum erhht. Dieses bertragen der nderungen erfolgt durch Setzen des "`Dirty-Flags"' in den besprochenen Routing-Paketen.\bigskip\\ % Wenn das eigentliche Routingprotokoll abgeschaltet wurde, so verhlt sich die Routingschicht bei einem eintreffenden Paket wie folgt: \enumlist{Lcount}{\arabic} \item Kam das Paket von einer hheren Schicht, wird es einfach an die nchstniedrigere Schicht weitergeleitet, da angenommen wird, dass in diesem Fall ein lokaler Standard-Gateway eingetragen wurde, oder das Ziel lokal angeschlossen ist. Die Ausnahme davon bilden Pakete, die an die eigene IP adressiert sind. Diese werden direkt zurck an die hheren Layer geleitet. \item Anderenfalls, wenn es sich um ein Echo-Paket handelt, wird ein als Antwort markiertes eigenes Echo-Paket zurckgesendet. \item In den brigen Fllen wird das Paket gegebenenfalls entpackt\footnote{Um die IPs der Originalquelle und des Originalziels nicht berschreiben zu mssen, wird beim Routing das Paket in ein Standardpaket mit vernderten Adressen verpackt.} und an die nchsthhere Schicht weitergeleitet. \end{list}\medskip % Wenn das Routingprotokoll angeschaltet wurde, wird dieses Verhalten so verndert, dass die Routingtabelle gefllt wird und ein direktes Routing der eingehenden Pakete stattfindet. So wird die Kommunikation zwischen den Routern bzw. zwischen Router und einzelnen lokalen Knoten ermglicht. Dabei verhlt sich diese Schicht beim Empfang von Paketen wie folgt: \begin{enumerate} \item Wenn das Paket von einer hheren Schicht ankommt, wird die IP des bergebenen Pakets in der Routingtabelle nachgeschlagen. Falls ein Eintrag gefunden wird, wird das Paket mit einem anderen Paket umhllt, dessen Ziel-IP aus der Routingtabelle entnommen wurde und dessen Quell-IP die IP des momentanen Routers ist. Danach wird das Paket ber den ebenfalls der Tabelle entnommenen physikalischen Ausgang an eine niedrigere Schicht gesendet. Die Ausnahme sind erneut Pakete, die an die eigene IP adressiert sind. Diese werden sofort an die hheren Schichten zurckgeleitet. \item Wenn das Paket von einer niedrigeren Schicht kommt, wird zunchst der Typ des Pakets festgestellt. \item Wenn es sich um ein Echo Paket handelt: \begin{enumerate} \item Wenn das Paket eine Echo-Anforderung ist, so wird ein Antwort-Echo-Paket zurckgesendet. \item Direkt danach wird ein Routing-Paket mit einer Kopie der momentanen Routingtabelle an die Quell-IP des Echo Pakets gesendet. \item Handelte es sich aber um eine Antwort auf ein von dieser Schicht ausgehendes Echo Paket, so wird die Quell-IP als lokaler Knoten in die Routingtabelle bernommen. \end{enumerate} \item Wenn es sich um ein Routing-Paket handelt: \begin{enumerate} \item Wenn das Paket nicht von der Routing-Schicht selbst stammt\footnote{Dies kann passieren, wenn sie mit zwei unterschiedlichen physikalischen Ausgngen an dasselbe Netz angeschlossen ist.}, wird die im Paket enthaltene Routingtabelle entpackt. \item Es werden alle Eintrge als nicht-lokale IPs bernommen, die auf eine bislang unbekannte IP zeigen. Der dazugehrige physikalische Ausgang ist derjenige, ber den das Routing-Paket ankam. Als dazugehriger Router wird die Quell-IP des Pakets angenommen. \item Bereits bekannte Eintrge werden, wenn ihr physikalischer Ausgang und zugehriger Router zu den Daten im Paket passen, so markiert, dass sie nicht beim nchsten Lschvorgang entfernt werden. \item Wenn sich irgendetwas an der Routingtabelle gendert hat, wird die eigene Tabelle als "`dirty"' markiert. \end{enumerate} \item Falls es sich um einen anderen Pakettyp handelt: \begin{enumerate} \item Pakete an Broadcast-IPs werden ignoriert und fallen gelassen. Dies sorgt fr eine Abtrennung der Netze in unterschiedliche Broadcast-Domnen. \item Zunchst wird ein gegebenenfalls vorhandener Routing-Wrapper entfernt, um die echte Ziel-IP des Pakets in Erfahrung zu bringen. \item Wenn diese IP mit der des Routers bereinstimmt, so wird das Paket einfach an die nchsthhere Schicht weitergeleitet. \item Sonst wird angenommen, dass das Paket geroutet werden muss. \item Dazu wird die Ziel-IP in der Routingtabelle nachgeschlagen und, sofern gefunden, verpackt und an die dort eingetragene IP ber den eingetragenen Ausgang an eine niedrigere Schicht bergeben. \item Wenn die IP nicht aufgelst werden kann, wird das Paket einfach ignoriert und fallen gelassen. \end{enumerate} \end{enumerate}\bigskip % Auf diese Weise werden Pakete geroutet, und die routerinterne Kommunikation abgesichert. Aufgrund der Verwendung eines Distance-Vector-hnlichen Algorithmus werden nderungen durch das ganze Netz verteilt, bis sich nach einiger Zeit eine Stabilisierung\footnote{Dass stets eine Stabilisierung eintritt kann hier nur aufgrund von empirischer Erfahrung mit dem Algorithmus angenommen werden.} einstellt. Die Optimalitt des Pfades kann dabei jedoch nicht garantiert werden, da die Abschtzung durch die Latenz zum nchsten Sprung zu gierig (greedy) ist, und sich somit in lokalen Optima verfangen kann. Schleifenlosigkeit wird nach einer nderung unter Umstnden erst im Stabilittspunkt wiederhergestellt. Da das Protokoll keine Lebensdauer eines individuellen Pakets vorsieht kann es somit zu langen Paketschleifen kommen, die sich aber ebenso sptestens im Stabilittspunkt auflsen.\bigskip\\ % Die Routing-Schicht wird in den Dateien \texttt{Rou\-ting\-Lay\-er.hpp} und \texttt{Rou\-ting\-Lay\-er.cc} implementiert. \subsection{Transportschicht} Die Transportschicht stellt bei uns die korrekte Reihenfolge der Pakete sicher, garantiert ein Ankommen der Pakete, sofern es berhaupt eine Route zum Ziel gibt, und schtzt durch eine einfache statische Flusssteuerung vor berlastungen. Die korrekte Fragmentierung und Reassemblierung der Pakete wurde aus der eigentlichen Transportschicht ausgelagert, und wird von einer direkt ber ihr stehenden, eigenen Schicht erledigt. Dies trennt auf natrliche Weise diese beiden Teilgebiete. Im Folgenden wird nur die Transportschicht nher beleuchtet, da die Fragmentierungsschicht eher simpel und wenig funktionell wenig erhellend ist. Es drfte ausreichen zu sagen, dass sie davon ausgehen kann, dass die Pakete, dank der Transportsicherung, in der richtigen Reihenfolge und stets komplett ankommen, so dass die einzige Aufgabe das Verbinden und Trennen von Paketen ist. Dies geschieht durch Nutzung fortlaufender Sequenznummern pro Verbindung fr jedes aufzuteilende Paket. \subsubsection{Transport -- Paketformat} Das von unserem Transportprotokoll verwendete Paketformat weist die folgenden Felder auf: \enumlist{Lcount}{\arabic} \item Netzwerkadresse des Quelladapters (im Folgenden Quell-IP genannt) \item Netzwerkadresse des Zieladapters (im Folgenden Ziel-IP genannt) \item Paketgre, Kopf + angehngte Daten (Pakete der hheren Schichten) \item \textbf{Pakettyp}, zeigt an um welche Art von Paket es sich handelt\footnote{Die mglichen Arten werden in Abschnitt \ref{TransportLayer} genauer erlutert.} \item \textbf{Sequenznummer der Quelle}, speichert die Sequenznummer, die dieses Paket beim Absenden von ihrer Quelle zugewiesen bekommen hat. \item \textbf{Zusatzsequenznummer 1 \& 2}, speichern zwei weitere Sequenznummer fr administrative Zwecke\footnote{Details in Abschnitt \ref{TransportLayer}} \end{list} Der Pakettyp der Transportschicht wird in der Datei \texttt{Trans\-port\-Packet.hpp} implementiert. \subsubsection{Transport -- Schicht} \label{TransportLayer} Das von uns zur Transportsicherung verwendete Protokoll ist verbindungsorientiert und nutzt zum Verbindungsaufbau und -abbau einen 3 Wege Handshake. Die Fehlerbehandlung erfolgt durch eine leicht modifizierte Variante des "`Selective-Repeat"', bei der ein NACK so umgedeutet wurde, dass damit der erfolgreiche Empfang eines Paketes besttigt wird, das nicht in korrekter Reihenfolge ankam. Somit werden fehlende Pakete schon vor dem Timeout erkannt und knnen. Die Flusssteuerung wird mittels eines Gleitenden Fensters (Sliding Window) implementiert, wobei die gre des erlaubten Fensters statisch vordefiniert wird. Bei einem Verbindungsaufbau verhlt sich die Transportschicht wie folgt, wobei P1 und P2 jeweils die beiden kommunizierenden Transportschichten sind, und die Verbindung von P1 ausgeht. \enumlist{Lcount}{\arabic} \item P1 generiert eine zufllige Sequenznummer $S1$ und erstellt damit einen Verbindungseintrag in seiner Verbindungstabelle mit der Flussrichtung $P1 \rightarrow P2$ und der Sequenznummer $S1 - 1$\footnote{Diese Nummer zeigt an, welches Paket als letztes korrekt besttigt wurde. In diesem Fall noch keins.}. \item P1 sendet ein SYN Paket an P2, wobei das Quellsequenzfeld mit der generierten Sequenznummer $S1$ gefllt wird. \item P2 empfngt das SYN Paket und erstellt zwei Verbindungseintrge $P1 \rightarrow P2$ und $P2 \rightarrow P1$. \item Der ersten der beiden Verbindungen weist P2 die Sequenznummer $S1$ aus dem SYN Paket zu. Fr die zweite Verbindung generiert P2 eine neue Sequenznummer $S2$ und weist der Verbindung $S2 - 1$ als letztes besttigtes Paket zu. \item P2 sendet ein SYN+ACK Paket an P1, wobei das Quellsequenzfeld S2 trgt, und das 1. Zusatzsequenzfeld nochmals $S1$ enthlt. \item P1 empfngt das SYN+ACK von P2, aktiviert die Verbindung $P1 \rightarrow P2$ sofern $S1$ korrekt zurckbertragen wurde, und erhht die Sequenznummer der Verbindung um 1. Danach wird die Verbindung $P2 \rightarrow P1$ mit $S2$ angelegt und aktiviert. P1 sendet dann ein ACK zurck an P2, wobei die Quellsequenz der Verbindung $P1 \rightarrow P2$ entnommen wurde und $S2$ im Extrasequenzfeld gespeichert wird. \item P2 empfngt das ACK und aktiviert daraufhin, sofern die Sequenznummern passen und korrekt hochgezhlt wurden, beide Verbindungen. \end{list} Auf diese Art werden werden bei beiden Teilnehmern die gleichen Verbindungen mit identischen Sequenznummern erstellt, und eine Datenkommunikation kann begonnen werden. Es sei hierbei angemerkt, dass ein jeder Verbindungseintrag genau zwei Sequenznummern speichert: Die Sequenznummer des zuletzt quittierten Pakets und die Sequenznummer die das nchste Paket bekommen muss. Eine graphische bersicht findet sich in bei den Fludiagrammen auf Seite \pageref{Flowchart_3WayHandshake} in Abbildung \ref{Flowchart_3WayHandshake}, wobei darauf zu achten ist, dass hierbei pro Verbindung nur die Sequenznummer des zuletzt quittierten Pakets angezeigt wird.\bigskip\\ % Beim Datenaustausch wird die folgende Abfolge eingehalten. Hierbei wird erneut ein Datenfluss von P1 nach P2 angenommen. \begin{enumerate} \item P1 testet ob die Verbindung nach P2 steht und aktiv ist. \item P1 erstellt ein Datenpaket mit der nchstmglichen Sequenznummer der Verbindung $P1 \rightarrow P2$, sendet dieses an P2 und setzt einen Timeout fr das erneute versenden. \item P2 empfngt das Datenpaket. Falls es das Paket nicht empfngt luft bei P1 der Timeout ab und das Paket wird erneut gesendet. So kommt es irgendwann bei P2 an. \begin{enumerate} \item Falls das Datenpaket mit der richtigen (als nchstes fr die Verbindung $P1 \rightarrow P2$ erwarteten) Sequenznummer ankam, sendet P2 ein ACK an P1, wobei das Quellsequenzfeld mit der nchstmglichen Nummer aus der Verbindung $P2 \rightarrow P1$, und das Extrasequenzfeld mit der Sequenznummer des Datenpakets gefllt wird. Danach wird das Datenpaket entpackt und an die nchsthhere Schicht geleitet. \item Falls das Datenpaket nicht mit der richtigen Sequenznummer ankam, wird es entweder verworfen, wenn es ausserhalb des Sliding Window ist, oder es wird durch ein NACK besttigt. Das NACK funktioniert dabei wie ein ACK, nur dass das zweite Extrasequenzfeld mit der eigentlich fr die Verbindung $P1 \rightarrow P2$ erwarteten Sequenznummer befllt wird. Das Paket wird dann solange zwischengepuffert, bis die Reihenfolge durch den Empfang der erwarteten Datenpakete wiederhergestellt wurde. Erst dann wird es entpackt und an die nchsthhere Schicht geleitet. \end{enumerate} \item P1 empfngt nun wiederum ein ACK oder ein NACK \begin{enumerate} \item Bei einem ACK wird der Timeout fr das zum ACK gehrende Datenpaket entfernt. \item Bei einem NACK wird ebenso der Timeout fr das zum NACK gehrende Datenpaket entfernt, aber zustzlich werden noch alle Pakete erneut gesendet (und deren Timeouts neu gestartet), die zwischen dem durch NACK besttigten Paket liegen, und dem Paket, auf dass im zweiten Extrasequenzfeld des NACK verwiesen wird. Dabei werden all' jene dazwischenliegenden Pakete ignoriert, die bereits selbst ein NACK bzw. ein ACK erhalten haben. \end{enumerate} \end{enumerate} Am Ende dieser Abfolge ist die Reihenfolge und jedes zwischendurch verlorengegangene Paket wiederhergestellt. Es sei angemerkt, dass falls ACK und NACK Pakete verloren gehen, diese erst nach erneuter Ankunft des zu ihnen gehrigen Datenpakets neu gesendet werden, whrend Datenpakete entweder durch einen Timeout oder, oftmals schneller, als Nebeneffekt eines NACK neu gesendet werden.\bigskip\\ % Ein Verbindungsabbau erfolgt erneut durch einen 3-Wege Handshake und wird ausgelst, wenn ein Timeout fr die jeweilige Verbindung erreicht wird und bei einem anschlieendes Test festgestellt wird, dass die Verbindung inaktiv ist, also weder auf Pakete wartet, noch Pakete senden will. Dabei werden nur Verbindungen von der jeweiligen Transportschicht selbst zu anderen Transportschichten bercksichtigt, da die brigen whrend des 3-Wege Handshakes mit entfernt werden. Der Ablauf ist dann wie folgt, wobei erneut ein Ausgehen von P1 vorausgesetzt wird. \begin{enumerate} \item P1 erhlt den Timeout fr die Verbindung $P1 \rightarrow P2$ und erkennt, dass diese Verbindung inaktiv ist. \item P1 sendet ein FIN Packet an P2 und setzt die Verbindung $P1 \rightarrow P2$ und $P2 \rightarrow P1$ auf "`inaktiv"', so dass keine neuen Datenpakete mehr ber diese Verbindung gesendet werden knnen, bis sie komplett abgebaut ist. Alte Pakete (wegen erneutem Senden) und ACKs/NACKs knnen aber immer noch gesendet werden, auch wenn dies aufgrund der Bedingungen and das Auslsen des FIN nicht auftreten sollte. \item P2 empfngt das FIN Packet und inaktiviert die Verbindungen $P1 \rightarrow P2$ und $P2 \rightarrow P1$, wartet jedoch noch mit dem Besttigen des FIN bis alle Pakete fr die erste Verbindung bis zur Sequenznummer des FIN angekommen sind und die zweite Verbindung fr alle Pakete ein ACK bzw. NACK erhalten hat. \item P2 sendet ein FIN+ACK und setzt die Verbindungen $P1 \rightarrow P2$ und $P2 \rightarrow P1$ auf "`tot"', wodurch alle weiteren Pakete abgelehnt werden und die Verbindung eventuell wieder neu aufgebaut werden kann. \item P1 empfngt das FIN+ACK und setzt nunmehr die beiden Verbindungen $P1 \rightarrow P2$ und $P1 \rightarrow P2$ auf "`tot"'. \end{enumerate} Am Ende dieser Abfolge sind die Verbindungen in beide Richtungen abgebaut, ohne dass ein Paket dabei verlorengegangen sein sollte.\bigskip\\ % Die Flusssteuerung erfolgt einfach und direkt durch Vorgabe eines Sliding-Window fr die Auswahl an Sequnznummern pro Verbindung. Jede Verbindung darf dabei nur eine gewisse Menge an Datenpaketen mehr versenden, als bislang Pakete besttigt wurden. Gleiches gilt fr den Empfang, bei denen jedes Paket, das mit seiner Sequenznummer "`zu weit in der Zukunft"' liegt einfach ignoriert wird. Bei letzterem stellt die gegenberliegende Transportschicht ein erneutes Versenden des verworfenen Paketes sicher. Bei ersterem Fall, dass wir selbst mehr Pakete als erlaubt senden wollen, knnen wir die Pakete nicht ignorieren oder verwerfen, da in dem von uns implementierten Framework eine derartige Kommunikation zwischen den Schichten nicht mglich ist. Die bermig ankommenden Pakete mssen daher zwischengepuffert werden, und werden verarbeitet sobald die Verbindung wieder freie Sequenznummern brig hat.\bigskip\\ % Die Transportschicht wird in den Dateien \texttt{Trans\-port\-Layer.hpp} und \texttt{Trans\-port\-Layer.cc} implementiert. Die Hilfsklassen fr das Verwalten von Verbindungseintrgen sind in den Dateien \texttt{Conn\-Track\-er.hpp} und \texttt{Conn\-Track\-er.cc} implementiert. \subsection{Anwendungsschicht} In der Anwendungsschicht stehen zwei Dienste zur Verfgung, der Namensdienst und die Dateibertragung. Jeder simulierte PC besitzt genau einen dieser beiden Dienste, mit Ausnahme der Router. Auf einem Router knnte zwar ebenfalls ein Dienst der Anwendungsschicht laufen, im Rahmen der Aufgabenstellung wird jedoch darauf verzichtet. \subsubsection{Namensdienst -- Paketformat} Das von unserem Namensdienstprotokoll verwendete Paketformat weist die folgenden Felder auf: \enumlist{Lcount}{\arabic} \item Netzwerkadresse des Quelladapters (im Folgenden Quell-IP genannt) \item Netzwerkadresse des Zieladapters (im Folgenden Ziel-IP genannt) \item Paketgre, Kopf + angehngte Daten (Pakete der hheren Schichten) \item \textbf{Namen}, der Name der mit der gegebenen Adresse verbunden ist. \item \textbf{Adresse}, die IP Adresse die mit dem gesuchten Namen verbunden ist. \end{list} Hierbei wird vom anfragenden PC der Name vorgegeben und die Adresse als Antwort vom Namensdienst eingetragen. \subsubsection{Namensdienst -- Schicht} Der Ablauf der Kommunikation zwischen einem Clienten und dem Namensdienst luft wie folgt ab: \enumlist{Lcount}{\arabic} \item Der Client bereitet ein Paket im Format des Namensdienstes vor, und trgt im Namensfeld den gesuchten Namen ein. Das Adressfeld kann beliebig gefllt werden, es wird durch den Namensdienst ignoriert. \item Der Namensdienst empfngt das Paket, sucht den Namen in seiner Namenstabelle und trgt, sofern der Name aufgelst werden konnte, die aufgelste Netwerkadresse und den Namen in ein neues Namenspaket ein und sendet es an den Client zurck. Wenn der Name nicht aufgelst werden konnte, wird als Adresse eine $-1$ eingetragen. \item Der Client empfngt das Paket und erfhrt somit den passenden Namen zu der Adresse, wobei er das Adressfeld auf Existenz einer $-1$ testet und darauf entsprechend reagiert. \end{list} In der vorliegenden Implementation des Netzwerks und der Verteilung der Schichten erfolgt die Kommunikation zwischen den Clienten und dem Namensdienst auch ber die Transportsicherung und luft daher verbindungsorientiert ab. \subsubsection{Dateibertragung -- Paketformat} Die zur Dateibertragung verwendeten Pakete weisen folgenden Felder auf: \enumlist{Lcount}{\arabic} \item Netzwerkadresse des Quelladapters (im Folgenden Quell-IP genannt) \item Netzwerkadresse des Zieladapters (im Folgenden Ziel-IP genannt) \item Paketgre, Kopf + angehngte Daten (Pakete der hheren Schichten) \item \textbf{Typ}, der angibt, welche Aktion auf dem Dateisystem auszufhren ist, bzw. um was fr eine Antwort es sich handelt \item \textbf{String-Parameter}, ein abstrakter Parameter fr Aktionen und Antworten, die eine Zeichenkette als Parameter bentigen (z.B. Dateipfad) \item \textbf{Int-Parameter}, ein abstrakter Parameter fr Aktionen und Antworten, die eine Zahl als Parameter bentigen (z.B. Dateigre) \end{list} Es gibt folgende \textbf{Typen}: \enumlist{Lcount}{\arabic} \item \emph{CONN-REQ} -- Anfrage zum Aufbau einer Verbindung \item \emph{CONN-ACK} -- Antwort: Besttigung der Verbindung, insbesondere die Besttigung, dass sich am anderen Ende auch ein Dateibertragungsdienst befindet \item \emph{CD-REQ}, \emph{CD-ACK} und \emph{CD-DENY} -- Anfrage, Positiv-Antwort und Negativ-Antwort fr die Aktion "`Verzeichniswechsel"' \item \emph{DEL-REQ}, \emph{DEL-ACK} und \emph{DEL-DENY} -- Anfrage, Positiv-Antwort und Negativ-Antwort fr die Aktion "`Datei oder Verzeichnis lschen"' \item \emph{DIR-REQ}, \emph{DIR-ACK} und \emph{DIR-DENY} -- Anfrage, Positiv-Antwort und Negativ-Antwort fr die Aktion "`Verzeichnisinhalt anzeigen"' \item \emph{MKDIR-REQ}, \emph{MKDIR-ACK} und \emph{MKDIR-DENY} -- Anfrage, Positiv-Antwort und Negativ-Antwort fr die Aktion "`Verzeichnis erstellen"' \item \emph{MKFIL-REQ}, \emph{MKFIL-ACK} und \emph{MKFIL-DENY} -- Anfrage, Positiv-Antwort und Negativ-Antwort fr die Aktion "`Datei erstellen"' \item \emph{GET-REQ}, \emph{GET-ACK} und \emph{GET-DENY} -- Anfrage, Positiv-Antwort und Negativ-Antwort fr die Aktion "`Datei herunterladen"' \item \emph{PUT-REQ}, \emph{PUT-ACK} und \emph{PUT-DENY} -- Anfrage, Positiv-Antwort und Negativ-Antwort fr die Aktion "`Datei hochladen"' \end{list} Das Paketformat der Dateibertragungsschicht ist in der Datei \texttt{File\-Packet\-.hpp} implementiert. \subsubsection{Dateibertragung -- Schicht} Die Dateibertragungsschicht ist Client und Server zugleich. Sie antwortet einerseits auf eingehende Anfrage-Pakete (Server) und stellt andererseits der Shell ihre Funktionen zur Verfgung (Client). So ist das Wissen ber das Protokoll und Paketformat in der Schicht gekapselt. Die Auenwelt (Shell) bedient lediglich die bereitgestellten Funktionen. Durch Shellkommando oder Anfrage-Paket ausgelste lokale Aktionen werden direkt ausgefhrt. Remote-Aktionen werden durch Versenden eines entsprechenden Anfrage-Pakets realisiert. Eingehende Antwortpakete werden dann dem Benutzer prsentiert. Es werden jedoch keine echten Dateien bertragen. Smtliche Aktionen finden in virtuellen Dateisystemen statt. Der Inhalt der Dateisysteme wird zu Beginn der Simulation pro PC durch entsprechende XML-Konfigurationsdateien festgelegt. Dabei bildet das virtuelle Dateisystem nur Dateipfade und Dateigren ab. Mehr ist fr die Simulation auch nicht notwendig: Groe Dateien verursachen bei einer \emph{GET-REQ}-Anfrage ein entsprechend groes \emph{GET-ACK}-Antwortpaket, das von den tieferen Schichten entsprechend in kleinere Pakete zerlegt wird, die bertragen, in die richtige Reihenfolge gebracht und wieder zusammengefgt werden mssen. Die Dateien und Verzeichnisse werden auf Paket-Ebene stets durch absolute Pfade adressiert. Jedoch akzeptieren die Client-Funktionen auch relative Pfade, die clientseitig in absolute Pfade umgewandelt werden. Die Dateibertragungsschicht wird in den Dateien \texttt{FileLayer.hpp} und \texttt{FileLayer.cc} implementiert. Das virtuelle Dateisystem wird in den Dateien \texttt{SimpleFS.hpp} und \texttt{SimpleFS.cc} implementiert. \newpage \section*{Flussdiagramme} Zur besseren Veranschaulichung der inneren Ablufe in den verschiedenen Schichten folgen nun einige Flussdiagramme. \vfill \begin{figure}[ht] \centering\includegraphics[width=15.5cm]{graphics/3WayHandshake.eps} \caption{Ablauf eines 3-Wege Handshakes zum Verbindungsaufbau.} \label{Flowchart_3WayHandshake} \end{figure} \begin{figure}[ht] \centering\includegraphics[width=15.5cm]{graphics/SimplePC.eps} \caption{Ablufe in einem einfachen PC} \label{Flowchart_Normal_PC} \end{figure} \begin{figure}[ht] \centering\includegraphics[width=15.5cm]{graphics/RouterPC.eps} \caption{Ablufe in einem PC mit aktiver Routing-Schicht} \label{Flowchart_Router_PC} \end{figure} \begin{figure}[ht] \centering\includegraphics[width=15.5cm]{graphics/2WayRouter.eps} \caption{Ablufe in einem Router mit mehren Ausgngen} \label{Flowchart_2WayRouter} \end{figure} \clearpage % dump all figures %\bibliography{Sources} %\bibliographystyle{bababbrv} \section*{Lizenz} Dieses Dokument ist lizensiert unter \href{http://creativecommons.org/licenses/by/3.0/deed.de}{% Creative Commons BY 3.0} \bigskip \href{http://creativecommons.org/licenses/by/3.0/deed.de}{% % CC-Icons heruntergeladen von: % http://creativecommons.org/presskit \includegraphics{graphics/by}} \end{document} Netzwerksimulation/graphics/0000755000175000017500000000000010756143355014755 5ustar vogvogNetzwerksimulation/graphics/originals/0000755000175000017500000000000010756143355016744 5ustar vogvogNetzwerksimulation/graphics/originals/2WayRouter.dia0000644000175000017500000000636010753714421021446 0ustar vogvog ][o~ϯ@Ѣ6ëD7 `vc nj"zw8/+oYeȿuHe4J]a8bu3:_Wsu =K[]5T}bwq@~HE=2R)yϿY5i}㹮VdDt`l@P$)0BI=1On6,pXrɰ>Nm8fR7^!L]ˆINLp9 ^{yvM$Ҫ,nկno.-`^%?vC?i0 uYxO?vS}k-gên.ТbXsfTt.voԋխ葓G ^N:^͋aglݿAz;8F"Pb/ztƷ>!}%8#sybĶ&Aɳd,y 3̼^{R9 8Z",zfUy>֧$uغ ޣ<=!dL>WgB~5ʍN8+1+7mzDb@)X7MStT A kiچ>iΘ=c`J c![,_+iiHkFDD, WT1I#o-E}Uk}Z-ZxƢ-;trtK6X*w˱q];[,[M,c`l<c~noL(r˦g#-džZ_qEb!#I ׭蚻??^*S[_(QQ4 a(M^p!1+p4A~Rc#`#\px#ܴx4H [N+ XeL Cʐu|-7!\:;ԝzSڿёC*96 )Gp8-=?1ǬoONvt.;&t2 2Z83o2c?BA'pbPv[ؙaa?XY{#ERp|C3Åq>cܫq X| ZsIſ:zfPҢkj&8)**qsI[Gɛs̹CImS-ȿޢk6ZZ _5p>e_ ik#2zPe|j\lS 6))#p} p$!M߅kjN>0}=Tvgp\MD1"cݩixPՕNث7EaAU%W@J jST ;<`s{XI< :GN GR(/?Ǔ=3xe/L 1b9{xP7#xϵg\bM=J\2LqyNޚ[/ўFM;0Xx$f'c{F=AzȲWֿR,;{nOMIxuBXOw:Wb mֆ7/:S!2eIEq}U{'U"NVܤ/*$Հ;Z1D[R(qHx) UkDr+ =BAk%T?xnNۑVeֈXI8[R̹D'X+p0C.A w',Hڦܽ:.2+|v8tmmҎRp}p~zs2w&䪜»L Wyd <&YRu{^r;z.!d^ *uy[vJV*zX1Ygxg_pwmrn]+6wwL`+힂*l^xs.aSg)^("X3s, DZ3ĜP<o&ط̏ r>33Cf֏l O)sN/ubL`L LL f`g;ƏMsGO͞wgqi}>Netzwerksimulation/graphics/originals/3WayHandshake.dia0000644000175000017500000000431210753673000022045 0ustar vogvog ][8}_RiUSm vәjn>S$L–@%}MI L7t&_|rαQ,?=TX؛·S7^]wfax=>>2竎}V?8' :7WY<\aۣR\>;#>1{w҉K%ƞw;V_^RM/SϞ|j|]&+S^`"rUdG=ѿeR(No^}_ŷ\XUt;sOmw;'R Q>Jpf9͆ gÅ>#s,QC*'sGL}ͪЊ;; ǝėSܩoO?;jy'l$ڗj{XEwoam/>?:~{׶syP˰ӗ=,[fGMXP1b 'CgS?Zd k&dcOy|񂰳rؓΟZwUķ= o=̮ovUhݩc%*cգ`"pL-ǚǞn#ZZ=[fSEQOt!_!̲pw0{a:4İA kua,J[ǎV.ĝ8G"B3qXc*`d`W:vR9b8|_ q9`qrB{\Cb$we[&ܟzL(Irdf:Cjj&*3LL""}R.ru+ Y}ʔ}v|ۃZvM%1QBEו;>#e8Vd+w s(PZT?MeeܑL iiέ1]>tdBvs񰺥Y=OH9CE$L[9eWjmj=&@j"$D*$8 k Ao H@ ۍ Ii6 !H Ed Bl /Ab)_EC^ yP|LP`TRV̪`%r^!Ƥju"fj xDk%#F]9ɪ 'HS Nx?/PdwdetHUC UEu[U../.Ewd`{Ǩ;ֲwl4a{/4P@ů_.߻vEd>];U[KUs(~,r)ZgS46KE5Z_Z &\5uTn,IJ0j,+9̪lbe>qV\Ǿ>Y/ח|龾T MT>PڭIW}}ʗw9:I _oUhR0Zk>rXc4B1ǀz z̨#!zhYzLz lzR1Y=F4 ]&DϛmR1fǀ+|[1k5֯|4{>DX5Pc-h]CH!Rj,=r1P=; X!R&1ΘP`R H|^$'vo{M`CNetzwerksimulation/graphics/originals/RouterPC.dia0000644000175000017500000000544410753714421021130 0ustar vogvog mo6W^lnC EK یF Il~ %ىe;SȮ%S"ΌwgA]=GGxDӋ޿.ξ[&܁+]fYx{~~{{»~qf03ߜ+YeȟLxMzE287w^fs#y/%ڿٟ5RdI5"NH- M*DݛMQ}^ WH6imˁ HRJ1 {#69\ܨ[qan"Nm8RdcˆyG1˻,nF 6dm!AHg:β8C$<{rc7FSߵ FU&*fޝ|.fo(r;MZ>MDOt4{rΟjj6Lqz"BN'e?­41ZS7!YYA:cf{ `r'lj} +V,u}\6+e=UsN~4 u# y;aCq DPϯqm;MT0ϾJ ?L=\(3*!kaZQQRq`OU #7?0Mu3DljHgiJPWh9/ovf_,fqG>Zk?Lu 1,7 8YHvCJI鮹IXv)-7-7-7| 04 'hYJ.@A|Ŋ{ljQtI^H za]xLɕ$QDiͬBM+ID?SУ[x\`#FFsEmuגZymV `fus9 rq*<4X",Z;?σauehCu amOȸ!X7jmPҁqsl펱nкaZ7ֺͱIyG䤬BN9)~!KNKNچ, 1/Dq B[UۍWր|]$/ Cϐ\;`uzXGRavd-jxGl;:4Mn魪iyY4[uiB7iGM+H*jׯf/H P%>5-o\AA9Ӛc#|3.ODWs8 6U<]&~%/?z$~&]yڟ[w2b\<쮇`ǒOV\ͮyPcm>lgi%88͐5{Nng8z6ц4ڐ:cp8S\vC&3IP%hIݹ ߝ_tv'7Vkl[k?x:ƪA;>!M|bɰRzF;`]cBACTcՓAey.heƞHaTF6j`{=ek2 b\bGb2cxTˣzWS1(gW1Z'ޕ\6EymNk,)Fէu~q-3 Ϝe_Y(Lt̉G?87ql<.S~otVdtd--ue,&XL;LueW-ֺ!ÜBDлOk/Ʀ(3xu  ^2TUHFZ?Zgy?Xdwl>IdA6m`un 0г]wpybM `'`:KgNt7=7@Os\FSCTsuInNK,2\ud?~|=8k8mS+x]xJ<{]ṁ}ܩ:bVCqZ'Ŏpc8:ebLWf6=W[ dZ p@BR} !v]d PŭQ '! / Gln׊W\u=:>.I7wKҀ!aŮI풄I) ڡ__sP0K ]mDESk:RӕfEu9f'(&=qPۭ@:_Թ9m|Wقw6gMZeZ1~ (UH?vJ&((Oe۱##OW"΢B8>fBNÎ_(*kౣyHZ]D@ |)l[ 2F-_b 4Ae'O.:jgMwmy]XknT'\$@tI`¤4:(~3*[LDΥ?ae^[]FK+IL`p&qLux vRA:g0p4 e5Zd.^ q?A̓|s`pW`&Ő2:P~Au0o_p@@ ~$:M];TFXpGq'8Ί&pv*Netzwerksimulation/graphics/originals/SimplePC.dia0000644000175000017500000000542010753714422021074 0ustar vogvog n(Zf+,Slw`7mȒ!ɓ\z$;l'qX2CRso<O:I8{$\~?ޞ}; owsRstћe[ޥ~'( (?D罷g0\yϲ$-3D\_Ffh+Rq''?轹ze6<ŸQYcQ꘬:f;_iIV=ҔRHM߾yE*O絫{ds?Ѷhh$C(=jōv+.V\^-$K 9PQ!5Kx9=V-IQzSOHy VknI6DY!},}qz͎C94MH'>?vk4U]K `]o>k&k"DjtLtD7L'YV{n*G."tRf:Lu8.qoz{8?iֻW@ &֩o5"^!nb_֣Q5JGP0˜PI/>&]1tg@Dp.+j'ѶD$ԃHr9ұ^f). U' [T0"xf`ܺIU}y0|Mm0,a2<=Viv-b ,N/qᣕT˂qB*d'N;=lrrr_C?:݁NZŨT1 g\wqEW:8j;銄80ЭNjjvم4\IE*q"D3%;= :~7 1`ddqn9^V'q-)%׺fh@ fVw0yڐ@*@*%¢zA<(֯kXW&9dXW O6M܎"u %7FuckKNQwDN*Tr~mx òmBǐh/Ux5!a e@~!2~!)P1D ɵcQg|$6!iG٢kzzdCiڈYMfުn_]MӪiUj&tsq4v~ 8`iR~$ѽ Q(S3Yȕ$Si#]eeGY >;qGByj(%ڜwyA A|ɽUy-#uIzx v,1dE ucm.Bx_A~L}OL)eɧHg] ]4G*F1F0pK%cdꛖ'CFRdQMFV6z9R9D7?k.w-;cl+ѳ!6ц4kSę`V悵2^ $]O()/DKzUF8ZcZi5V jQ i"[uK]*3°!  *#sdG+6DBD2qW۫)T]!Wn?Ô{ ƻZջ* t0G9;ڈ:e0ಱ.ks_cPtH1b> 4/ENng`Dx,#DeKfNǾكFci6RׅiĴΝcZ!&i7a%=W_??.u(H oZ&vD)Xpex=`iz@o I.Dؗ\?g73O? \k.rp zPvvxO_דohZlDyS_p% fyz$fI9{%R(گ-6ŴTnIT4so!ek;]ir\A]C۝ӆL~{nc&U65GؐR,cvO1NYC;[\i΢Cp>fCNÎ_(:kౣyHZ]D@ |)"[1!2RTK|1t 䲓'fsp&Qۏ3{3y.9~7{{PVdLmT#`?It:ɀ)ti_p273lϙ<.G04yNtN]^G eZ \ 2y!(7xwx$R )COȫ_b.DUSKG;hSMNλ,SY{+Q] މ*_"w}w8gNIJ_Netzwerksimulation/graphics/originals/by.svg0000644000175000017500000002377410754616217020114 0ustar vogvog image/svg+xml