Home

Entwurf und Realisierung eines parallelen

Contents

1. VER KL DT Gesamtl nge GL 0 31 4 bit 4 bit 8 bit 16 bit seet PRI V D Z Be 3 bit U U U unbenutzt Identifikation ID FL Fragmentposition FP 63 16 bit 3 bit 13 bit Lebenszeit LZ Protokoll PR Kopfpr fsumme KP 95 8 bit 8 bit 16 bit 127 Senderadresse SA 32 bit 159 Empf ngeradresse EA 32 bit Optionen OP sind optional maximal 20 Byte 160 bit F llfeld FF Abbildung 5 12 Datagramm IP Dateneinheit vgl RFC 791 S 11 IP Daten maximal 65515 Byte brauchen nicht auf 32 bit ausgerichtet werden Format der IP Optionen Die Anzahl und L nge einzelner Optionen ist variabel Optionen sind strukturiert nach Klasse und Optionsnummer Bei einer Analyse kann gepr ft werden ob die Bits f r die Klasse der Option richtig gesetzt sind Von den vier m glichen Werten sind nur die Werte null 0 f r 19 Beispielsweise kann durch die strikte Vorgabe f r einen zu verwendenden Pfad gepr ft werden ob bestimmte Vermittlungsrechner erreichbar sind KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 117 Datagramm oder Netzwerk Kontrolle sowie zwei 2 f r Fehlersuche und Messungen erlaubt Die Werte eins 1 und drei 3 sind reserviert f r k nftige Erweiterungen Neben der Grobeinteilung in die Klassen null oder zwei mu verifiziert werden ob die Optionsnummer bekannt ist und mit der Optionsklasse vertr gl
2. n 1 Verbindung 5 PDUs oder Kontrollinformationen en gt Realisierung gt Interproze kommunikation O Proze Protokollinstanz Abbildung 3 14 Verbindungsparallelit t 3 3 3 5 Paketparallelit t Bei der Paketparallelit t versucht man die Granularit t gegen ber der Verbindungs parallelit t zu erh hen indem man nicht mehr Verbindungen als kleinste unabh ngige Einheiten ansieht sondern die Dateneinheiten Pakete aller Verbindungen als vonein ander unabh ngig betrachtet Jedes Paket kann konzeptionell unabh ngig von allen anderen verarbeitet werden vgl GNI93 S 221ff und Abbildung 3 15 F r eine ausf hrliche Diskussion der Vor und Nachteile der verschiedenen Ans tze vgl Zit91b WF93 Ben94 3 3 4 Bewertung der Konzepte zur parallelen Protokollverarbeitung Die oben vorgestellten Konzepte zur parallelen Protokollverarbeitung k nnen nun un ter Ber cksichtigung der Hardware vgl Abschnitt 3 2 f r eine Anpassung an ein paralleles Me werkzeug bewertet werden Die Bewertungskriterien aus Abschnitt 3 3 1 sind e Realisierbarkeit der funktionalen Anforderungen e Firweiterbarkeit e Leistungsf higkeit e Vertr glichkeit mit der Hardware KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 62 PDU lt gt Interproze kommunikation ss gt Realisierung Proze Abbildung 3 15
3. Terminator Speicher ease Kontrollflu Abbildung 5 1 Symbole der Datenflu diagramme KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 96 5 1 3 Die Prozesse des Transputernetzes als Datenflu diagramm Die Abbildung 4 1 wird hier als Datenflu diagramm dargestellt Es handelt sich hierbei um eine Verfeinerung der Abbildung 4 1 Da genau ein Proze auf jeden Transputer plaziert wird werden die Prozessoren in dieser Abbildung nicht mehr dargestellt Der Hostrechner Proze soll nicht modelliert werden Er wird deshalb als Terminator dargestellt Ein weiterer Terminator ist die Ethernet Schnittstelle Das so abgegrenzte System ist in Abbildung 5 2 dargestellt Man beachte die Numerierung der Prozesse die in den folgenden Abschnitten verfeinert werden Der Kontrollflu wird in dieser und den folgenden Darstellungen vernachl ssigt Hostrechner Proze globale Statistik Analysevorgaben Analysedaten PSTAT Analysedaten lokale ef N Analysedaten lokale Statistik Analysevorgaben PPAKET PPAKET Uhrzeit gefilterte Frames gefilterte Frames netznahe Statistik netznahe Statistik PDEV netznahe Statistik Ethernet Frames Netz Server Rohdatenerfassung Ethernet Frames Ethernet Schnittstelle Abbildung 5 2 Datenflu diagramm der Transputerprozesse Zum zweiten Proze PDEV ist anzumerken da hier
4. 2 Der Text ist nicht statisch sondern wird dynamisch durch neuen Text ersetzt Es wird ein Ringpuffer f r den Text ben tigt der eine bestimmte Anzahl von Text zeilen aufnehmen kann Der im Fenster sichtbare Textausschnitt entspricht einem Abschnitt dieses Ringpuffers der vom Benutzer vergr ert oder verkleinert werden kann P Durch Bet tigen eines Rollbalkens an der Seite des Textfensters kann der 8Der Benutzer kann durch Ver ndern der Fenstergr e w hlen wieviele Zeilen Text dargestellt werden KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 124 Benutzer den sichtbaren Textauschnitt vertikal verschieben Dadurch ist es m glich Textzeilen wieder sichtbar zu machen die aus dem Fenster herausgerollt wurden Die eigentliche Schwierigkeit besteht in der Berechnung des gerade sichtbaren Text ausschnittes Der sichtbare Textausschnitt wird von den vier Faktoren e Fenstergr e e Position des Rollbalkens e Schriftgr e und e berdeckung durch andere Fenster bestimmt Die berdeckung durch andere Fenster schr nkt den tats chlich sichtbaren Bereich determiniert durch die Fenstergr e ein Aus dem sichtbaren Bereich und der Schriftgr e kann man die Anzahl der sichtbaren Textzeilen berechnen Die Position des Rollbalkens kann man sich als Zeiger in den Ringpuffer vorstellen der auf die Startposition zum Auslesen der Textzeilen zeigt Die optionale Ausgabe des Textes in eine Datei ist leicht real
5. Schnittstelle zum Hostrechner verarbeitet werden m ssen Es sind nicht alle Auftr ge die auftreten k nnen ber cksichtigt sondern nur solche die mit einem externen Lastgenerator systematisch erzeugt werden konnten Bei den Auftr gen han delt es sich um Analysedaten f r die in der Tabelle angegebenen Protokolle die zum Hostrechner Proze bertragen werden sollen Alle anderen Prozesse synchronisieren sich ber die vollen Nachrichtenringpuffer Sie warten mit der Weiterverarbeitung bis wieder Nachrichten versendet werden k nnen Hier gehen jedoch auf keinen Fall Nachrichten verloren Der Netz Server kann bei voller Empfangswarteschlange allerdings keine Dateneinheiten mehr empfangen Treffen dennoch Dateneinheiten ein werden sie abgewiesen KAPITEL 7 LEISTUNGSBEWERTUNG DES PROTOTYPEN 163 Ethernet Ethernet IP Ethernet IP UDP IP UDP Ethernet UDP IP UDP 6 Tabelle 7 1 Die verschiedenen Auftr ge f r die Schnittstelle zum Hostrechner In Abbildung 7 1 ist der Grenzdurchsatz in Abh ngigkeit von der Auftragsgr e L nge in Byte dargestellt Erwartungsgem werden die k rzesten Auftr ge auch am schnellsten verarbeitet Grenzdurchsatz an der Schnittstelle zum Hostrechner 900 T T T T T 850 UDP J 750 7 650 o Auftraege s 550 7 Ethernet IP UDP 450 R 400 L L L L L 0 20 40 60 80 100 120 Auftragsgroesse in Byte Abbildung 7 1 Grenzdu
6. Soll die Datei nachtr glich von einem menschlichen Benutzer analysiert werden mu ein drittes Datenformat gew hlt werden Der Informationsgehalt ist u U derselbe wie bei der maschinennahen Darstellung Jedoch m ssen f r eine gute Lesbarkeit der Daten zus tzliche redundante Informationen mit in die Datei aufgenommen werden F r die programminterne Darstellung von Analysedaten sollen weitere Fenster der graphischen Benutzeroberfl che verwendet werden Die Ausgabe kann entweder als Textmeldung erfolgen analog zu Fehlermeldungen s o oder alternativ als Graphik Insbesondere die Standardauswertung Auslastung des Ethernet Segmentes soll als Liniengraphik dargestellt werden vgl Abschnitt 2 4 und 2 7 4 4 4 4 3 Essentielle Funktionen zur Konfigurierung der Transputer Die Transputer sollen beim Programmstart vom Host automatisch konfiguriert werden vgl Abschnitt 4 3 2 4 Dazu sind folgende Funktionen notwendig e Initialisieren der Transputer Zu jedem Zeitpunkt mu es m glich sein die Trans puter in einen definierten Zustand zur ckzusetzen Beispielsweise mu vor dem Laden von Programmen auf einen Transputer s u sichergestellt werden da der Transputer in einem bestimmten Betriebsmodus Bootmode ist Um einen Reset an einem Transputer durchzuf hren ist es notwendig eine Verbindung zu dem entsprechenden Transputer herzustellen Eine solche Verbindung mu beim Einsatz der TBs aus Abbildung 3 7 er
7. Werden zwei oder mehr Prozesse auf einen Prozessor abgebildet hei t die Zuordnung kontraktiv Will man stets eine injektive Zuordnung von Prozessen zu Prozessoren erreichen mu man bei T gt n Prozessen eine unvollst ndige Zuordnung machen bei der eine Teilmenge der Prozesse nicht zugeordnet wird Bei Kontraktion oder wenn gilt T lt n kann man eine vollst ndige Zuordnung erreichen Aus der Sicht der Proze verwaltung eines Parallelrechners kann sich eine Zuordnung mit der Zeit ndern Das hat haupts chlich zwei Gr nde 1 bereits aktive Prozesse terminieren und geben einen Prozessor frei 2 neue Programme sollen abgearbeitet werden bzw neue Prozesse werden dyna misch generiert und m ssen auf freie Prozessoren abgebildet werden Die Gesamtmenge der zu einem Zeitpunkt t zu verwaltenen Prozesse T setzt sich zusammen aus den aktiven Prozessen die bereits zum Zeitpunkt t auf Prozessoren KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 40 plaziert sind und den wartenden Prozessen T die bis zum Zeitpunkt t neu hin zugekommen sind Bezeichnet man die Menge der zum Zeitpunkt nicht belegten Prozessoren mit Pf so kann man den dynamischen Verlauf der Belegung als konser vativ oder als aggressiv bezeichnen Tkonservativ TP P Taggressiv Ti gt P 3 7 Der Unterschied besteht darin da bei der aggressiven Zuordnung Prozesse von den Prozessoren verdr ngt werden k nnen Diese k nnen entweder einem and
8. be trieben werden insbesondere sollte der Benutzer darauf verzichten w hrend einer Messung eine andere Anwendung zu starten Aufgrund der Bedienstrategie von OS 2 ist der Hostrechner Proze w hrend des Ladens einer anderen Applikation nicht in der Lage Me daten in ausreichender Geschwindigkeit entgegenzunehmen KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 105 5 3 Realisierung der essentiellen Funktionen Die Darstellung der Realisierung der essentiellen Funktionen orientiert sich an der Darstellungsreihenfolge beim Entwurf in Abschnitt 4 4 In Abschnitt 5 2 2 wird der Ger tetreiber f r die Ethernet Schnittstelle beschrie ben Hierbei handelt es sich sozusagen um das Rohdatenerfassungsmodul vgl Ab schnitt 4 4 1 In Abschnitt 5 3 2 wird das Analysemodul beschrieben Auf Grundlage der Paket parallelit t werden eintreffende Dateneinheiten analysiert Dabei wird u a auf die zur Zeit untersuchbaren Protokolle eingegangen 5 3 1 Realisierung des Ger tetreibers f r die Ethernet Schnittstelle F r die Realisierung dieses Werkzeuges konnte leider kein Zugang zu einem Hochge schwindigkeitsnetz eingerichtet werden Es mu te deshalb mit einer Schnittstelle zu einem Ethernet Netz gearbeitet werden vgl Abschnitt 2 7 4 Eine Besonderheit dieses Ger tetreibers ist die Organisation der Funktionen in Cli ent und Server Zwei Client Prozesse Sendeproze und Empfangsproze laufen unabh ngig vonei
9. ber den Namen der Messung verwaltet s u 6Der Grund daf r ist da ein Gro teil der Konfiguration getestet werden kann ohne den Server zu laden F r diese Testzwecke konnten ltere Versionen des Prototypen auch ohne Ethernet Schnittstelle betrieben werden Bei einer zuk nftigen Version sollte das Laden des Netz Server jedoch automatisch mit dem Laden der anderen Prozesse erfolgen In Zeile 8 informiert PDEV den Benutzer da er eine Nachricht vom Typ ST Status Informa tion durch eine Broadcast Nachricht ROUTE_BROADCAST erhalten hat Diese Nachricht hat das Versenden der Informationen aus Zeile 7 veranla t KAPITEL 6 ARBEITEN MIT DEM PROTOTYPEN 156 6 3 2 Definieren eines Filters Man sollte in jedem Fall einen Filter setzen der genau angibt welche Dateneinheiten f r die Messung analysiert werden sollen In diesem Fall sind das ARP und RARP Dateneinheiten Der Benutzer definiert einen entsprechenden Filter in Zeile 16 Der Versuch in Zeile 14 erzeugte eine Fehlermeldung Zeile 15 da ein Leerzeichen zwischen dem relationalen Operator und dem Vergleichswert rarp fehlt vgl Abschnitt 5 3 5 1 6 3 3 Ausw hlen der zu protokollierenden Informationen ber ein Dialogfeld legt der Benutzer fest welche Informationen aus den Dateneinhei ten selektiert werden sollen die den Filter passieren In Abbildung 6 8 werden dazu vom Benutzer die Protokolle ARP RARP ausgew hlt und angegeben
10. bertragen der Daten von und zur Schnittstelle ber den Bus des Hostrech ners ist mindestens vier mal langsamer als beim Zugriff auf andere Peripherie Das liegt an dem nur acht Bit breiten Datentor 3 Die Belastung des Hostrechner Prozessors ist w hrend der Daten bertragung von und zur Schnittstelle sehr hoch Die Ursache hierf r ist da es sich nicht um eine Direct Memory Access DMA Schnittstelle handelt die den Prozessor von der Daten bertragung fast v llig befreit sondern dieser jedes Byte einzeln kopieren mu Au erdem ist bei diesem Kopiervorgang f r jedes Byte die Sende bzw Empfangsbereitschaft der Schnittstelle zu berpr fen polling 7 1 2 Analyse des prim ren Engpasses Dieser Engpa kann zu Datenverlust f hren wenn die Nachrichten zum Hostrechner auf PSTAT den Nachrichtenringpuffer gef llt haben und durch sukzessives Auff llen der Nachrichtenpuffer der anderen Prozesse R ckstau letztendlich beim Netz Server Dateneinheiten abgewiesen werden Durch die netznahen Statistiken die der Benutzer mit dem Kommando status net direkt vom Netz Server anfordern kann kann man feststellen ob Dateneinheiten abgewiesen werden mu ten Hiermit konnte gemessen werden bei welcher Art von Auftr gen es zu einem R ckstau an der Schnittstelle zum Hostrechner kommt In Tabelle 7 1 sind die verschiedenen Auftr ge aufgelistet die von der Funktions einheit
11. hnliche Angaben f r die anderen analysierbaren Protokolle gemacht werden Wird das Werkzeug um Analysefunktionen f r andere Protokolle erweitert m ssen entspre chende Wahlm glichkeiten f r diese Protokolle vorgesehen werden 6 3 4 Starten einer Messung Zum Starten der Messung wird das Kommando enable eingegeben Zeile 18 Der PDEV Proze gibt in den Zeilen 20 23 mehrere Debug Informationen aus die unter anderem besagen da der P Code des Filters empfangen wurde vgl Abschnitt 5 3 5 2 Der Netz Server beginnt mit dem Empfang der Dateneinheiten Werden ARP oder RARP Dateneinheiten empfangen stellt der Hostrechner Proze diese tabella risch in dem Fenster ARP RARP Tabelle dar Zus tzlich wird angezeigt wie oft nach einer Adresse gefragt wurde und wie oft eine ARP Antwort f r diese Adresse empfangen wurde Ein Beispiel f r die Ausgabe im Fenster ist in Abbildung 6 10 dargestellt 6 3 5 Unterbrechen einer Messung Eine Messung wird durch das Kommando disable Zeile 24 unterbrochen Man mu Messungen unterbrechen um neue Filter zu definieren Man kann Messungen unterbrechen um beispielsweise Ausgaben in ein Fenster zu verhindern ARP RARP Tabelle oder MBit s Das ist beispielsweise sinnvoll um sich Ausgaben in den Fenstern mp Ruhe ansehen zu k nnen KAPITEL 6 ARBEITEN MIT DEM PROTOTYPEN 158 x ARP RARP Tabelle ARP RARP Tabelle Format
12. zen abzuschotten bzw die Kommunikation zwischen den Netzen zu reglementieren bieten Messungen die M glichkeit e potentielle Sicherheitsl cken aufzuzeigen e den Zugriff auf sensible Daten zu registrieren e Verst e gegen Sicherheitsma nahmen zu erkennen 1 3 1 4 Aufdecken potentieller Sicherheitsl cken Potentielle Sicherheitsl cken bilden Rechner die als Server Dienste ber ein Netz anbieten Bei einer zu freiz gigen oder einfach falschen Konfiguration k nnten Be nutzer ber ein Netz den Betrieb des Servers bewu t oder unbewu t st ren Durch Messungen die Konfigurationsfehler aufdecken k nnen geeignete Gegenma nahmen veranla t werden vgl z B Kus95 5Sogenannte Firewalls vgl Kie95 bernehmen die Abschottung des lokalen Netzes nach au en Diese Technik hat jedoch eine Reihe von Nachteilen Insbesondere ist hier zu nennen da dedizierte Rechner f r diese Aufgabe bereitgestellt werden m ssen die potentiell Engpa der gesamten Kom munikation in einem LAN werden k nnen Gerade weil die Firewalls die Kommunikation von und nach au en berwachen mu die gesamte LAN WAN Kommunikation ber sie ablaufen KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 16 1 3 1 5 Zugriff auf sensible Daten Der Zugriff auf sensible Daten kann analog zum Accounting s o gemessen werden Dieses Vorgehen ist aus Datenschutzgr nden selber nicht unproblematisch Dennoch kann so registriert werden
13. Abbildung 4 1 pla ziert wird Dieser Proze mu nachtr glich durch eine Funktion die auf P5 abl uft auf den Transputer P6 geladen werden Au erdem kann aufgrund des geringen Spei chers der diesem Proze auf P6 vgl Abbildung 4 1 zur Verf gung steht nur eine gegen ber dem Proze Template stark vereinfachte Struktur realisiert wer den Hauptaufgabe dieses Prozesses ist es empfangene Dateneinheiten an den Proze PDEV s u weiterzuleiten und netznahe Statistiken zu generieren zu PDEV 2 netznahe Statistik netznahe Statistik anfertigen Pr fsummenfehler i EN Ethernet Frames Kollisionen usw Frames pr fen Ethernet Frames von der Ethernet Schnittstelle Abbildung 5 4 Datenflu diagramm des Netz Servers 5 2 3 Der Proze PDEV Der Proze PDEV soll auf den Transputer P5 vgl Abbildung 4 1 plaziert wer den Die Hauptaufgabe dieses Prozesses ist das Empfangen Filtern und Verteilen der Dateneinheiten die von der Rohdatenerfassung an ihn gesendet werden KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 99 5 2 3 1 Thread zum Filtern und Verteilen von Dateneinheiten Offensichtlich werden dazu die Filterfunktion und die Verteilungsfunktion vgl Ab schnitt 4 5 1 ben tigt Diese beiden Funktionen werden innerhalb eines Threads ausgef hrt da sie immer nacheinander ausgerufen werden m ssen Eine Datenein heit wird beim Filtern
14. Kommando s veranla t werden Das Me werkzeug k nnte so als intelligente Me station in einem Verteilten System ein gesetzt werden Die erfa ten Rohdaten und die Analyseergebnisse k nnten unter Verwendung des Simple Network Management Protocol SNMP vom Me werkzeug in eine verteilte Datenbank abgelegt werden Diese Integrationsmethode wird beispielsweise in Par95 diskutiert Eine Anwendung eines solchen NMS ist die berwachung von zugesicherter Dienstg te auch Quality of Service QoS genannt vgl z B FY94 Eine weitere Integrationsm glichkeit f r Me werkzeuge wird in D 94 diskutiert Das Me werkzeug dient hier der modellgest tzten Bewertung von Verteilten Systemen Eine hnliche Vorgehensweise wird in dM95 beschrieben Die Integration von Me werkzeugen in Performance Managementsysteme vgl Abschnitt 1 3 2 7 ist im Kontext von Hochgeschwindigkeitsnetzen HSN besonders interessant Durch die hohen bertragungsgeschwindigkeiten kann ein HSN innerhalb weniger Millisekunden von einem unkritischen Zustand in einen kritischen Zustand wechseln der nur durch Management Eingriffe behoben werden kannt Eine fr hzei tige Erkennung kritischer Zust nde ist bei HSN durch automatische berwachung und Reaktion mit einem Performance Managementsystem m glich 5 7 4 Vergleich mit anderen Werkzeugen der Kommunikationsme technik Ein berblick ber Werkzeuge der Kommunikationsme t
15. Local Computer Networks pages 375 384 Minneapolis Minnesota oct 1988 H U Heiss Prozessorzuteilung in Parallelrechnern Reihe Informatik Band 98 BI Wiss Verlag 1994 U Hinrichsen Ein Monitor f r ein autonomes Daten bertragungssystem Informatik Bericht 86 05 TU Braunschweig 1986 A I Holub Compiler Design in C Prentice Hall Englewood Cliffs New Jersey 1990 P Holsberg UNIX Desktop Guide to Tools SAMS Prentice Hall 1992 Inmos Limited Transputer Reference Manual 1988 Inmos Limited Transputer Development System 2 edition 1990 International Business Machines Corporation IBM Operating System 2 I O Subsystems and Device Support Volume 1 Device Drivers 1989 R Jain The Art of Computer Systems Performance Analysis Techniques for Experimental Design Measurement Simulation and Modeling John Wiley amp Sons Inc 1991 F Jobst Compilerbau Von der Quelle zum professionellen Assemblertext Hanser M nchen Wien 1992 E Jessen and R Valk Rechensysteme Grundlagen und Modellbildung Springer Verlag Berlin Heidelberg New York 1987 LITERATURVERZEICHNIS 184 K 95 Ker92 Kie95 KR92 Kus95 Lip88 MP86 Pag91 Par95 Pen92 Roc90 SF85 R Klar et al Messung und Modellierung paralleler und verteilter Rechensy steme B G Teubner Stuttgart 1995 H Kerner editor Rechnernetze nach OSI Addison Wesley 1992 M Kienle Marke
16. MBit s mit eingeblendeter Legende Die y Achse ist auf ein Megabit skaliert Die Auslastung ist demnach gering KAPITEL 6 ARBEITEN MIT DEM PROTOTYPEN 160 Abbildung 6 11 Fenster MBit s Kapitel 7 Leistungsbewertung des Prototypen In diesem Kapitel wird die Leistungsf higkeit des Prototypen bewertet In Abschnitt 7 1 werden zwei Engp sse identifiziert Weitere Komponenten lassen sich unter ge eigneten Annahmen bewerten In Abschnitt 7 2 wird der Grenzdurchsatz f r einen Pakettr ger und f r das Filtern berechnet 7 1 Engp sse des Prototypen Beim Arbeiten mit dem Prototypen kann es passieren da der Benutzer eine Warnung im Standardausgabe Fenster erh lt Es gibt zwei Warnungen die unabh ngig von einander auftreten k nnen Bei der einen Warnung wird dem Benutzer mitgeteilt da Analysedaten m glicherweise aufgrund eines Nachrichtenstaus an der Schnittstelle zum Hostrechner verlorengehen Die Ursachen hierf r werden in Abschnitt 7 1 1 diskutiert Die zweite Warnung zeigt an da m glicherweise Ethernet Frames von der Ether net Schnittstelle vernichtet werden weil die Auslastung der Schnittstelle zu hoch ist Die Ursache f r diese Warnung wird in Abschnitt 7 1 4 dargestellt Wenn eine dieser Meldungen auftritt sind die Analyseergebnisse vermutlich falsch oder unvollst ndig Der Benutzer sollte deshalb pr fen ob die aktuelle Messung wie derholt werden kann ygl JV87
17. Server 1100 T T T T T T T T T 1000 o o 900 o A 800 o J 700 1 Auftraege s 600 o J 500 400 7 300 o 4 o 200 L L L L L 1 L L L 364 504 634 804 874 1154 1254 1344 1526 Auftragsgroesse in Byte Abbildung 7 3 Grenzdurchsatz in Auftr ge s Man erreicht dies durch die Angabe mur Lastinfo in dem Dialog aus Abbildung 6 8 Dadurch senden die Pakettr ger nur noch lokale Statistiken an PSTAT PSTAT bereitet daraus eine 32 Byte lange Nachricht f r den Hostrechner Proze die einmal pro Sekunde versendet wird Das liegt nat rlich weit unter dem Grenzdurchsatz so da hier kein Engpa auftritt Der Lastgenerator konnte mit einer Rate von maximal 1000 Dateneinheiten pro Sekunde betrieben werden 61500 Byte Nutzdaten zuz glich Protokoll Overhead vgl Abbildung 5 10 KAPITEL 7 LEISTUNGSBEWERTUNG DES PROTOTYPEN 166 Berechnet man daraus den Durchsatz auf dem Ethernet Segment den der Netz Server noch vollst ndig mitschreiben kann so ergibt sich folgende Kurve vgl Ab bildung 7 4 Grenzdurchsatz am Netz Server 6 T T T T T T T T T MBit s 1 L L L L l L l l L 364 504 634 804 874 1154 1254 1344 1526 Auftragsgroesse in Byte Abbildung 7 4 Grenzdurchsatz in MBit s Der Verlauf der Kurve kann nicht definitiv gekl rt werden Vermutlich h ngen die Abweichungen von einem linearen Verlauf mit der Pufferverwaltung auf dem Netz Server
18. da die Infor mationen der ARP RARP Dateneinheiten protokolliert werden sollen vgl Abschnitt 5 3 4 3 sl Protokolle w hlen Protokolle f r Analyse w hlen Global Ethernet Ethernet _ IEEE802 3 ARP IP VI ARP RARP IP d J ICMP _ UDP UDP ren ETP TER ICMP e protokollieren Q Me daten erfassen nur Lastinfo Seite 1 ECH ol Cancel Help Abbildung 6 8 Protokolle w hlen Zu jedem Protokoll kann der Benutzer au erdem angeben welche Informationen protokolliert werden sollen vgl Abbildung 6 9 In diesem Fall ist das unn tig da die Angaben nur im ARP RARP Fenster angezeigt werden sollen und die daf r ben tigten Informationen dem Programm bekannt sind H tte der Benutzer beispielsweise mit set output arp out eine Protokollierungsda tei hier arp out angegeben w rden die in Abbildung 6 9 selektierten Informationen zus tzlich in dieser Datei protokolliert Wie aus Abbildung 6 9 ersichtlich ist k nnen KAPITEL 6 ARBEITEN MIT DEM PROTOTYPEN 157 e e a aeaeaeaee Parameter f r ARP RARP EE Global V Sender HW Ethernet ARP V Empf nger HW IP UDP d Sender IP a 2 TCP H i M Empf nger IP ICMP d L nge redundant Seite 3 Dr el Cancel Help Abbildung 6 9 Zu protokollierende Informationen w hlen
19. der Messungen am Kommunikationssystem zur Protokollverarbeitung in Endsystemen deutlich vgl Abschnitt 3 3 2 Ka 37 D Ba UDP TCP SI 0011 0006 Sk 16 1 s N IP Protocol IEE802 3 IP ARP RARP lt 05EE 16 Ethernet Type Abbildung 4 3 Erkennungsbaum f r Protokolle Ethernet Type und IP Protocol sind Beispiele f r solche Informationen Es handelt sich hierbei um Werte die aus der Dateneinheit des jeweiligen Protokolls gewonnen werden vgl Abschnitte 5 3 2 2 5 3 2 7 KAPITEL 4 ENTWURF DES MESSWERKZEUGES 78 Analysieren von erkannten typisierten Dateneinheiten Wurde im ersten Schritt eine Dateneinheit erkannt kann diese Dateneinheit analy siert werden Eine Analyse ist bereits nach einer partiellen Erkennung m glich So kann eine als Ethernet Frame typisierte Dateneinheit bereits analysiert werden ohne da zuvor in weiteren Iterationen eine genauere Typisierung vorgenommen wird Vor aussetzung f r eine Analyse auf der Protokollebene n ist demnach nur eine Iden tifizierung Erkennung bis zur Protokollebene n Das Ergebnis der Analyse ist die vollst ndige Beschreibung der variablen Informationen einer Dateneinheit und die Verifikation der invarianten Informationen einer Dateneinheit auf einer bestimmten Protokollebene Damit beinhaltet die Analyse einer Dateneinheit der Ebene n auch das Erkennen des Typs einer eingebetteten Dateneinheit der Ebene n 1 sofern vor handen Die vol
20. keitsnetze idee nee ee EN E E 33 2 7 1 Anforderungen an die Erweiterbarkeit 2 2 22 20 34 2 7 2 Anforderungen an die Leistungsf higkeit 2 34 INHALTSVERZEICHNIS 2 7 3 Anforderungen an die Skalierbarkeit e 2 74 Zusammenfassung der Anforderungen 3 Abbilden der Prozesse auf die Hardware 3 1 Zuordnungsproblem 2 2 non nn 3 1 1 Zuordnung von Algorithmen zu Prozessoren 3 1 2 Formale Pr zisierung der Zuordnung 2 22 2 0 3 1 3 Ziele bei der Zuordnung 3 1 4 Zeitpunkt der Zuordnung e 3 2 Verf gbare Hardware und Entwicklungsumgebung 3 2 1 Transputer und Transputer Boards f r PCs 3 2 2 Entwicklungsumgebung 2 2 nn a 3 3 Parallele Protokollverarbeitung 3 3 1 Bewertungskriterien 2 222mm onen 3 3 2 Vergleich zwischen Endsystem und Monitor 3 3 3 Klassifikation der parallelen Protokollverarbeitung 3 3 4 Bewertung der Konzepter Entwurf des Me werkzeuges 4 1 Restriktionen durch die Hardware 4 2 Wahl eines Konzeptes zur parallelen Protokollanalyse 4 3 Grobgliederung des Me werkzeuges durch Prozesse 4 3 1 Die Anzahl der Prozessoren 4 3 2 Die wesentlichen Prozesse des Me werkzeuges 4 3 3 Entwurf der Grobstruktur des Me werkzeuges 4 4 Entwurf der essentiellen Funktionen 2 222 nennnen 4 4 1 Entwurf der essentiellen Funktionen f r die Rohdatenerfassung 4 4 2 Entwurf der essentiellen Funktionen f
21. kommunikation auf grund der Vielzahl von Prozessen pro Protokoll erheblich ist Bei einer Zuordnung der vielen Prozesse auf Prozessoren ergibt sich weiterer Overhead durch die vielen Kontextwechsel die f r den quasiparallelen Ablauf der Prozesse auf einem Prozessor n tig sind Aus der Sicht der Realisierbarkeit und der Erweiterbarkeit ist dieses Konzept v llig ungeeignet f r eine Anpassung an die parallele Protokollanalyse Das Auffinden der inh renten Parallelit t ist schon f r ein einziges Protokoll aufwendig vgl Zit91a Soll das Werkzeug ganze Protokollfamilien analysieren k nnen m te bei diesem Kon zept f r jedes einzelne Protokoll eine eigene Analyse angefertigt werden Ein derartiger Arbeitsaufwand ist nicht zu vertreten Die Vertr glichkeit mit der Hardware mu u U erst hergestellt werden In Zit91a S 139 wird beschrieben da spezielle Kommunikationsprozesse realisiert wurden um die vielen Kommunikationskan le der Protokollfunktion zu b ndeln da die Trans puter nur vier Links haben Diese Restriktion der Hardware konnte nur durch zus tz lichen Overhead n mlich durch die Kommunikationsprozesse ausgeglichen werden 3 3 4 4 Bewertung der Verbindungsparallelit t Die Verbindungsparallelit t ist sehr leicht realisierbar und erweiterbar Auf jedem Prozessor wird der gleiche Proze plaziert so da jeder Prozessor eine Verbindung unterst tzen kann Auch hier kann wie bei der Protokollpipe
22. nem erkannten Schl sselwort wird eine eindeutige Nummer zugeordnet Die ansch lie ende syntaktische berpr fung der Eingabe wird dadurch beschleunigt Anstelle der Schl sselw ter m ssen nur noch Token Nummern verarbeitet werden F r die syntaktische berpr fung der Eingabe wurde ein Yacc Skript geschrie ben Darin ist festgelegt wie die verschiedenen Schl sselw rter und Symbole angeord net werden d rfen und welche Umwandlungsfunktionen beim Erkennen einer g ltigen Benutzereingabe ausgef hrt werden sollen Das Werkzeug Bison vgl Abschnitt 3 2 2 1 generiert aus diesem Skript ebenfalls eine Funktion Erweiterungen um neue Kommandos sind daher sehr leicht durch Erg nzen von Regeln in den beiden Skripten m glich Durch die Trennung der lexikalischen und syntaktischen berpr fung der Eingabe kann man die beiden Module unabh ngig voneinander austauschen oder erweitern Beispielsweise kann man die Schl sselw rter gegen andere austauschen Durch die Verwendung der Werkzeuge Les und Yacc werden Erweiterungen deut lich vereinfacht Der Programmierer schreibt Regeln nach denen die berpr fung der Eingabe vorgenommen wird Er mu jedoch nicht spezifizieren wie diese Regeln zu berpr fen sind Bei einer handgeschriebenen berpr fung w rde dieser Aspekt dominieren Die Abfrage der Benutzereingabe bernimmt ein Dialogelement der graphischen Benutzerschnittstelle Dadurch sind sehr komf
23. nnte man die Filterfunktionen in die Pakettr ger einbinden Bei mehr als einem Pakettr ger w re dadurch eine Leistungssteigerung wahrscheinlich Der Grenzdurchsatz der Pakettr ger s u w rde sich jedoch durch den zus tzlichen Filteraufwand verringern 7 2 2 Grenzdurchsatz des Pakettr gers Zum Messen der Analysezeiten f r verschiedene Dateneinheiten wurde durch Filter je weils ein bestimmter Auftragstyp aus Tabelle 7 1 ausgew hlt Durch eine Nachricht an den Pakettr ger konnte dann die Analysezeit f r eine bestimmte Anzahl von Analysen derselben Dateneinheit gemessen werden Der k rzeste Auftrag bei der Analyse ist das Berechnen der Auslastung des Ethernet Segmentes Die daf r ben tigte Zeit ist vernachl ssigbar klein Werden die Datenein heiten hingegen vollst ndig ausgewertet so ergeben sich signifikante Unterschiede in den Analysezeiten der Protokolle bzw Protokollkombinationen aus Tabelle 7 1 Der Grenzdurchsatz ist in Abbildung 7 6 angegeben Die Beschriftung der Kurven hat die Form ps data si bezeichnet die analysierten Protokolle Steht hier ein e wurden Analysedaten f r Ethernet erzeugt Ein steht analog f r IP und ein ui f r UDP Es ergeben sich die gleichen Kombinationsm glichkeiten wie in Tabelle 7 1 Die ben tigten Zeiten f r die Abarbeitung von 100 900 Auftr ge wichen bei den verschiedenen Me wiederholungen maximal Zus voneinander ab Die Auftr ge wur den von einem hochpriorisierten T
24. r Nachrichten eingerichtet werden und die Symbolverwaltung f r den Benutzer Au erdem l dt der Hostrechner Proze die Prozesse auf die Transputer Dazu verwendet er die in Abschnitt 5 3 4 6 beschriebene Funktion e Reagieren auf Benutzereingaben Dazu werden die Unterst tzungsfunktionen aus Abschnitt 5 3 4 1 benutzt Reagieren auf Nachrichten der Transputer die vom anderen Thread empfangen wurden Im wesentlichen handelt es sich hierbei um Me ergebnisse Diese Er gebnisse werden on line angezeigt oder durch die Unterst tzungsfunktionen aus Abschnitt 5 3 4 3 weiterverarbeitet Zu dem Hostrechner Proze ist noch anzumerken da er sehr hohe Anforderungen an die Leistungsf higkeit des Hostrechners stellt Das liegt vor allem an der st ndi gen berwachung der Sendebereitschaft des Transputers mittels polling vgl Ab schnitt 5 4 4 Dar ber hinaus ist die Verwaltung der Benutzerein und ausgabe ber die graphische Benutzeroberfl che sehr aufwendig Der Von Neumann Flaschenhals macht sich ebenfalls bemerkbar Die Analyseergebnisse m ssen von den Transputern empfangen und im Hauptspeicher abgelegt werden Im Zuge der Weiterverarbeitung durch die Exportfunktionen werden sie dann erneut ber den Bus des Hostrechners gesendet Aus diesem Grund ist eine gewisse Zur ckhaltung durch den Benutzer angebracht So sollten m glichst keine Anwendungen zeitgleich mit dem Hostrechner Proze
25. r den einfachen Zugriff auf die Rohdaten und den Ergebnisspeicher Zeilen 17 21 29 30 wird hier eine Typumwandlung auf Grundlage eines Zeigers vor genommen Danach ist ein strukturierter Zugriff auf einen vormals unstrukturierten Bereich void in Zeile 5 im Speicher m glich In der ebenfalls verf gbaren Programmiersprache OCCAM w re ein derart einfa cher und eleganter Zugriff auf den Speicher nicht m glich da OCCAM keine Zeiger kennt Zu dem Pseudo C Code ist noch anzumerken da sich hier die wesentlichen An weisungen in den Zeilen 17 21 und 29 47 befinden Einerseits ist hier die Analyse in abstrakter Form dargestellt 17 21 andererseits das Erkennen und Analysieren eines eingebetteten Protokolls 29 47 13Die Analyse wird hier hinter den Funktionsaufrufen f fn 2 verborgen KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 111 5 3 2 2 Realisierung der Analysefunktion f r Ethernet IEEE 803 2 Fra mes Ethernet Frames laut Xerox Digital Intel Spezifikation f r Ethernet 2 0 unter scheiden sich von IEEE 802 3 Frames in der Interpretation des mit Frame Typ bzw Daten L nge bezeichneten Abschnitts des Frames vgl Abbildung 5 10 W hrend hier bei einem Ethernet Frame eine Typangabe die im Daten Bereich eingekapselte Dateneinheit einer h heren Protokollebene identifiziert steht bei IEEE 802 3 Frames an dieser Stelle eine L ngenangabe die die Gesamtl nge des
26. s u Prozesse Es wird eine Broadcast Nachricht an alle Transputerprozesse gesen det Die Prozesse antworten mit einer Zustandsmeldung Der Benutzer kann durch diese Funktion berpr fen ob alle Prozesse auf Nachrichten reagieren Netz Es werden die netznahen Statistiken angefordert und ausgegeben vgl Abschnitt 4 4 1 ARP Tabelle Das Fenster der ARP Tabelle wird wieder hergestellt bzw vor allen anderen Fenstern angezeigt Typischerweise wird das ARP Fenster von der graphischen Oberfl che gel scht da es nur bei Messungen ben tigt wird in deren Verlauf ARP RARP Dateneinheiten analysiert werden ber diesen Men eintrag kann das tempor r gel schte Fenster wieder hergestellt werden KAPITEL 6 ARBEITEN MIT DEM PROTOTYPEN 150 PM Frontend STDOUT ile Show Messung Test Aktuelle Messung Prozesse Netz ARP Tabelle Abbildung 6 4 Das Show Men 6 1 1 3 Das Messung Men Die wichtigsten Kommandos zur Steuerung einer Messung sind hier zusammengefa t e Aktuelle Messung Dieser Eintrag entspricht dem Eintrag im Show Men e Starten Eine Messung wird aktiviert s u e Unterbrechen Eine Messung wird unterbrochen s u e Parameter festlegen Ein weiteres Fenster mit Dialogen zum Ausw hlen der zu analysierenden Protokolle wird abgerufen s u PM Frontend STDOUT Ol le Show Messung Test Help Aktuelle Messung Starten Unterbrechen Parameter festlegen Abbildung 6 5 Da
27. tzliche M glichkeiten f r die Realisierung des Werkzeuges dis kutiert werden Nach der Festlegung der funktionalen Anforderungen mu vor der Realisierung berpr ft werden wie diese Funktionen strukturiert werden k nnen Ziel einer Strukturierung ist die Festlegung welche Funktionen zu Prozessen zusammen gefa t werden Die Prozesse wiederum sind die elementaren Einheiten die auf die verf gbare Hardware abgebildet werden In Abschnitt 3 1 wird ein berblick ber theoretische Aspekte dieser Zuordnungsprobleme gegeben Ein wichtiges Kriterium f r die Zuordnung der Funktionen ist die Hardware HW da sich aus deren Eigenschaften eine Vielzahl von Randbedingungen Restriktionen f r das Plazieren von Prozessen ergeben Eine Darstellung der zur Verf gung stehen den HW und der Entwicklungswerkzeuge ist in Abschnitt 3 2 In Abschnitt 3 3 werden Konzepte zur parallelen Protokollverarbeitung unter den Aspekten der zu implementierenden Funktionen den Einschr nkungen durch die HW der Erweiterbarkeit und der Leistungsf higkeit diskutiert Die Entscheidung f r eines dieser Konzepte legt wesentliche Aspekte f r die Realisierung des Werkzeuges fest In Kapitel 4 kann auf Grundlage der hier vorgestellten M glichkeiten und Restrik tionen der Entwurf eines Prototypen diskutiert werden 3 1 Das Zuordnungsproblem der Parallelverarbeitung In diesem Abschnitt soll das Problem der Zuordnung von Programmen und Prozes sen zu den verf gbaren Proz
28. zusammen Dort wird der Speicher f r eine empfangene Dateneinheit aus kleinen Empfangspuffern zusammengestellt um den vorhandenen Speicher konomi scher zu nutzen Der Verwaltungsaufwand f r das Allozieren Verketten Belegen und Freigeben dieser Empfangspuffer scheint bei gro en Dateneinheiten f r das Abfallen der Kurve verantwortlich zu sein 7 1 5 Ma nahmen w hrend und am Ende der Messung Dateneinheiten werden grunds tzlich nur von der Ethernet Schnittstelle vernichtet Falls nicht mehr ausreichend Platz f r eine eintreffende Dateneinheit im Speicher vor handen ist vernichtet die Rohdatenerfassung die Dateneinheit und aktualisiert die netznahe Statistik entsprechend Nach jeder Messung insbesondere wenn eine der obigen Warnungen auftritt sollte der Benutzer mit dem Kommando status net die Man will nicht f r jeden Frame 1518 Byte a priori reservieren KAPITEL 7 LEISTUNGSBEWERTUNG DES PROTOTYPEN 167 netznahen Statistiken anfordern Nur so kann mit Sicherheit festgestellt werden ob Dateneinheiten w hrend der Messung verloren gegangen sind W hrend der Messung sollte der Benutzer die Auslastung des Ethernet Segmentes mit Hilfe der Fensters MBit s beobachten Tritt eine der obigen Warnungen w hrend eines kurzzeitigen Burst auf sollte das Me experiment nicht vorzeitig abgebrochen werden Kommt es vor dem prim ren Engpa durch sto artige Last zu einem Stau wird das durch die Nachrichtenpuffer a
29. 1 3 Messungen am Kommunikationssystem 2 2 222mm 13 1 3 1 Die Notwendigkeit f r Messungen am Kommunikationssystem 13 1 3 2 Werkzeuge zum Erfassen von Me daten 2 2 2 2 16 1 4 Klassifikation von Monitoren e 19 1 4 1 Klassifikation nach der Me aufgabe 2 2 222 0 19 1 4 2 Klassifikation nach der Architektur 20 1 4 3 Klassifikation nach dem Funktionsumfang 2 2 23 1 4 4 Klassifikation nach dem Me verfahren 24 1 4 5 Klassifikation nach der Ergebnispr sentation 24 1 4 6 Zusammenfassung der Klassifikation 25 2 Anforderungen an ein Me werkzeug 26 2 1 Anforderungen seitens der Me aufgabe Datenerfassung und Analyse 26 2 1 1 Schicht 1 physikalische Schicht 26 2 1 2 Schicht 2 Datensicherungsschicht 2 2 22 22 28 2 1 3 Schicht 3 Vermittlungsschicht e 29 2 1 4 Schicht 4 Transportschicht 2 22 222m nennen 29 2 1 5 Schicht 5 7 Kommunikationssteuerungs Darstellungs und An wendungsschicht 22 2 222 or nn 29 2 1 6 Alternative Schichteneinteilung 30 2 1 7 Schichtunabh ngige Anforderungen 2 22 2 2200 30 2 2 Anforderungen an das Filtern der Daten 2 2 222020 30 2 3 Anforderungen an das Bewerten der Daten 2 22 2 0 31 2 4 Anforderungen an das Anzeigen der Daten 2 2 22 20 31 2 5 Anforderungen an das Verwalten der Daten 32 2 6 Anforderungen der Dentzer 33 2 7 Anforderungen an ein paralleles Me werkzeug f r Hochgeschwindig
30. 1 Anforderungen an die Erweiterbarkeit Ein Werkzeug sollte grunds tzlich erweiterbar sein um neuen Benutzeranforderungen gerecht zu werden Es gibt genau zwei M glichkeiten ein Werkzeug um neue Funktionalit t zu erwei tern Einerseits kann man externe Werkzeuge benutzen um die exportierten Daten weiterzuverarbeiten Andererseits kann man neue Funktionalit t direkt in das Werk zeug einbauen Daraus ergeben sich die folgenden Minimalanforderungen e Die analysierten Daten m ssen durch Exportfunktionen in eine ACSII Datei ge schrieben werden e Das Format der exportierten Daten sollte einer maschinell leicht erkennbaren Syntax gen gen um den externen Werkzeugen einen effizienten Zugriff auf die Daten zu erm glichen e Die Grundfunktionalit t mu modular programmiert werden um sp tere Erwei terungen zu vereinfachen e Die Schnittstellen dieser Module sind zu dokumentieren 2 7 2 Anforderungen an die Leistungsf higkeit Hochgeschwindigkeitsnetze HSN zeichnen sich insbesondere durch hohe bertra gungsgeschwindigkeiten aus Ein Me werkzeug f r Hochgeschwindigkeitsnetze mu grunds tzlich in der Lage sein alle Dateneinheiten ohne Verluste auszuwerten Dies ist ein wesentlicher Unterschied zwischen einem Endsystem und einem dedizierten Me werkzeug vgl Abschnitt 3 3 2 Endsysteme empfangen nur die Dateneinheiten die fr sie bestimmt sind Diese gegen ber einem Endsystem vielfach h here Anforderung an die Leistung
31. 5 10 LLC Dateneinheit Steht f r das erkannte Protokoll eine Analysefunktion zur Verf gung kann sie an dieser Stelle aufgeru fen werden 4 Identifizieren des Senders und des Empf ngers 5 3 2 3 Realisierung der Analysefunktion f r ARP RARP Dateneinhei ten Das Address Resolution Protocol ARP und das Reverse Address Resolution Pro tocol RARP sind Protokolle der TCP IP Protokollfamilie Die Hauptaufgabe die ser beiden Protokolle besteht darin physikalische Adressen in diesem Fall Ethernet Adressen auf Internet Adressen IP Adressen und IP Adressen auf physikalische Adressen abzubilden ARP und RARP benutzen das gleiche Nachrichtenformat vgl Abbildung 5 11 Die Erkennung s o ist bei einer Einbettung dieser Protokolle in Ethernet Frames trivial Laut RFC 1700 ist der Frame Typ f r ARP auf 080616 und f r RARP auf 083516 zu setzen vgl auch Abbildung 4 3 Die Analyse von ARP und RARP mu folgendes leisten 1 Im Feld Hardware Typ mu der Wert 1 f r Ethernet verifiziert werden 15Mit Nachrichtenformat ist die Struktur der Dateneinheit eines Protokolls gemeint KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 113 2 Im Feld Protokoll Typ mu der Wert 080016 f r IP verifiziert werden 3 Im Feld Funktion mu bei ARP entweder der Wert 1 f r ARP Anfrage ARP request oder der Wert 2 f r ARP Antwort ARP response stehen Bei RARP 3 RARP request oder 4 RAR
32. 7 5 ist daher der Grenzduchsatz f r verschiedene Filter Auftr ge angegeben Die Kurven sind mit fxy data beschriftet Es handelt sich dabei um Filter mit x Vergleichen ber eine L nge von jeweils y Byte KAPITEL 7 LEISTUNGSBEWERTUNG DES PROTOTYPEN 168 Grenzdurchsatz verschiedener Filter 25000 4 K S Se 2 E o S 7 S 5 R 12 data 16 data o 21 data x 22 data A 20000 52 data x 4 B D D D D D D e D 0 3 15000 J E bi an e x x x x x x x x x 5 A A A A A A A A A 10000 d 5000 xX x X X X x X X X 0 L L L L l o 200 400 600 800 1000 1200 Anzahl der Wiederholungen Abbildung 7 5 Grenzdurchsatz bei verschiedenen Filter Auftr gen Erwartungsgem sinkt der Durchsatz mit h herer Filterkomplexit t Die Filter komplexit t wird prim r von der Anzahl der Vergleiche bestimmt vgl fl1 f21 f52 Innerhalb der gleichen Anzahl an Vergleichen kann man dann den Einflu der L nge eines Vergleichs auf den Durchsatz erkennen Der Grenzdurchsatz beim Filtern liegt bei 24468 Filter Auftr ge pro Sekunde Die in der Kurve TT data deutlich zu er kennenden Unterschiede in den Me werten f r 100 und 200 Wiederholungen ergeben sich aus der Me genauigkeit Es konnte auf 64us genau gemessen werden Bei 10 MBit pro Sekunde k nnen maximal 17361 Frames minimaler L nge inner halb einer Sekunde ber das Ethernet Segment versendet werden Dieses theoretische Maximum wird aufgrund von Kollisione
33. Abschnitt 1 3 eingegangen um schlie lich den Entwurf und die Realisierung eines Werkzeuges f r diesen Zweck zu motivieren In einem eigenen Abschnitt vgl 1 4 werden die verschiedenen Klassifikationen f r Werkzeuge der Kommunikationsme technik vorgestellt 1 1 Notwendigkeit f r die Analyse von Kommunikations systemen Mit Analyse ist im allgemeinen eine zielgerichtete aktiv empirische Untersuchung ge meint Der Zweck einer Analyse ist die Gewinnung nicht offensichtlicher Informationen ber ein System bzw Teilsystem Neben der Interpretation der Analyseergebnisse ist die Gewinnung von Informationen durch eine Analyse die wichtigste Grundlage f r die Bewertung eines Systems Im folgenden wird speziell auf Kommunikationssysteme als Ganzes eventuell sogar als Subsystem eines noch gr eren Systems oder auf Teile ei nes Kommunikationssystems wie beispielsweise Vermittlungsrechner Leitungen oder Protokolle eingegangen Kommunikationssysteme werden in der Regel als Subsysteme entworfen und be trieben Als Teil eines gr eren Systems beispielsweise eines Verteilten Systems werden eine Vielzahl an Benutzer Anforderungen an das Kommunikationssystem gestellt Dies sind insbesondere e Verf gbarkeit Ein System mu grunds tzlich verf gbar sein um berhaupt einen Nutzen erbringen zu k nnen Bei einer Analyse soll in der Regel fest 10 KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 11 gestellt werden wie das ze
34. Bitfehlerh ufigkeit engl BER Bit Error Rate fehlerhafte Bit BER 2 2 Gesamtzahl bertragener Bit a e bertragungsgeschwindigkeit Bit s Eine hohe bzw f r die gew hlte Leitung hohe Bitfehlerh ufigkeit kann obige ana loge Messungen nach sich ziehen da Bitfehler entstehen wenn Me werte bei den analogen Messungen von der Spezifikation abweichen 2 1 2 Schicht 2 Datensicherungsschicht Hauptaufgabe der Sicherungsschicht ist die Bitfehler der Schicht 1 zu erkennen und gegebenenfalls zu korrigieren Dazu wird der Bitstrom der Schicht 1 als sequenziell bertragene Bl cke interpretiert die einem bestimmten Format gen gen m ssen Das Format wird in einer Protokollspezifikation festgelegt Die Bitbl cke sind somit als Schicht 2 Protokolldateneinheiten PDUs interpretierbar In dieser Protokollschicht ist me bar bzw analysierbar e Anzahl fehlerhafter fehlerfreier PDUs seit Beginn der Messung e Anzahl fehlerhafter fehlerfreier PDUs pro Zeiteinheit e Verteilung der PDU Typen prozentualer oder ganzzahliger Anteil bestimmter PDUs an der Gesamtzahl aller PDUs e Pr fen der syntaktischen Korrektheit von PDUs e Aufschl sselung der PDUs gem ihrem PDU Format Anzeigen einzelner PDU Felder insbesondere der eingebetteten PDUs h herer Schichten e Angaben zur L ngenverteilung der PDUs vgl Sta93 S 500ff e Angabe der Auslastung des bertragungsmediums Utilization minimal ma x
35. Diese Werkzeuge werden Monitore genannt In der Informatik gibt es noch weitere Definitionen f r Monitor Teilweise werden die Bildschirme der Rechner als Monitore bezeichnet Im Zusammenhang mit Be triebssystemen versteht man unter einem Monitor eine Funktion die den Zugriff auf Betriebsmittel f r nebenl ufige Prozesse synchronisiert In dieser Arbeit wird der Begriff Monitor ausschlie lich als Bezeichnung f r ein Werkzeug zum Erfassen von Me daten benutzt ber den Funktionsumfang was ein Monitor alles k nnen mu gibt es unterschiedliche Meinungen Grundvoraussetzung f r einen Monitor ist die F higkeit zur Datenerfassung von Rohdaten Dar ber hinaus kann ein Monitor zus tzliche Funktionen beinhalten Dies sind Funktionen zum e Filtern der Daten e Analysieren der Daten 6Diese nderung sollte jedoch lokal am jeweiligen Arbeitsplatzrechner erfolgen Eine nderung mit Hilfe von TELNET w rde das Sicherheitsrisiko nicht beseitigen Rohdaten sind die vom Monitor unmittelbar am System erhobenen Me daten KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 17 e Bewerten der Daten e Anzeigen der Daten e Verwalten der Daten e aktivem Testen des Me objektes 1 3 2 1 Filtern von Daten Das Filtern der Daten ist erforderlich wenn der Monitor nur einen Teil der gemessenen Daten weiterverarbeiten soll oder aufgrund des Betriebsmittelbedarfs f r die Wei terverarbeitung der Daten nur einen Teil der
36. Eigenbau TIS Toolkit f r anwendungsorientierte Firewall Systeme IX Multiuser Multitasking Magazin 6 54 61 jun 1995 B W Kernighan and D M Ritchie Programmieren in C Hanser Prentice Hall M nchen Wien London 2 edition 1992 M Kuschke Teuflisch gut SATAN PD Tool zum Auffinden von Security L cken IX Multiuser Multitasking Magazin 6 54 61 jun 1995 H Lipp Entwurf und Realisierung eines Software Monitors f r lokale Rech nernetze zur Unterst tzung von Verkehrs und Leistungsanalysen Diplomar beit Universit t Hamburg Arbeitsbereich Rechnerorganisation 1988 LMB92 J R Levine T Mason and D Brown lex amp yacc UNIX Programming Tools O Reilly amp Associates Inc 2 edition 1992 S McMenamin and J Palmer Strukturierte Systemanalyse Hanser 1986 MSS93 M Mansouri Samani and M Sloman Monitoring Distributed Systems IEEE Network 7 6 20 30 1993 Mue94 J Mueller The Ultimate OS 2 Programmer s Manual McGraw Hill 1994 MWT94 J K Muppala W Wang and K S Trivedi Dependability Evaluation Through Measurement and Models In R Marie G Haring and G Kotsis editors 7th Int Conf on Modelling Techniques and Tools for Performance Evaluation Schriftenreihe der Osterr Computer Gesellschaft Band 73 1994 B Page Diskrete Simulation Eine Einf hrung mit Modula 2 Springer Verlag Berlin Heidelberg 1991 C Parris Using SNMP to Manage Guaranted Performance Connec
37. LAN und umgekehrt f r Sicherheits berpr fungen Accounting Geb hrenberechnung usw 2 1 4 Schicht 4 Transportschicht Zus tzlich zu den Messungen der Schicht 2 sind hier Messungen n tig die die Aufgaben der Transportschicht berpr fen e berpr fen von Flu kontrollmechanismen e berpr fen der Sequenzierung kommt es zu Reihenfolgevertauschungen von PDUs e berpr fen der Wahl eines Netzes bei mehreren alternativen Netzen Ist das gew hlte Netz in der Lage die vom Benutzer gew nschte Dienstg te zu erbringen g e Angaben zu Verbindungen Dauer Anzahl bertragener Byte Typ und zeitliche Anordnung der Nachrichten des Handshake 2 1 5 Schicht 5 7 Kommunikationssteuerungs Darstellungs und Anwendungsschicht Die Aufgaben der anwendungsnahen Protokolle sind speziell auf die Bed rfnisse der Anwendungen zugeschnitten Grunds tzlich sind hier hnliche Analysen wie f r die Schicht 2 m glich und eventuell berpr fungen von Verbindungsauf und Abbau sowie Angaben zur Verbindung wie bei der Schicht 4 KAPITEL 2 ANFORDERUNGEN AN EIN MESSWERKZEUG 30 2 1 6 Alternative Schichteneinteilung Die oben an dem OSI Schichtenmodell diskutierten Messungen k nnen bei Bedarf auch zusammengefa t werden So werden in F 87 beispielsweise Messungen zum Stations Durchsatz und zum Interface Durchsatz diskutiert Beim Stations Durchsatz wird der Durchsatz an Benutzerdaten an der Schnittstelle z
38. M glichkeit Die Auswahl der wich tigsten Kommandos ber ein Menn mit einer Maus ist eine weitere graphische Eingabem glichkeit Au erdem mu es Prozesse geben die Analysedaten bei Bedarf auf Massenspeicher auslagern Auch hier ist f r den sicheren Betrieb eine enge Koppelung an die Funktio nen des Betriebssystems notwendig Vor der Ausgabe ist sicherlich eine Umwandlung in ein Standardformat erforderlich um die Daten anderen Werkzeugen zug nglich zu machen vgl Abschnitt 2 5 Eine weitere Aufgabe die von einem Proze auf dem Host bernommen werden sollte ist das Konfigurieren der Transputer und Einladen der Transputer Prozesse in die Prozessoren Das sollte bei jedem Start des Prototypen automatisch geschehen Eine manuelle Konfigurierung durch den Benutzer ist weder komfortabel noch sinnvoll da hierf r neben der Kenntnis der Konfiguration auch der Umgang mit entsprechenden Konfigurierungswerkzeugen vom Benutzer erwartet wird Die Kenntnis der Konfigura tion ist jedoch f r die Verwendung des Prototypen nicht erforderlich Daher bietet sich das automatische Konfigurieren und die Kapselung der daf r notwendigen Funktionen in einem Proze an Derartige Multiple Choice Formulare kann man sich beispielsweise zur Auswahl der zu erfassen den Me werte durch den Benutzer vorstellen wie es bereits in den Anforderungen spezifiziert wurde vgl Abschnitt 2 7 4 KAPITEL A ENTWURF DES MESSWERKZEUGES 72 4 3 3 Entwurf der Grob
39. Protocol vgl RFC 1009 Internet Protocol vgl RFC 791 Internationale Standard Organisation Kilobyte Local Area Network Lokales Netz Logical Link Control Megabit Megabyte Me datenerfassungs und Analyseger t Megaherz Management Information Base Maximum Transmission Unit Network Byte Order Network Management System LITERATURVERZEICHNIS 187 Abk rzungen Fortsetzung 08 2 Ost OSIRM OSPF PC PD PDU PM RAM RARP RCS RFC RMON RO RZ SA SDU SNMP SW TB TCP TDR TELNET VB Operating System 2 Open System Interconnection OSI Reference Model Open Shortest Path First vgl RFC 1583 Personal Computer Public Domain Protocol Data Unit Dateneinheit Presentation Manager Random Access Memory Reverse Address Resolution Protocol vgl RFC 903 Revision Control System Request for Comments Remote Monitoring Rechnerorganisation Rechenzentrum Absender Sender Adresse Service Data Unit Simple Network Management Protocol Software Transputer Board Transmission Control Protocol vgl RFC 793 Time Domain Reflectometer Telnet Protocol vgl RFC 854 855 Vermittlungs bit
40. Protokollen statt Die Leistungsf higkeit ist unter hoher Last besonders gut Alle Prozesse k nnen durch einfaches Verteilen der eintreffenden Dateneinheiten ann hernd gleichm ig aus gelastet werden Damit bietet dieser Ansatz bei deutlich geringerem Realisierungsauf wand eine zu den Protokollfunktionen vergleichbare Leistungsf higkeit Der Ansatz der Protokollfunktionen w re nur bei niedriger Last sporadisch eintreffende Daten einheiten berlegen Ein weiterer Vorteil dieses Ansatzes ist da f r die Analyse auf unterschiedlichen Protokollschichten keine Kontextwechsel n tig sind da derselbe Proze alle Protokolle analysiert Die Analyseprozesse k nnen fast beliebig auf ein Prozessornetz plaziert werden Aus Ffiizienzgr nden wird man auch bei diesem Ansatz versuchen die Analyseprozesse zusammenh ngend auf Prozesse zu plazieren Die Prozessortopologie ist jedoch nicht wie bei Protokollfunktionen oder Schichtenpipeline festgelegt Vielmehr l t sich 19Es wird die Annahme unterstellt da man bei Protokollfunktionen und Protokollpipeline versucht eine isomorphe Zuordnung zu finden KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 66 dieser Ansatz auch auf v llig regul re Prozessornetze abbilden Ein weiterer Vorteil im Zusammenhang mit der Hardware ist da Erweiterungen der Analysefunktionalit t nicht notwendigerweise auch zu Hardware Erweiterungen f hren Au erdem ist dieser Ansatz unabh ngig von der Anzah
41. S 67 PSTAT leitet die Daten zum Hostrechner weiter Eine Warnung wird von PSTAT generiert falls der Nachrichtenringpuffer voll ist PSTAT kann aber nicht definitiv entscheiden ob das zum Verlust von Dateneinheiten f hrt Die Nachrichtenringpuffer der Pakettr ger k nnen beispielsweise kurzfristig Nachrichten zwischenspeichern Falls kein Proze weitere Nachrichten zwischenspeichern kann kommt es auf der Ethernet Schnittstelle zu Paketverlusten Dieser Paketverlust kann durch Anfordern der netznahen Statistiken erkannt werden 161 KAPITEL 7 LEISTUNGSBEWERTUNG DES PROTOTYPEN 162 7 1 1 Der prim re Engpa des Prototypen Der prim re Engpa des Prototypen ist die Schnittstelle zwischen Hostrechner und Transputerboard Das Datentor auf dem Transputerboard ist nur acht Bit breit obwohl die Transputer als auch der Prozessor des Hostrechners 32 Bit Prozessoren sind Die Umwandlung der Informationen aus dem seriellen bertragungsformat der Transputer vgl Abbildung 3 6 in ein acht Bit Wort des Hostrechners ist au erdem deutlich langsamer als die bertragungsgeschwindigkeit eines Transputerlinks Das hat folgende drei Konsequenzen 1 Es gibt einen deutlich geringeren Durchsatz in Byte zwischen Hostrechner und Transputer als zwischen zwei Transputern Das liegt an der zu langsamen Umwandlung der bit seriell bertragenen Informationen in acht Bit W rter und vice versa 2 Das
42. Stelle soll deshalb nur noch auf zwei offene Fragen eingegangen werden 8 3 1 Die Schnittstelle f r Messungen in Hochgeschwindigkeitsnet zen Es gibt viele neue Zugriffsverfahren im Bereich der Hochgeschwindigkeitsnetze Einige dieser Zugriffsverfahren erschweren die Rohdatenerfassung durch Me werkzeuge erheb lich Ein in diesem Zusammenhang unproblematisches HSN ist FDDI vgl Abschnitt 8 3 1 1 Der problematische Fall kann am Beispiel von ATM diskutiert werden 8 3 1 1 Me datenerfassung in einem FDDI Netz Die Stationen werden in einem FDDI Netz ringf rmig angeordnet vgl BHK9Y4 S 343ff F r die Me datenerfassung entscheidend ist da alle Dateneinheiten den physikalischen Ring vollst ndig umrunden bevor die sendende Station ihre eigenen Dateneinheiten wieder vom Netz entfernt Ein Me werkzeug kann daher unabh ngig von der Position im Ring den gesamten Verkehr beobachten Es k nnen insbesondere Verkehrsmatrixen erstellt werden Ein weltweiter Informations Austauschdienst 6Namentlich Herr Gerrit M ller KAPITEL 8 ZUSAMMENFASSUNG UND AUSBLICK 179 B g Station B Station A FDDI Ring A Monitor U Station C Abbildung 8 1 FDDI LAN 8 3 1 2 Me datenerfassung in einem ATM Netz Asynchronous Transfer Mode ATM bedeutet da ununterbrochen Dateneinheiten unabh ngig von Benutzerdaten in einem ATM Netz versendet werden Fal
43. Transputerboard ist nicht eingesetzt oder f r einen anderen 1 O Bereich konfiguriert Dieser Fehler tritt auf falls die Transputerboards TBs nicht richtig im Hostrechner eingesetzt wurden oder ber die Steckleisten ein ande rer 1 O Bereich f r die Adressen der TBs gew hlt wurde Die zu verwendende Startadresse f r das Parsytec Board vgl Abbildung 3 7 ist 15016 F r das INMOS Board vgl Abbildung 3 8 ist die Startadresse 30016 zu w hlen 2 Eine falsche Konfigurationsdatei wurde beim Konfigurieren der Transputer Pro zesse verwendet Es mu berpr ft werden ob in den Programmauellen der richtige Dateiname eingetragen wurde 3 Eine falsche Programmdatei mit den Transputerprozessen wurde angegeben Auch hier ist die Angabe in den Programmquellen der Ladefunktion vgl Abschnitt 5 3 4 6 zu berpr fen 4 Der Timeout Wert f r den Ladevorgang wurde zu klein gew hlt vgl Abschnitt 5 3 4 6 Dieser Wert kann in den Programmaquellen versuchsweise erh ht werden 6 2 Vorgehensweise zur Durchf hrung eines Me experi ments Allgemein sind folgende Schritte f r die Durchf hrung eines Me experiments notwen dig Die Funktionalit t entspricht dem Standardausgabe Fenster 30 2 stellt f r Situationen wie diese wo der Benutzer in jedem Fall eine Meldung quittieren sollte sogenannte system modale Dialoge zur Verf gung Neben dem Anzeigen der Fehler Meldung und auff lliger Ach
44. auf Quelle oder Senke der Da ten bertragung im Speicher zugreifen kann Die Verbindung zweier Transputer ber Links ist symmetrisch in dem Sinn da der Ausgang eines Links an den Eingang eines anderen gef hrt wird und umgekehrt Die Brutto Datenrate f r die Linkgeschwin digkeit ist einstellbar Sie kann zwischen 5Mbit s 10Mbit s und 20Mbit s gew hlt werden ber die Links wird sequentiell kommuniziert Ein zu versendendes Byte wird mit zwei Startbits und einem Stopbit versehen Jedes dieser 11bit langen Pakete wird vom Empf nger best tigt Diese Best tigung ist bei den Transputern T800 im Arbeitsbereich Rechnerorga nisation der Universit t Hamburg RO berlappend Ein Paket wird schon nach den ersten 6 Bit best tigt so da die Sendeseite die Best tigung empf ngt wenn das letzte Bit versendet wurde Es treten also keine Sendeverz gerungen f r aufeinanderfolgende Pakete auf Damit ergibt sich die theoretische Obergrenze f r die Netto Datenrate also die Nutzinformationen ohne Start und Stopbits zu U 1175 1024 1775 568Kbyte s f r die unidirektionale Kommunikation F r die bidirektionale Kom munikation kann dieser Wert leider nicht verdoppelt werden da sich hier die Pakete KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 49 Stopbit
45. gegeben In Abschnitt 3 3 3 werden schlie lich die verschiedenen Ans tze zur parallelen Pro tokollverarbeitung vorgestellt und in Abschnitt 3 3 4 f r einen Einsatz in der parallelen Protokollanalyse bewertet 3 3 1 Bewertungskriterien Die Grundlage f r die Bewertung der Konzepte in den folgenden Abschnitten sind e Realisierbarkeit der funktionalen Anforderungen Die allgemeinen An forderungen an ein Werkzeug wurden in Abschnitt 2 diskutiert die speziell zu erf llenden Anforderungen in Abschnitt 2 7 Das gew hlte Konzept mu grunds tzlich die Implementierung der erforderlichen Funktionen zulassen Ne ben dieser allgemeinen Eignung mu weiterhin beachtet werden mit welchem Aufwand die Realisierung verbunden ist Der Aufwand ist im Vergleich mit al ternativen Konzepten abzusch tzen Ein m gliches Ma f r diesen relativen Aufwand w re die Summe der zus tzlichen Unterst tzungsfunktionen da sich Realisierungen unterschiedlicher Konzepte ge rade in diesen Unterst tzungsfunktionen unterscheiden Unterst tzungsfunktio nen erbringen Dienste f r die Funktionen die die eigentlichen Benutzer An forderungen realisieren Dies sind beispielsweise Funktionen f r die Inter und Intraproze kommunikation und Funktionen f r Warteschlangen mit bestimmten Bedienstrategien usw Erweiterbarkeit Der Aufwand bei Erweiterungen ist ein weiteres Kriterium f r die Wahl eines Konzeptes Beispielsweise k nnte man den Aufwand bewer ten
46. gemessenen Daten weiterverarbeiten kann Da der Betriebsmittelbedarf f r Monitore in der Regel sehr hoch ist sollte das Filtern der Rohdaten m glichst unmittelbar nach der Erfassung erfolgen 1 3 2 2 Analysieren der Daten Unter Analysieren ist in diesem Zusammenhang das zielgerichtete Auswerten der Roh daten zu verstehen Das k nnen statistische Berechnungen sein Klassifizierung der Me daten etc 1 3 2 3 Bewerten der Daten Beim Bewerten der Daten werden Analyseergebnisse vom Monitor interpretiert Einige Werkzeuge zur Fehlersuche bieten sogar die Funktionalit t von Expertensystemen Durch Einsatz von KI Techniken versucht der Monitor nach dem Analysieren der Me daten R ckschl sse auf die Fehlerursache zu ziehen Nicht in jedem Fall sind f r eine maschinelle Bewertung von Analyseergebnissen KI Techniken erforderlich Oft ergeben sich Bewertungsm glichkeiten direkt aus den Analyseergebnissen 1 3 2 4 Anzeigen der Daten Das Anzeigen der Daten erm glicht dem Analysierenden den Einblick in die Me er gebnisse Grunds tzlich kann man zwischen der tabellarischen und der graphischen Aufbereitung unterscheiden Bei der tabellarischen Aufbereitung werden die analysierten Me daten formatiert dargestellt Diese Art der Darstellung eignet sich besonders f r Protokollanalysatoren s u Die graphische Aufbereitung ist besonders f r gro e Datenmengen unerl lich Durch Histogramme und andere Diagrammformen k nnen die Analyseergebn
47. ger Proze T800 T800 P5 Rohdatenerfassung T800 Zwischenspeicher P6 Rohdatenerfassung T225 Kontrolle ber Ethernet Schnittstelle Abbildung 4 1 6 Prozessor Konfiguration 4 4 Entwurf der essentiellen Funktionen Die im letzten Abschnitt vorgestellte Grobeinteilung kann weiter verfeinert werden Durch die Festlegung der Hardware Anzahl der Prozessoren und deren Verbindungen untereinander konnte eine erste Grobgliederung in Abbildung 4 1 vorgestellt werden Die Plazierung der Prozesse aus Abschnitt 4 3 2 1 4 3 2 4 wurde entsprechend ihrer jeweiligen Hauptaufgabe vorgenommen und im letzten Abschnitt 4 3 3 begr ndet Die Hauptaufgabe der Prozesse durch Namen wie Pakettr ger globale Sta tistik verdeutlicht wird von Funktionen realisiert Diese Funktionen sind somit essentiell f r den jeweiligen Proze und f r den Prototyp als paralleles Programm In den folgenden Abschnitten werden diese essentiellen Funktionen der einzelnen Pro zesse entworfen 4 4 1 Entwurf der essentiellen Funktionen f r die Rohdatenerfassung Die essentiellen Funktionen f r die Rohdatenerfassung teilen sich auf zwei Prozesse auf Einerseits ben tigt man einen Proze zur physikalischen Ansteuerung und Kontrolle der Ethernet Schnittstelle Andererseits ben tigt man einen Proze f r das Zwischen speichern der erfa ten Daten vor der Weitergabe an die Pakettr ger Die essentiellen KAPITEL 4 ENTWURF DES MESSWERKZEU
48. handelt es sich zwar immer noch um Parallelverarbeitung da noch andere Prozesse nebenl ufig zum Pakettr ger proze ablaufen jedoch nicht mehr um Paketparallelit t im engeren Sinne Die eigentliche Analyse oder auch Protokollverarbeitung w re dann sequentiell KAPITEL A ENTWURF DES MESSWERKZEUGES 80 4 4 4 1 Essentielle Funktionen f r die Interaktion mit dem Benutzer Die Steuerung des Prototypen wird vom Benutzer bernommen Dazu mu der Benut zer Aktionen im Me werkzeug ausl sen k nnen Bei der Verwendung einer graphischen Benutzeroberfl che gibt es prinzipiell die beiden folgenden M glichkeiten e Der Benutzer kann Aktionen ber Kommandos ausl sen die ber eine Kom mandozeile eingegeben werden Der Benutzer tippt dazu ber die Tastatur die entsprechenden Kommandos ein e Der Benutzer kann Aktionen durch Auswahl graphischer Symbole mit der Maus ausl sen In Abschnitt 4 3 2 4 wurde bereits dargestellt da beide Eingabem glichkeiten Vor teile haben Es sollen daher Funktionen f r eine Kommandozeile und Funktionen zur Eingabe ber Dialoge und Men s realisiert werden Die Kommandozeile mu e Eingaben ber die Tastatur darstellen e komfortable Editierfunktionen bieten Einf gen L schen Verschieben und ber schreiben von Zeichen ketten und e die der Eingabe entsprechenden Aktionen ausl sen k nnen Die Dialoge und Men s sollten in ihrer Erscheinung den unter OS 2 blic
49. im IP Kopf wird zur Identifizierung von ICMP Dateneinheiten auf den Wert KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 118 000116 gesetzt TYP CODE Pr fsumme abh ngig von TYP und CODE Abbildung 5 13 ICMP Dateneinheit Die Hauptaufgabe bei der Analyse einer ICOMP Dateneinheit besteht darin die vielf ltigen Kombinationsm glichkeiten aus TYP und CODE in eine Klartextmel dung umzuwandeln Diese Meldung ist der wesentliche Teil bei der Protokollierung von ICMP Dateneinheiten vgl Com91 S 127 136 RFC 792 S 4 18 Au erdem wird die L nge der Dateneinheit bestimmt 5 3 2 6 Realisierung der Analysefunktion f r das User Datagram Proto col Das User Datagram Protocol UDP erweitert das Internet Protocol IP im we sentlichen um die Angabe eines Quell Ports und eines Senken Ports Wird hier eine gem RFC 1700 standardisierte Nummer eingetragen kann der Empf nger hiermit die Anwendung identifizieren die die Daten versendet hat bzw f r welche Anwendung die Daten bestimmt sind Die Struktur von UDP Dateneinheiten ist entsprechend simpel vgl Abbildung 5 14 Quell Port Senken Port L nge Pr fsumme Abbildung 5 14 UDP Dateneinheit Die Analysefunktion f r UDP Dateneinheiten mu neben den blichen Berech nungen zur L nge nur mit Hilfe einer Tabelle das eingebettete Protokoll anhand der Portnummern identifizieren Danach k nnt
50. ist demnach ein deutlich gr erer Zwischenspeicher m glich Der Proze f r die globale Statistik wird auf P2 plaziert Das ist sinnvoll da ber diesen Prozessor ohnehin alle Ergebnisse zum PC weitervermittelt werden Eine Plazierung dieses Prozesses auf einen anderen Prozessor als P2 w rde mehr Overhead f r die Berechnung und Vermittlung der globalen Statistiken bedeuten Die Zuordnung der Pakettr ger Prozesse ist relativ frei Sie m ssen logisch zwi schen der Rohdatenerfassung einerseits und dem Proze f r die globale Statistik ande rerseits liegen Man k nnte also jeweils einen Pakettr ger Proze auf P2 P5 plazieren Gegen P2 k nnte sprechen da es von der Rohdatenerfassung keine direkte Verbin dung zu diesem Pakettr ger geben w rde Gegen P5 k nnte sprechen da dieser Prozessor schon durch die Rohdatenerfassung ausgelastet ist In jedem Fall wird man jedoch auf P3 und P4 einen Pakettr ger plazieren Die graphische Darstellung der Konfiguration mit sechs Prozessoren ist in Abbil dung 4 1 gegeben Formal betrachtet handelt es sich bei der Plazierung der Prozesse um eine qualitative zusammenh ngende kontraktive vollst ndige und konservative Zuordnung vgl Abschnitt 3 1 2 die wie oben dargestellt manuell erfolgt KAPITEL A ENTWURF DES MESSWERKZEUGES 73 j P1 Hostrechner Prozesse 1586 globale Statistik P2 T800 Pakettr ger Proze P3 P4 Pakettr
51. llt auf da auch hier die Namensgebung uneinheitlich ist vgl Protokollanalyse vs Netzanalyse bei GK94 s 0 bzw Protokoll Monitor als Subtyp von Netzmonitor bei W0193 s 0 1 4 2 Klassifikation nach der Architektur Die Unterscheidung von Monitoren nach der Art ihrer Realisierung bzw Implemen tierung ist die am weitesten verbreitete Klassifikation Es kann grunds tzlich unter schieden werden zwischen e Hardware Monitor e Software Monitor e Firmware Monitor und e Hybrid Monitor Obwohl der Trend bei neueren Monitoren zu einer hybriden Realisierung geht ist diese Klassifizierung weiterhin breit akzeptiert vgl z B Hin86 Jai91 Thu93 Dies liegt vor allem daran da in der Anfangszeit der Monitortechnik man fast jeden Monitor genau einer von zwei Klassen zuordnen konnte Er war entweder ein Hardware oder ein Software Monitor vgl Hin86 S 4 KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 21 1 4 2 1 Hardware Monitor Ein Hardware Monitor ist ein Me ger t das an das Me objekt mit Hilfe von Me f h lern angeschlossen wird Ver nderungen des Me objektes werden durch die Me f hler registriert Die Me ergebnisse k nnen durch logische Schaltungen weiterverarbeitet werden Einige Hardware Monitore unterst tzen auch das Speichern der Daten auf eigenen Massenspeichern vgl Lip88 S 31 Hin86 S 4ff Jai91 S 98 Wesentliches Merkmal der Hardware Monitore ist da sie
52. r die Analyse 4 4 3 Entwurf der essentiellen Funktionen f r die globale Statistik 4 4 4 Entwurf der essentiellen Funktionen f r den Hostrechner 4 4 5 Entwurf essentieller Funktionen zum Filtern 4 5 Entwurf der unterst tzenden Funktionen o 2 22 2 2 4 5 1 Entwurf von Vermittlungsfunktionen und Verteilungsfunktionen 4 5 2 Entwurf von Verbindungsmanagement Funktionen 4 5 3 Entwurf der Kommunikationsunterst tzung f r die Hostrech ner Transputer Kommunikation 4 6 Sonstige unterst tzende Funktionen 2 2 2 nnnnnen 4 6 1 Funktionen zur Ringpuffer Verwaltung 2 2 2 4 6 2 Funktionen zur Symboltabellen Verwaltung 4 6 3 Funktionen zum Umwandeln von Daten 2 2 2 2 4 7 Klassifikation der Funktionen 35 35 37 37 38 38 41 42 44 44 53 55 55 56 57 61 67 67 68 69 69 69 72 73 73 74 79 79 82 84 84 87 INHALTSVERZEICHNIS 5 Realisierung des Me werkzeuges 5 1 5 2 5 3 5 4 5 5 5 6 5 7 Zusammenstellen der Funktionen zu Prozessen e 5 1 1 Prozesse und Threads auf Transputern 5 1 2 Darstellen der Prozesse mit Datenflu diagrammen 5 1 3 Die Prozesse des Transputernetzes als Datenflu diagramm Verfeinerung der Prozesse 2 2 2 onen 5 2 1 Ein allgemeines Proze Template 2 22 2222 5 2 2 Der Proze zur Rohdatenerfassung 5 2 3 Der Proze PDEV 1 2 4 22 K
53. ren ist die M glichkeit durch replizieren dieser Prozesse an verschiedenen Stellen im Netz Rohdaten verteilt erfassen zu k nnen Man h tte so mehrere Rohdatenerfas sungsmodule wie beispielsweise in K 95 S 56 dargestellt Auch eine Anpassung an andere Netze f llt bei einer Kapselung der hardwarenahen Funktionen in einen eigenen Proze leichter Die Ansteuerung der netz spezifischen Schnittstellen kann prozess lokal erfolgen um anderen Funktionen eine einheitliche Schnittstelle an die Datenerfassung anzubieten Man erh lt so einen Netz Server Proze 4 3 2 2 Prozesse zur Analyse Durch die Wahl der Paketparallelit t als Paradigma f r die parallele Protokollanalyse ergibt sich da mindestens zwei Prozesse die erfa ten Rohdaten parallel auswerten sollten Die Funktionalit t der Pakettr ger mu identisch sein damit jedes erfa te Rohdatum von einem beliebigen Pakettr ger ausgewertet werden kann Nur wenn die Pakettr ger ber die gleiche Funktionalit t verf gen kann man die Entscheidung dar ber von welchem Pakettr ger eine Dateneinheit ausgewertet werden soll unabh ngig vom Inhalt der Dateneinheit treffen Wollte man teilweise speziali sierte Pakettr ger realisieren m te ein Teil der Analyse au erhalb der Pakettr ger erfolgen um entscheiden zu k nnen welche r Pakettr ger f r die Analyse geeignet sind ist Bei dem Prototypen sollen alle Pakettr ger ber die gleiche Funktio
54. sind umfangreiche Analysen der Me werte m glich da die Funktionalit t des Me objektes f r diese Analysen meist vollst ndig zur Verf gung steht e Es sind applikationsnahe Messungen m glich SW Monitore lassen sich subklassifizieren nach der Art wie Ver nderungen des Me objektes registriert werden Die Aufnahme von Me daten durch den Monitor kann vom Me objekt durch folgende drei M glichkeiten veranla t werden vgl Jai91 S 96 11 Mit Me objekt ist das zu vermessene System gemeint KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 22 e Ausf hren bestimmter Maschinenbefehle e Ausf hren des Einzelschrittmodus Der Prozessor des Me objektes oder der Hardware auf dem Monitor und Me objekt ablaufen springt nach Ausf hrung jedes einzelnen Maschinenbefehls in den Programmcode des Monitors Der Einzelschrittmodus mu vom jeweiligen Prozessor unterst tzt werden e Unterbrechungen durch den Zeitgeber Verf gt das Me objekt ber einen Zeitge ber dann kann der Monitor durch eine vom Zeitgeber ausgel ste Unterbrechung zur Aufnahme von Me daten veranla t werden Diese Subklassifikation ist au erdem eine Verfeinerung der Klassifikation nach dem Me verfahren s u 1 4 2 3 Vergleich von Hardware und Software Monitoren Die Vorteile bzw Nachteile von HW und SW Monitore ergeben sich im direkten Vergleich beider Typen miteinander Neben den oben genannten Hauptnachteilen beider Typen haben die SW
55. standard Filtern Namensgebung Spei chern Laden Zus tzlich zu den Filtern sollten universelle Me ger te auch sogenannte Trigger Mechanismen bieten hnlich den Filtern arbeiten auch die Trigger auf den Me daten Der Unterschied zu den Filtern besteht darin da Trigger keine Reduktion der Daten vornehmen sondern abh ngig von den erhobenen Daten benutzerdefinierte KAPITEL 2 ANFORDERUNGEN AN EIN MESSWERKZEUG 31 Aktionen ausl sen Durch Trigger l t sich das Verhalten des Me ger tes program mieren Beispielsweise k nnte ein Trigger das Erfassen von Me daten ab einer be stimmten Uhrzeit veranlassen Ein weiterer Trigger beendet die Me datenerfassung beispielsweise nach dem Eintreffen einer bestimmten Anzahl an Ethernet Frames 2 3 Anforderungen an das Bewerten der Daten Trigger lassen sich au erdem f r das Bewerten der Daten durch den Benutzer ein setzen Unabh ngig vom Benutzer k nnen Bewertungen durch ein Expertensystem erfolgen Die Bewertungsm glichkeiten ergeben sich durch e Einsetzen der Trigger Mechanismen f r benutzerdefinierte Fehler und Ereignis meldungen und einer e Schnittstelle zu Expertensystemen Ein Trigger k nnte beispielsweise das Eintreffen von ICMP Nachrichten des Typs ECHO Request erkennen und die Meldung Netzmanagement von Station XYZ aus geben Dabei wird XYZ durch die jeweilige Senderadresse ersetzt Die Programmierung derartige
56. t der Leitung und der bertragenen Signale sind gebr uchlich vgl auch Abbildung 2 1 26 KAPITEL 2 ANFORDERUNGEN AN EIN MESSWERKZEUG 27 e Impedanzen e Frequenzgang Ger usche Jitter d e Spannungsversatz Bias a Gleichspannungsanteil b Wechselspannungsanteil Flankensteilheit e Frequenz f Amplitude c e Geschwindigkeit des Signals Volti Abbildung 2 1 Me gr en der physikalischen Schicht Die gemessenen Werte k nnen zusammen mit statischen Angaben ber das Netz be nutzt werden um zu berpr fen ob sich die Leitung gem einer bestimmten Spezifi kation verh lt Durch Analyse der Werte k nnen weitere Aussagen getroffen werden beispielsweise ob es einen Kabelbruch an einer Stelle im Kabel gibt In Formel 2 1 gibt dis einen N herungswert f r die Entfernung eines m glichen Kabelbruches in Me tern an P ist die Ausbreitungsgeschwindigkeit des Signals im Kabel TDR Time Domain Reflectometer gibt den Z hlwert seit dem Beginn einer bertragung bis zum Erkennen einer Kollision an Der Wert wird mit der Bitrate des Mediums erh ht Bei Ethernet sind das 10MHz 10M Hz x 1bit 10 Mbit s KAPITEL 2 ANFORDERUNGEN AN EIN MESSWERKZEUG 28 Der Faktor von 0 5 ist n tig da sich das Signal zum Kabelbruch hin ausbreiten mu und die Reflektion zur ck zum Me ger t kommen mu 1 dis 5 P TDR 0 1x10 2 1 Digitale Messungen der Schicht 1 beziehen sich meist auf die e
57. vgl Tic85 verwendet das neben der Kommentierung einer nderung f r eine kompakte Speicherung der Quellen sorgt Ein weiterer Vorteil durch die Verwendung der Versionskontrolle ist da zu einer beliebigen Version zur ckgekehrt werden kann Dadurch sind nicht nur Erweiterun gen m glich sondern auch alternative Realisierungen bereits vorhandener Funktionen auf Grundlage einer beliebigen Version Bei Gruppenarbeiten verhindert das Ver sionskontrollsystem VKS dar ber hinaus da mehrere Programmierer gleichzeitig nderungen an demselben Modul vornehmen Der folgende Text ist eine Auszug der Kommentare zu einem Modul Ablaufsteue rung des Prozesses PPAKET Das VKS tr gt zu jeder Version das Erstellungsda tum und die Uhrzeit sowie den Namen des Programmierers ein der die nderung an den Programmquellen vorgenommen hat Zus tzlich kann der Programmierer einen Kommentar zu jeder Version eingeben der die Anderungen an dem jeweiligen Modul dokumentieren sollte RCS file RCS ppaket c v Working file ppaket c head 2 7 branch locks strict benecke 2 7 access list symbolic names keyword substitution kv total revisions 21 selected revisions 21 description Erstellt von Carsten Benecke im Rahmen seiner Diplomarbeit revision 2 7 locked by benecke date 1996 01 26 15 46 21 author benecke state Exp lines 66 6 Messunterstuetzung fuer interne Auswertung C B revision 2 5 date 1995 12 08 1
58. w ren beispielsweise die L nge und die Pr fsumme Neben diesen reinen Systemmessungen kann man auch Lastmessungen an einem System durchf hren Dazu untersucht man beispielsweise die verschiedenen Auftr ge und die Zwischenankunftszeiten mit denen diese Auftr ge an das System abgegeben werden Auftr ge k nnten in diesem Fall Ethernet Frames sein die an das Netz zur bertragung abgegeben werden Alle Dateneinheiten die in einem bestimmten Zeitintervall an das System abgegeben werden bilden die Last vgl WK90 Eine dritte M glichkeit sind Leistungsmessungen Dazu werden mit Hilfe von Last generatoren Auftr ge oder Auftragsklassen an das System bergeben und beobachtet wie sich das System unter dieser Last verh lt Eine Besonderheit ergibt sich bei Messungen an Ethernet basierten Kommunikati onssystemen Durch die oben besprochenen Filter kann man die Schnittstelle derart einschr nken da nur noch ein Teil des Kommunikationssystems ein Subsystem be trachtet wird Beispielsweise k nnte man anstelle aller Auftr ge die an das Netz abgegeben werden nur noch die Auftr ge messen die von einem bestimmten Knoten an das Netz abgegeben werden Au erdem kann man aufgrund der hierarchischen Strukturierung der Dienste in einem Kommunikationssystem unter Nutzung einer Hierarchie von Protokollen jede Protokollschicht als Schnittstelle f r eine bestimmte Klasse von Auftr gen ansehen Diese Schnittstellen sind durch die Protoko
59. wurden um die Hardware anzusteuern oder die Analyse nach dem Paradigma der Paketpar allelit t zu erm glichen Funktionen die keiner dieser beiden Kategorien angeh ren 4Die Network Byte Order legt fest in welcher Reihenfolge die Byte eines Wortes bertragen werden Eine Festlegung ist notwendig da nicht alle Prozessoren die Byte eines Wortes in der gleichen Reihenfolge ablegen 5 Bei beiden Prozessoren handelt es sich um sogenannte Little Endian Maschinen die das nieder wertigste Byte eines Wortes an der Speicherstelle mit der kleinsten Adresse ablegen Das h chstwertigste Byte eines Wortes wird zuerst bertragen Das entspricht dem Big Endian Format KAPITEL 4 ENTWURF DES MESSWERKZEUGES 92 wurden entworfen um direkt den Anforderungen zu gen gen Bei der folgenden Klas sifikation vgl Tabelle 4 1 ist zu beachten da die Zugeh rigkeit zu einer Kategorie den wesentlichen Aspekt einer Funktion kennzeichnet Damit ist nicht ausgeschlossen da eine Funktion auch unter einer anderen Kategorie eingeordnet werden k nnte Einige Funktionen des Me werkzeuges essentielle Funktionen unterst tzende Funktionen Benutzeran Deklaration von Filtern Umwandlungsfunktionen forderungen Filterfunktionen Statistikfunktionen Fkt zum Verschriftl Exportfilter Paketparallelit t globale Statistikfkt Verteilungsfunktionen Verbindungsmana gementfunktionen Hardware Ger tetreiber Ethernet Vermittlungs
60. zur Nachrichtenvermittlung gibt es nur noch einen weiteren Thread Er bernimmt sowohl die Kontrollfunktionalit t als auch die Analyse der Dateneinheiten Thread f r Analyse und Ablaufkoordinierung Die Ablaufkoordinierung bearbeitet alle Nachrichten die von anderen Prozessen an den Pakettr ger gesendet werden Da die Dateneinheiten als Nachrichten verpackt vom Proze PDEV beim Pakettr ger eintreffen veranla t die Ablaufkoordinierung auch die Analyse der Dateneinheiten Ein eigenst ndiger Analyse Thread h tte nur sehr geringe Vorteile Ein Beispiel w re die schnellere Reaktion auf Nachrichten die keine Dateneinheiten transportieren Kontrollnachrichten W hrend der Analyse Thread noch besch ftigt ist k nnte die Ablaufkoordinierung den Ringpuffer vorausschauend nach Kontrollnachrichten durchsuchen KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 102 Neben dem Auswerten der eintreffenden Dateneinheiten veranla t die Ablaufkoor dinierung das Versenden der lokalen Statistiken an die globale Statistik s u PSTAT als Reaktion auf die von PDEV versendete TIMER Nachricht s o PDEV Eine weitere wichtige Nachricht wird vom Hostrechner an die Pakettr ger gesendet Im mer wenn der Benutzer eine Auswahl der zu analysierenden Protokolle trifft mu die Wahl den Pakettr gern mitgeteilt werden Die meisten Nachrichten beinhalten jedoch Dateneinheiten die vom Pakettr ge
61. 2 2 on none 41 Bl ckschaltbild 24 2 zawer 28 84er 3 mer mr De 45 Zust ndsdiagramm ue mm aan en 46 Zeitgeber eege Te ae Ben ER en RA E ad 48 Link Pr t k ll 22 23 nr ee nn a ma 49 MTM BC Haard 2 a war 2808 a er EEN AE 50 INMOS kompatibles Board 2 22 2 2 nn 51 Hardware Architektur oaoa 53 Strukturelle Parallelit t e 58 Protokollpipeline 59 Sende Empfangspipeline 59 Protokollfunktionen 60 Verbindungsparallelit t 2 22 Coon 61 Paketparallelit t 2 2 Coon on 62 6 Prozessor Konfiguration 73 Direkte und indirekte Messung 76 Erkennungsbaum f r Protokolle 2 22 2 nn none 77 Deadlock beim Nachrichtenaustausch 86 Zugriff einer OS 2 Anwendung auf Ger te 89 Symbole der Datenflu diagramme 2 2 nn rn 95 Datenflu diagramm der Transputerprozesse 2 22 96 Datenflu diagramm des Proze Templates 97 Datenflu diagramm des Netz Servers e 98 Datenflu diagramm von PDEV e 101 Datenflu diagramm von PPAKET e 102 Datenflu diagramm von PSTAT 2 nn nn nenn 103 Ger tetreiber als Clients und Berger 106 Template einer Analysefunktion 109 Ethernet und IEEE 802 3 Frame 2 2 2 none 111 ABBILDUNGSVERZEICHNIS 8 5 11 5 12 5 13 5 14 5 15 5 16 5 17 5 18 5 19 5 20 5 21 5 22 5 23 5 24 6 1 6 2 6 3 6 4 6 5 6 6 6 7 6 8 6 9 6 10 6 11 7 1 72 7 3 7 4 7 5 7 6 T T 7 8 8 1
62. 3 4 1 Realisierung von Benutzereingaben Benutzer k nnen Anweisungen ber eine Kommandozeile eingeben oder ber Men s der Programmfenster mit Hilfe der Maus auf der graphischen Benutzerschnittstelle Eingaben ber eine Kommandozeile sind f r den ge bten Benutzer h ufig schneller und effizienter zu machen als ber eine eventuell mehrstufige Men hierarchie KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 122 Die Eingabe ber Men s und Dialogfelder der graphischen Benutzerschnittstelle bietet sich in F llen an in denen aus einer Vielzahl von vorgegebenen Wahlm glichkei ten selektiert werden mu Dies ist beispielsweise der Fall wenn der Benutzer angeben soll welche Me daten zu erheben sind Kommandozeile ber die Kommandozeile k nnen ber Schl sselw rter Kommandos eingegeben kor rigiert und ver ndert werden Dazu ist es notwendig die Schl sselw rter als sol che zu erkennen und die Einhaltung syntaktischer Regeln bei der Kombination der Schl sselw rter mit anderen Symbolen zu berpr fen Schl sselw rter und andere Symbole werden aus dem Zeichenstrom durch einen Scanner erkannt Die reservierten Schl sselw rter und Regeln wie die anderen zu erkennenden Symbole aufgebaut sein m ssen wurden mit Hilfe eines Lex Skriptes definiert Das unter Abschnitt 3 2 2 1 erw hnte Werkzeug Lex generierte daraus den Quellcode einer Funktion die Schl sselw rter in Zeichenketten erkennt Ei
63. 3 58 45 author benecke state Exp lines 9 3 Aenderungen an RESET Bearbeitung revision 2 4 date 1995 11 22 09 19 17 author benecke state Exp lines 132 99 Endversion 3tp 4tp revision 2 3 date 1995 11 20 12 44 13 author benecke state Exp lines 23 8 Erste lauffaehige Version ohne dynamischen Nachrichtenspeicher C B revision 2 0 date 1995 11 16 10 46 26 author benecke state Exp lines 255 272 branches 2 0 1 Schnelle Ringpuffer anstatt dynamischen Speicher fuer Nachrichten KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 142 revision 1 10 date 1995 11 06 13 11 39 author benecke state Exp lines 29 20 Benutzerauswahl 2 Filter wird beachtet revision 1 9 date 1995 11 06 11 09 44 author benecke state Exp lines 14 2 Vor Einbau des Filters 2 Stufe revision 1 8 date 1995 10 26 15 59 56 author benecke state Exp lines 376 376 Erweitert um Analysefunktion fuer ICMP Nachrichten C B revision 1 7 date 1995 09 27 21 33 47 author benecke state Exp lines 73 9 Erweiterungen fuer IP revision 1 5 date 1995 09 15 19 15 15 author benecke state Exp lines 104 5 ARP Protokollanalyse eingebaut ARP RARP C B revision 1 4 date 1995 09 13 19 11 32 author benecke state Exp lines 17 9 Fehler in Funktion eth_analyse behoben C B revision 1 3 date 1995 09 11 16 12 33 author benecke state Exp lines 9 5 ac_sym c bei vorheriger Version 1 2 un
64. 8 2 8 3 R ARP Dateneinheit u 22 Eee en Br a 114 Datagramm IP Dateneinheit 22m mn 116 ICMP Dateneinheit s a ssp a d Aaoi as g ap r A aa ala a i ang 118 UDP Dateneinheit 2 2 2 mm on 118 TOR D teneinheit i au EEN mn ec Be E 119 globale Statistiken 2 22 2 Cm nommen 121 Algorithmus zum Programmieren einer Verbindungstopologie 127 Topologie A2BOB2D1D2EOA3COC2D3 e 128 P Code eines Filterausdrucks aoaaa 131 Allgemeines Nachrichtenformat 132 Vermitteln von Nachrichten 133 Verteilen von Dateneinheiten 2 2 on on 135 Vereinfachter Zugriff auf Ger te 136 Empfangen einer Nachricht auf dem Hostrechner 137 Fenster des Hostrechner Prozesses 147 Standardausgabe Fenster 2 22 2 Cm nn 148 Das File Men sca re 4 wa ae E ee BE ee 149 Das Show Men ai 4 4 NEEN EN AE a e i aae EN 150 Das Messung Men 150 Standardeingabe Fenster 2 2 2 Co nn n nenn 151 Ein zu kleines Fenster 151 Protokolle w hlen 2 2 2 Co non nn 156 Zu protokollierende Informationen w hlen 2 22222020 157 ARP RARP Fenster ege es ee ee a a H 158 Fenster MBit s use ee e 160 Grenzdurchsatz in Auftr ge s ee a 163 Grenzdurchsatz in KByte s LEE 2 2 A ee 164 Grenzdurchsatz in Auftr ge s 277 165 Grenzdurchsatz in MBit s 2 4222 22 a ea 166 Grenzdurchsatz bei verschiedenen Filter Auftr gen 168 Grenzdurchsatz eines Pakettr ge
65. ARDWARE 59 A f i Schicht n 1 er gt y i e Weitergabe v PDUs Schicht n gt gt Sech gt Realisierung f V TEENS Interproze kommunikation Schicht n 1 a SS C Proze i i y KE Protokollinstanz Abbildung 3 11 Protokollpipeline 3 3 3 2 Sende und Empfangspipeline Eine Sende und Empfangspipeline auch horizontale Parallelit t genannt entsteht durch die konzeptionelle Unterteilung jeder Protokollinstanz in ihre Sende und Emp fangsfunktionen Diese Gruppen von Funktionen k nnen weitgehend unabh ngig voneinander und somit parallel ausgef hrt werden vgl Abbildung 3 12 Schicht n Schicht n u gn senden empfangen PDUs oder Kontrollinformationen ROTE gt Realisierung gt Interproze kommunikation O Proze Protokollinstanz Abbildung 3 12 Sende Empfangspipeline KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 60 3 3 3 3 Protokollfunktionen Will man eine feinere funktionale Dekomposition erreichen als bei der Kombination aus horizontaler und vertikaler Parallelit t mu man die einzelnen Protokollinstan zen weiter unterteilen Diesem Konzept liegt die Annahme zugrunde da in Proto kollen verschiedene Funktionen unabh ngig voneinander ausgef hrt werden k nnen Diese Funktionen sind protokollspezifisch und m ssen durch eine genaue Analyse des Protokolls gefunden werden vgl Zit91b S Sp Abbildun
66. Anfragen Antworten Protokolladresse HW Adresse ARP_RESPONSE il 1 08 00 09 94 d6 9a 134 100 15 169 ARP_REQUEST O ol 08 00 20 03 6a d9 134 100 15 162 ARP RARP Tabelle Format Anfragen Antworten Protokolladresse HW Adresse ARP_REQUEST i ol 00 00 00 00 00 00 134 100 15 94 ARP_REQUEST O ol 00 00 0c 0c 22 50 134 100 15 250 ARP_RESPONSE i 1 08 00 09 94 46 9a 134 100 15 169 ARP_REQUEST 0 ol 08 00 20 03 6a d9 134 100 15 162 ARP RARP Tabelle Format Anfragen Antworten Protokolladresse HW Adresse ARP_RESPONSE il 1 00 80 d3 a0 72 38 134 100 15 94 ARP_REQUEST O ol 00 00 0c 0c 22 50 134 100 15 250 ARP_RESPONSE il 1 08 00 09 94 d6 9a 134 100 15 169 ARP_REQUEST O ol 08 00 20 03 6a d9 134 100 15 162 Abbildung 6 10 ARP RARP Fenster Ein Seiteneffekt beim Unterbrechen und Neustarten enable einer Messung ist da die Zeitstempel in einer Protokollierungsdatei wieder bei Null beginnen Dadurch erkennt man auch nachtr glich da eine Messung unterbrochen wurde Das Unterbrechen einer Messung ist au erdem Voraussetzung f r das Beenden einer Messung s u 6 3 6 Beenden einer Messung Man beendet eine Messung durch Eingabe des Kommandos drop name name ist dabei durch den Namen der jeweiligen Messung zu ersetzen In diesem Fall gibt der Benutzer drop _arp ein Zeile 32 Das Kommando schlie t im wesentlichen die Ausgabedateien die im Zu
67. Datenbits Startbits 0 1 1 LinkOut Linkin Daten und 1 0 SE LinkIn lt Linkou Best tigung LinkOut gt LinkIn berlappende Best tigung LinkIn lt LinkOut LinkOut Linkin nicht berlappende Best tigung LinkIn lt LinkOut Abbildung 3 6 Protokoll der Link Schnittstellen der Transputer vgl Ebe93 Seite 445 und die jeweiligen Best tigungen die bertragungskapazit t teilen m ssen In eigenen Messungen konnte gezeigt werden da aufgrund dieses Protokolls bei unidirektionaler Kommunikation die maximale bertragungsgeschwindigkeit 1472 8 Kbyte s betr gt Bei bidirektionaler Kommunikation betr gt die bertragungsge schwindigkeit 2137 25 Kbyte s vgl Ben94 S 102ff 3 2 1 5 Transputer Boards Transputer werden zusammen mit lokalem Speicher der an die externe Speicher schnittstelle angeschlossen wird vgl Abbildung 3 3 auf Transputer Boards TBs angeordnet Au erdem befinden sich auf TBs spezielle Baugruppen f r die Anbindung der Transputer an den Hostrechner s u und an Peripherieger te bzw f r die Kop pelung der Transputer untereinander Im Arbeitsbereich RO werden zwei verschiedene TB Typen eingesetzt MTM PC Board Parsytec Wesentliche Merkmale dieses TB sind e vier T800 Transputer e vier Megabyte lokaler Speicher pro Transputer KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 50 e Konfigurationskan le f r die Vernetzung mehrerer TB e programmierbare Kreuzschienenver
68. Datenfeldes in diesem Fall die L nge des eingebetteten IEEE 802 2 Logical Link Control LLC Frames angibt Der Frame mu eine minimale L nge von 64 Byte haben um Kollisionen sicher erkennen zu k nnen Alle Frames mit einer L nge von weniger als 64 Byte werden als Fragmente einer Kollision angesehen und laut Spezifikation vernichtet vgl Black 1993 S 129 Durch die Festlegung da ein Ethernet Frame im Frame Typ keine Werte kleiner oder gleich 1518 haben darf ist eine Unterscheidung der beiden Frames m glich Empf nger Sender Frame Pr ambel adresse adresse Typ Daten CRC 8 Byte 6 Byte 6 Byte 2 Byte 46 1500 Byte 4 Byte maximal 1518 Byte N Daten Pr ambel Empf nger Sender L Dat CRC dee SFD adresse adresse ange Kee 8 Byte 6 Byte 6 Byte 2 Byte 46 1500 Byte 4 Byte SFD Start Frame Delimiter DSAP SSAP Control LLC Daten 8 bit 8 bit 8 16 bit IEEE 802 2 Logical link control LLC Dateneinheit DSAP Destination Service Access Point SSAP Source Service Access Point Control Kontroll Feld LLC Daten LLC Benutzerdaten Abbildung 5 10 Ethernet und IEEE 802 3 Frame vgl Black 1993 S 124 Dies ist die maximale L nge eines IEERE 802 3 Frames ohne Pr ambel KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 112 Neben der Identifizierung des Frames sollten bei ei
69. Der Kontroll Thread stellt nun eine proze spezifische Nachricht zusammen die Auskunft ber bestimmte Zu standsvariablen des Prozesses gibt Diese Nachricht wird dann an den Hostrechner zur ckgesendet Die Kooperation zwischen dem Kontroll Thread und den Threads die die Nach richtenvermittlung realisieren ist bei allen Prozessen gleich Unterschiede bestehen lediglich in der Anzahl und der Art von Nachrichten auf die reagiert wird bzw an welche Prozesse sie weitervermittelt werden Bei der Beschreibung der folgenden Pro zesse wird daher nicht mehr auf diese Threads eingegangen 5 2 3 5 Thread f r die Aktualisierung des Zeitstempels Dieser Thread ist ebenfalls hochpriorisiert Er hat zwei Aufgaben e Aktualisieren des Zeitstempels mit einer Aufl sung von einer Millisekunde Der Zeitstempel wird in einer globalen Variable gespeichert und von der Filterfunk tion verwendet um Dateneinheiten zu markieren die nicht vernichtet werden e Periodisches Ausl sen einer Nachricht TIMER nach Ablauf einer vom Benutzer w hlbaren Zeit Beim Prototypen wird diese Nachricht jede Sekunde ausgel st und an die Pakettr ger weitervermittelt Die Pakettr ger nutzen diese Nachricht um periodisch ihre lokalen Statistiken an die globale Statistik weiterzuleiten Alternativ h tte auf jedem Prozessor auf dem ein Pakettr ger plaziert wird ein ei gener Zeitgeber realisiert werden k nnen Das gew hlte Vorgehen ist j
70. Dialogfelder Diese Eingabeformulare werden auf der graphischen Benutzeroberfl che dargestellt Der Benutzer kann mit der Maus schnell und effizient umfangreiche Auswahlen auf diesen Formularen treffen Die vom Benutzer gemachten Angaben k nnen dann wie derum in entsprechende Aktionen umgewandelt werden Die Realisierung der Eingabeformulare ist relativ einfach Mit entsprechenden Ent wicklungswerkzeugen kann das Aussehen der Formulare graphisch interaktiv bestimmt werden Die Verkn pfung mit dem Programm ist jedoch sehr aufwendig da f r jedes Formular eine Funktion zur Reaktion auf die Benutzereingabe entwickelt werden mu Abschlie end ist zu der Benutzereingabe anzumerken da die Kombination von Kommandoeingabe und Eingabe ber Dialogfelder eine sehr effiziente Schnittstelle f r den Benutzer darstellt Die Programmierung ist jedoch entsprechend aufwendig 5 3 4 2 Realisierung von Textfenstern Die Realisierung von Fenstern zum Anzeigen von Text ist aufgrund der Anforderungen beim Entwurf vgl Abschnitt 4 4 4 deutlich aufwendiger als die Realisierung der Dialogfelder Die Darstellung der vergleichsweise statischen Dialogfelder kann der graphischen Benutzeroberfl che berlassen werden Die Darstellung von Text und das Rollen von Textausschnitten im Fenster mu aus zwei Gr nden vom Programmierer selbst realisiert werden 1 Die Fenstergr e und somit der sichtbare Textausschnitt kann vom Benutzer ver ndert werden
71. Die zu verwendene Hardware verf gt jedoch nicht ber gemeinsamen Speicher Au erdem ist dieses Konzept ungeeignet um Dateneinheiten von verbindungslosen Protokollen zu analysieren Nur durch Verteilungs Prozesse und dem damit verbun denen Overhead kann entschieden werden welcher Proze sozusagen neben seiner Verbindung eine solche Dateneinheit verarbeitet 3 3 4 5 Bewertung der Paketparallelit t Das Konzept der Paketparallelit t ist leicht realisierbar hnlich der Verbindungs parallelit t werden gleichartige Prozesse auf die Prozessoren plaziert Auch hier kann eventuell vorhandener sequentieller Programmcode weiter benutzt werden Alle f r die Auswertung der Dateneinheiten notwendigen Funktionen werden zu einem Proze zusammengefa t Erweiterungen sind ebenfalls leicht einzubringen Der Proze wird um das neue Modul erweitert Der Hauptvorteil dieses Konzeptes bei Erweiterungen ergibt sich aus der Gleichartigkeit der Analyseprozesse Eine Erweiterung ist somit automatisch auf allen Prozessen pr sent Ein Nachteil dieses Ansatzes besteht in den dezentral anfallenden Analyseergebnis sen Da Dateneinheiten des gleichen Protokolls von verschiedenen Prozessen analysiert werden k nnen mu man durch zus tzliche Unterst tzungsfunktionen mit entspre chendem Overhead daf r sorgen da diese Ergebnisse zusammengef hrt werden Protokollabh ngige Interproze kommunikation findet nur bei verbindungsorientierten
72. Filtern einer Dateneinheit aufwendig und zeitintensiv ist Ein einzelner Proze k nnte durch das Filtern zum Engpa werden Bei Messungen in Verteilten Systemen ist die erste Alternative ebenfalls vorzu ziehen In einem Verteilten System kann es vorkommen da mehrere Anwendungen auf die Me daten zugreifen so da es bei der Rohdatenerfassung nicht m glich ist zu entscheiden welche Daten gefiltert werden k nnen Ein Vorteil der zweiten Alternative besteht in der M glichkeit die Filterfunktio nen in einem eigenen Proze zu kapseln Das erh ht die Modularit t des Werkzeuges Au erdem vermeidet ein Filtern unmittelbar nach der Rohdatenerfassung das Versen den von nicht ben tigten Rohdaten an die Pakettr ger Unabh ngig von dieser Reduktion der Rohdaten k nnen weitere Filtervorg nge zu einem sp teren Zeitpunkt erforderlich sein Beispielsweise k nnte sich im Zuge der Analyse durch die Pakettr ger ergeben da bestimmte Informationen der Rohdaten KAPITEL A ENTWURF DES MESSWERKZEUGES 83 nicht ben tigt werden Diese Informationen k nnten in einer zweiten Filterphase beispielsweise durch den globalen Statistikproze vernichtet werden 4 4 5 2 Entwurf der Filterfunktionen Auch bei der Definition und Eingabe von Filtern gibt es verschiedene M glichkeiten 1 Vorgabe von Standardfilter Der Benutzer kann in diesem Fall aus einer vorge gebenen Menge von Standardfilter ausw hlen 2 Universelle Filter Der Benutze
73. Funktion liefert einen Zeiger auf die lteste unverarbeitete Nachricht im Ringpuffer Nachrichten kopieren und l schen Nachrichten in den Ringpuffer einschreiben Diese Funktion wird durch die Emp fangsfunktion aus Abschnitt 5 4 4 realisiert 5 5 2 Realisierung der Symboltabellen Verwaltung Der Benutzer hat die M glichkeit ber eine Datei Symbole zu definieren Diese Sym bole kann er beispielsweise bei Eingaben ber die Kommandozeile verwenden Der Zugriff auf die Werte und Attribute der Symbole wird ber eine Streufunktion rea lisiert Falls zwei oder mehr Symbole durch die Hash Funktion auf denselben Wert abgebildet werden werden die Symbole mit ihren Attributen in einer Liste angeordnet Diese Funktion wird wiederum in Funktionen benutzt die e Symbole und deren Attribute in einer Symboltabelle ablegen e Symbole und deren Attribute aus der Symboltabelle zur ckgewinnen e die Existenz von Symbolen berpr fen um unbeabsichtigtes Neubelegen vorhan dener Attribute zu vermeiden 5 6 Vorgehen bei Erweiterungen In diesem Abschnitt werden einige Hinweise gegeben wie der Prototyp erweitert wer den k nnte Die allgemeine Vorgehensweise wird in Abschnitt 5 6 1 diskutiert Ein konkretes Beispiel folgt in Abschnitt 5 6 2 5 6 1 Erweitern des Prototypen um neue Transputer Prozesse Grundlage dieser Erweiterungen sollte das Proze Template aus Abbildung 5 3 sein Es werden in jedem Fall die Vermittlungsfunk
74. GES 74 Funktionen dieses Prozesses werden in Abschnitt 4 4 5 vorgestellt Diese Einteilung in zwei Prozesse ist kontra intuitiv Sie ergibt sich aus einer Re striktion der Hardware Der in Abbildung 3 8 dargestellte Speicher von 64Kbyte reicht gerade aus um die Funktionen zur Ansteuerung der Ethernet Schnittstelle aufzuneh men Die Zwischenspeicherung gr erer Datenmengen ist in diesem Speicher nicht m glich Eine Zwischenspeicherung ist aber erforderlich um die Rohdatenerfassung von der Analyse zu entkoppeln Die Hauptaufgabe der Rohdatenerfassung beschr nkt sich demnach auf die An steuerung und Kontrolle der Ethernet Schnittstelle Die Architektur dieser Schnitt stelle wurde bereits in Abschnitt 3 2 1 5 kurz angesprochen Zur Ansteuerung der eigentlichen Ethernet Schnittstelle mu auf dem T225 Transputer ein Ger tetreiber geladen werden der folgende Aufgaben bernimmt e Initialisieren der Schnittstelle e Ausf hren von Funktionstests e Konfigurieren der Schnittstelle Festlegen einer Ethernet Adresse f r die Schnittstelle Verwalten von Sende und Empfangswarteschlange e F hren von netznahen Statistiken e Empfangsmodus w hlen e Senden von Dateneinheiten e Empfangen von Dateneinheiten e gegebenenfalls Generieren von Fehlermeldungen 4 4 2 Entwurf der essentiellen Funktionen f r die Analyse Die parallele Analyse ist der Kern des Me werkzeuges Mit Hilfe der Analyseergebnisse k nnen Aussagen ber die
75. Gewichtung gew hrleistet Andererseits mu man anmerken da die geringe Anzahl analysierbarer Protokolle und die sehr eingeschr nkten Analysefunktionen kaum praxisnahen Anforderungen gerecht werden Hier ist viel Raum f r Erweiterungen Die wichtigsten bisher nicht realisierten Funktionen sind e Hilfsfunktionen Das Werkzeug sollte idealerweise selbsterkl rend sein Ein wichtiger Schritt in diese Richtung ist die Implementierung einer kontextsensi tiven on line Hilfsfunktion Unter OS 2 ist dies verh lnism ig leicht da die Realisierung von Hilfsfunktionen von den Entwicklungswerkzeugen unterst tzt wird Analysefunktionen f r anwendungsnahe Protokolle und Multi Media Protokolle Es sind bisher nur Analysefunktionen f r netznahe Protokolle Ethernet IEEE 802 3 ARP RARP und Protokolle auf der Vermittlungs und Transportschicht IP UDP ICMP TCP realisiert worden Ein wesentlicher Vorteil neben der prinzipiellen Erweiterbarkeit ist da parallel zur Realisierung eines neuen Pro tokolls eine Analysefunktion f r dieses Protokoll realisiert werden kann Ist der Prototyp des Protokolls einsatzbereit kann sofort mit Messungen begonnen wer den e Funktionen f r die Programmierung von Trigger vgl Abschnitt 2 2 Die M glichkeit benutzerspezifizierte Aktionen in Abh ngigkeit von bestimmten Er eignissen bei der Messung auszul sen w re w nschenswert f r Netzmanagement Aufgaben Slicing Techniken B
76. H Rena ran 5 2 4 Der Proze PPAKET 2 nn nme 5 2 5 Der Proze PSTAT e 5 2 6 Der Hostrechner Proze Realisierung der essentiellen Funktionen 2 2 2220 5 3 1 Realisierung des Ger tetreibers f r die Ethernet Schnittstelle 5 3 2 Realisierung der Analysefunktionen 2 22 2200 5 3 3 Realisierung der globale Statistikfunktionen 5 3 4 Realisierung der Funktionen f r den Hostrechner 5 3 5 Realisierung der Filterfunktionen Realisierung der unterst tzenden Funktionen 2 22 22 5 4 1 Realisierung der Vermittlungsfunktionen 2 2 2 5 4 2 Realisierung der Verteilungsfunktionen 2 2 22 5 4 3 Anmerkung zu Verbindungsmanagement Funktionen 5 4 4 Realisierung der Kommunikationsunterst tzung f r den Host ET GENEE Anmerkungen zu weiteren Funktionen 5 5 1 Realisierung der Ringpuffer Verwaltung 2 2 2 2 5 5 2 Realisierung der Symboltabellen Verwaltung Vorgehen bei Erweiterungen 2 a 5 6 1 Erweitern des Prototypen um neue Transputer Prozesse 5 6 2 Erweitern des Werkzeuges um die Proze klasse PNOTHING Anmerkungen zur Realisierung und zu Erweiterungen 5 7 1 Verwaltung der Programmquellen mit einem Versionskontrollsy STERN re ee a re We e ee dee i a 5 7 2 Wichtige nicht realisierte Funktionen 2 22 200 8 7 3 Erweiterungsvorschl ge 2 2 on on 5 7 4 Vergleich mit anderen Werkze
77. Link 0 Link 3 C0 CH Transputer 4 Link 0 Link 3 DO Di Externe Buchse E0 EN Konfigurartions Buchse kO K5 Tabelle 5 2 Symbolische Namen f r Transputerlinks und Buchsen eines TB KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 127 Sollen die Transputer zur ckgesetzt werden ja N wiederhole f r alle Transputer Verbindung zu diesem Transputer programmieren Reset Signal an diesen Transputer senden programmiere die Verbindungen aufgrund des Konfigurationsstrings f hre einen Reset auf diesem Transputer durch Abbildung 5 17 Algorithmus zum Programmieren einer Verbindungstopologie Die Angaben welche Verbindungen zu programmieren sind kann der Benutzer mit einem Konfigurationsstring an das Programm bergeben Der folgende Programm aufruf setzt alle Prozessoren in einen definierten Anfangszustand Parameter r zeigt die aktuelle Konfiguration an Parameter p und programmiert die Topologie aus Abbildung 5 18 Parameter cl conf r p c A2BOB2D1D2EOA3SCOC2D3 KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 128 Hostrechner 3 A 1 gt Kreuzschienen 2 verteiler gt c Uz lt gt 3 B 16 gt 2 2 0 3 D 1 lt gt Transputerlink p gt programmierte Verbindung Transputer OO O0 Externe Buchse Eo Abbildung 5 18 Topologie A2BOB2D1D2EOA3C0C2D3 Na
78. Messung am Kommunikationssystem vgl Ab schnitt 1 2 ein so kann man wiederum verschiedene Me aufgaben unterscheiden die sich meist direkt aus dem Analyseziel vgl Abschnitt 1 1 ableiten lassen In GK94 S 333 wird eine Einteilung der Me aufgaben in vier Bereiche vorgeschlagen bertragungstechnische Messungen an bertragungswegen Gemessen werden analoge Gr en wie Impedanzen Ger usche und Frequenzgang Bei digitalen Messungen k nnen beispielsweise Bitfehlerh ufigkeiten ermittelt werden Schnittstellentest Bei diesen Messungen sollen Kabeldurchg nge Installationen und Pegelbereiche berpr ft werden Grundlage dieser Tests sind die Normen f r die zu vermessenden Schnittstellen Daten und Protokollanalyse Ziel dieser Messungen ist ein Aufzeichnen und Aus werten des Datenstroms und ein Testen der eingesetzten Protokolle Durch einen Protokollanalysator kann beispielsweise berpr ft werden ob sich ein Protokoll gem seiner Spezifikation verh lt Netzanalyse Bei der Netzanalyse wird der Durchsatz und die Verkehrslast in einem Netz gemessen Die f r die jeweiligen Messungen eingesetzten Monitore leiten sich bei dieser Klassi fikation direkt aus dem Namen der Messung ab So werden bei GK94 Bitfehlerme ger te Schnittstellentester Daten Protokoll und Netzanalysatoren unterschieden vgl GK94 S 337 368 Eine genauere Unterscheidung der oben als Netzanalyse klassifizierten
79. Messungen wird in Wo193 S 16f vorgenommen Ein Netzmonitor wird hier subklassifiziert in 10Diese Kategorie ist wiederum subklassifizierbar als bertragungstechnische Messungen an analo gen bertragungswegen und bertragungstechnische Messungen an digitalen Ubertragungswegen KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 20 e LAN Monitor e Stations Monitor e Leitungs Monitor und e Protokoll Monitor Diese Terminologie geht unmittelbar auf die zu analysierenden Subsysteme eines Kom munikationssystems ein Man kann das Kommunikationssystem als ganzes betrachten LAN Monitor oder einzelne Subsysteme Die Arbeitsplatzrechner die Server und andere individuell adressierbare Hardware im Netz Stations Monitor deren physika lischen Verbindungen untereinander Leitungs Monitor und die von ihnen eingesetz ten Protokolle Protokoll Monitor Hinzu kommen bei dieser Klassifizierung Lastmonitore f r Lastmessungen auf ver schiedenen Ebenen des Kommunikationssystems zur Erstellung von Verkehrsmatrixen und Leistungsmonitore die im wesentlichen den Durchsatz bestimmter Auftr ge bei einer gegebenen Last messen Abschlie end ist zu der Klassifizierung nach der Me aufgabe anzumerken da sie einerseits intuitiv ist da sie sich direkt auf die Hauptaufgabe des jeweiligen Monitors bezieht Andererseits ist sie zwangsl ufig unvollst ndig da mit neuen Anforderungen und Aufgaben neue Klassen denkbar sind Dar ber hinaus f
80. Monitore weitere Nachteile Aufgrund der engen Koppelung der SW Monitore mit dem Me objekt kann ein SW Monitor fehlerhafte Ergebnisse produzieren wenn das beobachtete System selber fehlerhaft ist Ein HW Monitor liefert hingegen auch von fehlerhaften Systemen kor rekte Me werte Ist das System ausgefallen steht der SW Monitor berhaupt nicht mehr zur Verf gung Die enge Koppelung mit dem System verhindert i d R auch den Einsatz von SW Monitoren auf anderen Systemen Falls dies berhaupt m glich ist m ssen Anpas sungen an andere Systeme vorgenommen werden Aufgrund ihrer anwendungsnahen Einbindung in das zu untersuchende System werden parallel auftretende Ereignisse meist sequentiell vom SW Monitor aufge nommen Ein Beispiel sind Unterbrechungssignale Interrupts eines Rechners Diese k nnen parallel auftreten werden durch die Rechnerhardware jedoch sequentiell zur Abarbeitung an das Betriebssystem weitergegeben Ein SW Monitor kann fr hestens auf dieser Ebene Betriebssystem die Unterbrechungen registrieren nimmt sie also in jedem Fall als Sequenz auf Ein HW Monitor k nnte durch mehrere Me f hler an den Unterbrechungsleitungen des Rechners parallel auftretende Unterbrechungen auch als solche registrieren HW Monitore hingegen sind teuer Erweiterungen oder Ver nderungen sind meist mit erheblichem Aufwand verbunden sofern dies berhaupt m glich ist Der Vorteil der hardwarenahen Messung wird schnel
81. P response Diese Werte sind in Abh ngigkeit vom Frame Typ s o zu berpr fen 4 HLEN gibt die L nge der physikalischen Adresse an und mu bei Ethernet den Wert 6 haben 5 PLEN gibt die L nge der Adresse des Protokolls einer h heren Protokollebene an F r IP Adressen mu hier der Wert 4 stehen vgl auch Abbildung 5 12 SA amp EA Die L nge ist konstant 28 Byte Sie braucht nicht berechnet zu werden In ARP und RARP Dateneinheiten werden keine weiteren Protokolle eingebettet Eine Erkennung ist deshalb nicht n tig Neben diesen invarianten Informationen mu die Analyse bei einer ARP Anfrage die physikalische Adresse hier Ethernet Adresse des Senders physikalische Sender adresse und die IP Adresse des Senders IP Senderadresse gewinnen Bei einer ARP Antwort l t sich zus tzlich auch das Adre paar des Empf ngers gewinnen Bei einer RARP Antwort kann das Adre paar des Empf ngers gewonnen werden vgl Com91 S 80f Die variablen Teile des R ARP Protokolls hier die Adre paare f r Sender und Empf nger sind von besonderer Bedeutung f r die Netzanalyse Einerseits kann durch das schlichte Anzeigen einer ARP Tabelle mit den Zuordnungen der Adres sen zueinander gepr ft werden ob beispielsweise eine Adresse mehrmals vergeben wurde Andererseits erm glichen ARP Tabellen zusammen mit Domain Name Sy stem DNS Informationen die Aufl sung eines symbolischen Namens b
82. Paketparallelit t Die Bewertung anhand dieser Kriterien erfolgt durch grunds tzliche Aussagen zu den einzelnen Parallelisierungsm glichkeiten da diese in der Regel prinzipielle Vor und Nachteile haben Dar ber hinaus werden die Konzepte im Vergleich miteinander bewertet Dies ist n tig da sich die Vor und Nachteile der einzelnen Konzepte schlecht gegeneinander verrechnen lassen Vielmehr mu der Vergleich der Konzepte zeigen welche Punkte als besonders vor oder nachteilig zu bewerten sind 3 3 4 1 Bewertung der Schichtenparallelit t Das Konzept der Schichtenparallelit t ist einfach zu realisieren F r bereits imple mentierte Protokolle kann der sequentielle Programmtext bernommen werden Die Anpassungen an ein Me werkzeug sind ebenfalls leicht realisierbar Beispielsweise kann man protokollabh ngige Trigger der Pipelinestufe zuordnen die der jeweiligen Protokollschicht entspricht Allerdings ist das Konzept der Protokollpipeline f r einige Protokolle unreali stisch Beispielsweise sind die Protokolle IP und UDP derart eng miteinander ver zahnt da sie nur noch konzeptionell auf unterschiedlichen Protokollebenen stehen Bei einer Realisierung w rde man deshalb aus Effizienzgr nden darauf verzichten diese beiden Protokolle auf verschiedenen Pipelinestufen zu verarbeiten Erweiterungen an der Protokollpipeline sind ebenfalls einfach realisierbar Soll ein weiteres Protokoll analysiert werden ben t
83. Paral lelverarbeitung bei Me werkzeugen f r Hochgeschwindigkeitsnetze nicht nur hilfreich sondern auch notwendig ist Aufgrund des Netz Zugriffsverfahrens bei FDDI kommt es auch unter hoher Last zu keinen Kollisionen wie etwa bei Ethernet Die maximale Auslastung eines FDDI Netzes kann daher das theoretische Maximum auch in der Praxis erreichen Da f r die Leistungsprognose die Rechenleistung eines modernen Prozessors vorausgesetzt wurde wird deutlich da Einprozessor Systeme zuk nftig nicht in der Lage sein werden vergleichbare Messungen in einem HSN durchzuf hren Die Anforderungen aus Abschnitt 2 7 4 konnten erf llt werden W hrend die Anfor derungen bez glich der Standardauswertung und der graphischen Benutzeroberfl che prim r der Pr sentation des Werkzeuges dienten sicherten die Anforderungen zur Analyse von Protokollen der TCP IP Familie da der Prototyp praxisrelevante Roh daten analysieren kann 8 2 Erfahrungen bei der Realisierung Die Erfahrungen bei der Realisierung des Prototypen lassen sich in drei Kategorien einteilen e Probleme mit der Hardware e Probleme bei der Programmierung e Gruppenarbeit 8 2 1 Probleme mit der Hardware Die Restriktionen durch die Hardware wurden in Kapitel 3 beschrieben Daneben gab es eine Reihe von Problemen die in der Anfangsphase der Diplomarbeit gel st werden mu ten Beispielsweise mu te f r die Koppelung der verwendeten Transputerboards KAPITEL 8
84. Priorit t hat dem neuen Proze beim Anmeldevorgang mittels runp jedoch hohe Priorit t zuteilt Der nun hochpriorisierte neue Proze geht sofort in den Zustand aktiv ber Aktive Prozesse mit niedriger Priorit t k nnen vom Scheduler deaktiviert wer den falls sie zwei Zeitscheibendurchl ufe ununterbrochen gerechnet haben Sie wer KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 47 den dann wieder an die Liste der bereiten Prozesse angeh ngt und warten auf ihre Reaktivierung Au erdem k nnen sie von Prozessen hoher Priorit t unterbrochen werden Dies kann eintreten wenn ein Proze hoher Priorit t zuvor im Zustand war tend war und in den Zustand bereit bergegangen ist oder wenn ein Proze hoher Priorit t von einem Proze mit niedriger Priorit t angemeldet wurde und dann vom Scheduler sofort aktiviert wird Prozesse hoher Priorit t k nnen nicht unterbrochen werden F r einen unterbrochenen Proze niedriger Priorit t gibt es eine spezielle Da tenstruktur die die Registerinhalte sichert so da dieser sofort nach der Beendigung des priorisierten Prozesses wieder aktiviert werden kann ohne den Umweg ber die Bereitschaftsliste zu gehen Weiterhin k nnen aktive Prozesse gewollt beendet wer den indem der Scheduler durch Aufruf spezieller Maschinenbefehle dazu veranla t wird den Proze in den Zustand angehalten zu berf hren Dieser Zustand kann bei der Fehlersuche in Pro
85. Proze lokale Statistik netznahe Statistik Ringpuffer JI Empf nger SA Analysevorgaben d von Hostrechner Proze Analysedaten von 3 4 netznahe Statistik von 3 4 lokale Statistik von 3 4 Abbildung 5 7 Datenflu diagramm von PSTAT KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 104 5 2 6 Der Hostrechner Proze In Abschnitt 5 1 1 wurde dargestellt da es pro Transputer nur einen Proze gibt Dies gilt nicht f r den Hostrechner Hier bernimmt das Betriebssystem OS 2 die Betriebsmittelverwaltung und die Zuteilung der Rechenzeit Es k nnen quasi gleich zeitig mehrere Prozesse laufen Die Unterscheidung zwischen Thread und Proze bleibt jedoch bestehen da auch OS 2 mehrere Ablauff den in einem Proze zul t Der Hostrechner Proze des Me werkzeuges ist demnach einer von vielen Prozessen auf dem Hostrechner Der Hostrechner Proze ist in zwei Threads aufgeteilt Ein Thread ist aus schlie lich f r den Empfang von Nachrichten vom Transputernetz zust ndig Er f hrt die in Abschnitt 5 4 4 diskutierte Unterst tzungsfunktion zum Empfangen von Nach richten aus Der andere Thread ist wiederum die Ablaufkoordinierung Er hat folgende Auf gaben e Initialisieren des Werkzeuges Einerseits m ssen Initialisierungen f r die in Ab schnitt 5 5 beschriebenen Funktionen durchgef hrt werden Insbesondere mu der Ringpuffer f
86. S 110 27 28 Eingebettetes Protokoll erkennen und analysieren 29 eingebettetes_protokoll f_n 1 meine_rohdaten 30 eingebettete_rohdaten f_n 2 meine_rohdaten 31 anderer_ergebnisspeicher char ergebnisspeicher 32 meine_datenlaenge 33 switch eingebettetes_protokoll 34 35 case PROTOKOLL1 36 andere_datenlaenge analysiere_protokolli eingebettete_rohdaten 37 anderer_ergebnisspeicher 38 break 39 case PROTOKOLL2 40 andere_datenlaenge analysiere_protokoll2 eingebettete_rohdaten 41 anderer_ergebnisspeicher 42 break 43 Andere bekannte Protokolle 44 case PROTOKOLL_N 45 andere_datenlaenge analysiere_protokoll_n eingebettete_rohdaten 46 anderer_ergebnisspeicher 47 break 48 default 49 andere_datenlaenge 0 50 D 51 return meine_datenlaenge andere_datenlaenge 52 Der Pseudo C Code verdeutlicht zwei Mechanismen die unter anderem die Spra che C f r die Realisierung nahelegten Es ist zum einen die elegante Zeigerarithmetik mit deren Hilfe in den Zeilen 31 32 der Zeiger auf den Speicherplatz f r die Analyseer gebnisse der aufzurufenden Funktion berechnet wird Der zweite Mechanismus wird in den Zeilen 9 12 dargestellt Es wird angenommen da in einer externen Datei die zur bersetzungszeit geladen wird Zeile 1 und 2 Typdefinitionen f r die abstrakten Da tentypen MEINE_ANALYSE_STRUKTUR und MEINE_SPEICHER_STRUKTUR vorhanden sind F
87. SEQ und der Best tigungsnummer ACK e Quellen und Senken Port und tege Mechanismus dient dazu den Betriebsmittelbedarf f r die Empfangspuffer der Verbindung zu kontrollieren 1Die TCP Portnummern identifizieren genau wie die UDP Portnummern eine Anwendung bzw ein eingebettetes Protokoll KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 120 e die Kontroll Bits Diese Daten k nnen wie bei den anderen Analysefunktionen zum Berechnen lokaler Statistiken benutzt werden oder sie werden verwendet um Verbindungen zu protokol lieren Verbindungsorientierte Protokolle und die Paketparallelit t Das Analysieren verbindungsorientierter Protokolle z B TCP nach dem Konzept der Paketparallelit t ist nur scheinbar ein Widerspruch Vielmehr ist das Analysieren von verbindungslosen Protokollen mit dem Konzept der Paketparallelit t besonders leicht eine Analyse von verbindungsorientierten Pro tokollen nur u U aufwendiger Bei den oben dargestellten Berechnungen unterscheidet sich die Analyse berhaupt nicht Dies liegt daran da zur Zeit nur auf Werte zuge griffen wird die explizit in den Dateneinheiten mitgef hrt werden Soll bei Berechnungen auf Zust nde einer Verbindung eingegangen werden mu f r das jeweilige Protokoll nat rlich auch f r jede Verbindung ein Protokollautomat gef hrt werden Das F hren des Protokollautomaten Zustands nderungen proto kollieren ist wiederum protokollspezifisch Das Aufteilen de
88. SSE AUF DIE HARDWARE 46 3 2 1 2 Zentraleinheit Die CPU des Transputers ist speziell f r die Ausf hrung quasiparalleler Prozesse aus gelegt Um schnelle Kontextwechsel zwischen den Prozessen zu erreichen wurde der Mechanismus f r die Proze umschaltung in die Zentraleinheit integriert Ein Trans puter ben tigt somit keinen eigenen Software Scheduler f r die Proze verwaltung Ein Kontextwechsel kann in ca lus auf einem Transputer vorgenommen werden Es werden zwei Priorit tsstufen unterschieden Prozesse hoher Priorit t unter brechen Prozesse niedriger Priorit t sofort Die Zust nde der Prozesse auf einem Transputer und deren berg nge sind in Abbildung 3 4 dargestellt beendet vorbereitet oder angehalten je Ka unter brochen Zunppuuy wartend Ereignis eingetreten Abbildung 3 4 Zustandsdiagramm quasiparalleler Prozesse auf einem Transputer vgl Ebe93 Seite 389 Ein Proze ist worbereitet wenn sein Maschinencode im Speicher des Transputers steht Der Vaterproze kann ihn beim Scheduler des Transputers mit den Maschinen befehlen startp oder runp anmelden Der Scheduler h ngt diesen neuen Proze an die Proze liste Der Proze wartet nun solange im Zustand bereit bis ihn der Sche duler bei der Abarbeitung der Proze liste aktiviert Dann geht der Proze von bereit in aktiviert ber Anders verh lt es sich wenn der Vaterproze niedrige
89. Schnittstellen gemacht werden an denen die Rohdaten erhoben werden In Abschnitt 4 4 2 1 wird dieser Zusammenhang dargestellt Ein wichtiges Konzept beim Auswerten der Rohdaten ist die Unterscheidung zwi schen Erkennen und Analysieren der Dateneinheiten Dieses Konzept wird in Ab schnitt 4 4 2 2 vorgestellt da bei der Realisierung der einzelnen Analysefunktionen ebenfalls zwischen Erkennen und Analysieren unterschieden werden soll In Abschnitt 4 4 2 3 wird eine allgemeine Analysefunktion entworfen 4 4 2 1 Schnittstellen bei der Datenerfassung Zu Beginn mu auf die Schnittstellen eingegangen werden an der die Me daten er hoben werden Nach der Datenerhebung an diesen Schnittstellen k nnen durch die KAPITEL A ENTWURF DES MESSWERKZEUGES 75 Analyse Aussagen ber die betrachtete Schnittstelle gemacht werden Sind die Schnitt stellen definiert kann man die jeweiligen Analysefunktionen f r die einzelnen Schnitt stellen diskutieren Bei der Realisierung dieser Funktionen mu vor allem auf die Erweiterbarkeit geachtet werden Hierzu mehr in Abschnitt 5 3 2 Offensichtlich ist die einzige physikalische Schnittstelle des Me werkzeuges zum Netz die Ethernet Schnittstelle Man kann nun Systemmessungen durchf hren Das System ist in diesem Fall das Netz An dieser Schnittstelle k nnen die verschiedenen Auftr ge und deren Parameter gemessen werden Ein m glicher Auftrag w re das Ver senden eines Ethernet Frames M gliche Parameter
90. Sie sollten den Wert null 0 haben 3 Das Feld Gesamtl nge GL beinhaltet die L nge des Datagramms einschlie lich des Kopfes Die Angabe ist in Byte but Daraus ergibt sich da die Ge samtl nge maximal 65535 Byte betr gt Bei minimaler Kopfl nge 20 Byte s o ist die maximale L nge der IP Daten 65515 Byte Die L nge der IP Daten kann durch die Formel IP Daten L nge GL KL 4 berechnet werden 4 Die Felder Identifikation ID Flaggen FL und Fragment Position FP sind n tig um das richtige Zusammensetzen fragmentierter Datagramme sicherzu stellen Ist die L nge eines Datagramms l nger als die maximale L nge der auf einmal bertragbaren Daten maximal transfer unit MTU so mu das Datagramm in mehrere Fragmente mit einer L nge kleiner oder gleich MTU zerlegt werden Im Falle einer Fragmentierung bekommen alle Fragmente eines Datagramms die gleiche ID damit beim Zusammensetzen der Fragmente nach der bertragung nicht versehentlich zwei Fragmente verschiedener Datagramme zusammengef gt werden Fragment Position gibt an an welcher Stelle im frag mentierten Datagramm die Informationen dieser Dateneinheit liegen Der Wert von FP wird hierzu mit acht 8 multipliziert um die tats chliche Position der Daten des Fragments innerhalb des Datagramms zu ermitteln vgl Com91 S 97 Die drei Bits mit der Bezeichnung Flaggen geben an ob ein Datagramm frag mentiert werden darf Bit1 0 und ob weitere Fragment
91. Um zu verhindern da die Funktion bei Problemen nicht terminiert startet sie vor dem Laden des Programms einen Zeitgeber der die Funktion nach Ablauf einer festgelegten Zeit terminiert Die Funktion meldet den Erfolg oder Mi erfolg an die aufrufende Funktion Die Ladefunktion realisiert eine Teilfunktionalit t des Programms server Dieses Programm mu te nicht im Rahmen der Diplomarbeit erstellt werden sondern geh rt zu der Entwicklungsumgebung f r Transputer vgl Abschnitt 3 2 2 2 Das Programm iserver wird auf dem Hostrechner ausgef hrt Die Hauptauf gabe besteht darin ein Programm f r die Transputer ber die PC Schnittstelle vgl Abbildung 3 9 an die Transputer zu bertragen Dar ber hinaus erm glicht dieses Programm e den an die PC Schnittstelle angeschlossenen Transputer in einen definierten An fangszustand zu setzen Reset e dem an die PC Schnittstelle angeschlossenen Transputer Zugriff auf einige Funk tionen des Hostrechners z B Ausgaben auf den Bildschirm Dieser Zugriff auf die Betriebsmittel des Hosts wurden bei der Ladefunktion s o nicht ber ck sichtigt 5 3 4 7 Definieren einer Konfiguration Auch das Konfigurationsprogramm config geh rt zu der Entwicklungsumgebung f r Transputer s o Das Programm erm glicht es dem Benutzer wesentliche Teile einer Konfiguration festzulegen Dazu stellt es folgende Funktionen bereit e Benennen von Transputern e Benennen vo
92. Universit t Hamburg Fachbereich Informatik Arbeitsbereich Rechnerorganisation Diplomarbeit Entwurf und Realisierung eines parallelen Analysewerkzeuges f r Ethernet basierte Netze Betreuer Prof Dr Bernd E Wolfinger Dr Hans Joach m M ck Februar 1996 Carsten Benecke Am Plack 40 21217 Seevetal Tel 04105 80586 Erkl rung Ich versichere da ich die vorstehende Arbeit selbst ndig und ohne fremde Hilfe ange fertigt habe und keine au er der angegebenen Quellen und Hilfsmittel benutzt habe Seevetal den 08 02 1996 Danksagung Ich m chte mich an dieser Stelle bei meinem Erstbetreuer Herrn Prof Dr Bernd E Wolfinger und meinem Zweitbetreuer Dr Hans Joachim M ck f r ihre hervorragende Betreuung bedanken Die vielen Denkanst e und die konstruktive Kritik waren wert volle Hinweise f r die Erstellung dieser Diplomarbeit Kurzfassung In dieser Arbeit wird dargestellt wie der Einsatz von Parallelverarbeitung bei der Kommunikationsme technik die Bew ltigung zuk nftiger Me aufgaben in Hochge schwindigkeitsnetzen erm glicht Dazu wird ein Konzept der parallelen Protokollver arbeitung an die Anforderungen der Kommunikationsme technik angepa t um auf dieser Grundlage einen Prototypen eines parallelen Me werkzeuges zu realisieren Inhaltsverzeichnis 1 Analyse von Kommunikationssystemen 10 1 1 Notwendigkeit f r die Analyse von Kommunikationssystemen 10 1 2 Analysemethoden 22 2 moon 12
93. Verteilungsfunktionen Beispielsweise mu es eine solche Verteilungsfunktion geben um die Dateneinheiten auf die Pakettr gerpro zesse zu verteilen Verteilungsfunktionen k nnen analog zu den Funktionen f r die globale Statistik s o hierarchisch angeordnet werden falls nicht alle Pakettr ger prozesse direkt benachrichtigt werden k nnen Bei der 6 Prozessor Konfiguration gibt es nur zwei gleichartige essentielle Prozesse die Pakettr ger Nur f r diese beiden Pro KAPITEL A ENTWURF DES MESSWERKZEUGES 87 zesse ben tigt man eine Verteilungsfunktion die die Dateneinheiten auf sie aufteilt Die Dateneinheiten k nnten mit einer Verteilungsfunktion abwechselnd oder e zuf llig oder abh ngig von der Auslastung der Pakettr ger verteilt werden Es sind weitere Strategien denkbar wie man die Dateneinheiten auf die Pakettr ger aufteilen k nnte Der Prototyp soll mit der einfachsten Strategie realisiert werden Die Dateneinheiten werden abwechselnd auf die Pakettr ger verteilt 4 5 2 Entwurf von Verbindungsmanagement Funktionen Die Verbindungsmanagement Funktionen werden nur dann ben tigt wenn bei der Analyse von verbindungsorientierten Protokollen Zustands nderungen der Protokoll automaten beobachtet werden sollen oder das jeweilige Protokoll getestet werden soll Die Verbindungsmanagement Funktionen m ten in diesem Fall Verbindungen erkennen Eine Messung kann zu einem beliebigen Zeitpunkt ge startet werden Zu die
94. Werkzeuge die den Analysierenden bei einer Viel zahl seiner T tigkeiten unterst tzen Derartige Werkzeuge sind aufgrund ihrer Kom plexit t jedoch meist nicht intuitiv anwendbar so da eine Einarbeitungszeit n tig ist Auch hier ist jedoch das prim re Problem da eine bestimmte Analysemethode nur deshalb gew hlt wird weil f r sie ein Werkzeug verf gbar ist Zeitmangel M ssen Analysen innerhalb eines Projektes termingerecht abgeliefert werden kann der Termindruck dazu f hren da der Analysierende die Methode w hlt die vermeint lich am schnellsten zu einem Ergebnis f hrt Simulationsstudien an einem Modell Beispiele hierf r sind Markov Ketten Fehler Baum Diagramme oder Stochastische Petri Netze Einen vergleichenden berblick findet man in MWT94 KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 13 sind meist besonders zeitaufwendig Erstens mu ein Modell erstellt i d R in ei ner Programmiersprache programmiert werden Das ist zeitaufwendig da neben der Programmierung auch die Validierung des Modells und eventuell anschlie ende Modi fizierungen vorgenommen werden m ssen Zweitens sind die Experimente am Modell zeitaufwendig Der Zeitaufwand f r die Experimente ist u a abh ngig vom Untersu chungsziel Bei Optimierungsmodellen mu die Analyse mehrmals mit verschiedenen Parametern durchgef hrt werden bis eine sub optimale Parametermatrix gefunden ist vgl Wo193 S 9 Bei anderen Mod
95. ZUSAMMENFASSUNG UND AUSBLICK 177 ein passendes Kabel gebastelt werden da die TBs von verschiedenen Herstellern stam men Die potentielle Vernichtung der teuren Hardware vor Augen lie den Moment des ersten Einschaltens der Konfiguration zu einem unverge lichen Erlebnis werden Au erdem mu te ein Programm zur Programmierung des Kreuzschienenverteilers des TB entwickelt werden Ein vergleichbares Programm wurde leider nicht mit dem TB ausgeliefert Ein vergleichbares Problem trat bei dem TB mit der Ethernet Schnittstelle auf Es wurden zwar Programme zur Ansteuerung der Schnittstelle mit geliefert jedoch nicht f r den von uns verwendeten Compiler Der Device Driver f r die Ethernet Schnittstelle mu te an unsere Entwicklungsumgebung angepa t werden Die Anfangsphase der Diplomarbeit wurde dazu verwendet eine Infrastruktur f r die Programmierung der Parallelrechner zu schaffen auf der weitere Arbeiten im Ar beitsbereich Rechnerorganisation aufbauen k nnen Ein weiteres Problem ergab sich aus einem veralteten Hostrechner der in der Anfangsphase eingesetzt werden mu te Viel Zeit wurde darauf verwendet die ge ringe Leistungsf higkeit dieses Rechners auszugleichen Gl cklicherweise wurde dann f r die Diplomarbeit ein leistungsf higer Hostrechner zur Verf gung gestellt der es erlaubte OS 2 als Betriebssystem einzusetzen Dadurch ergaben sich neue M glich keiten beispielsweise die Fenster basierte Benutzerschnit
96. alternative Schnittstellenmodule erm glicht werden Die Anpassung an neue Protokolle geschieht durch Protokoll module die im Sinne der Orthogonalit t die vorhandene Funktionalit t zur Analyse auf die neuen Protokolle ausdehnen 2 7 Anforderungen an ein paralleles Me werkzeug f r Hochgeschwindigkeitsnetze In diesem Abschnitt soll verdeutlicht werden da heutige und zuk nftige Anforderun gen an Me werkzeuge f r Hochgeschwindigkeitsnetze parallele Realisierungen impli zieren Die bisher in diesem Kapitel aufgestellten Anforderungen an ein allgemeines Me werkzeug f r Kommunikationssysteme sind als Ideen zu verstehen die bei einer Rea lisierung ber cksichtigt werden k nnen Viele der genannten Benutzeranforderungen gelten f r alle nicht trivialen Realisierungen die eine Mensch Maschine Schnittstelle haben KAPITEL 2 ANFORDERUNGEN AN EIN MESSWERKZEUG 34 Diese Liste ist zwangsl ufig unvollst ndig da sich die Anforderungen der Benutzer jederzeit ndern k nnen Es werden daher in dieser Diplomarbeit einige rudiment re Funktionen realisiert die die Anwendungsgebiete des parallelen Me werkzeuges ver deutlichen vgl Abschnitt 2 7 4 Wichtiger als die Wahl zu realisierender Funktionen sind im Kontext von Hochge schwindigkeitsnetzen jedoch Anforderungen bez glich der Erweiterbarkeit vgl Ab schnitt 2 7 1 der Leistungsf higkeit vgl Abschnitt 2 7 2 und der Skalierbarkeit vgl Abschnitt 2 7 3 2 7
97. ammenfassung der Ergebnisse Die Themen der einzelnen Kapitel werden r ckblickend in Abschnitt 8 1 1 zusammen gefa t Danach folgt eine Darstellung der wichtigsten Ergebnisse dieser Diplomarbeit 8 1 1 Ein R ckblick auf die Diplomarbeit Die Kommunikationsme technik wurde als Analysemethode f r Kommunikationssy steme vorgestellt Es folgte eine Darstellung der verschiedenen Aufgaben von Me werk zeugen und eine Diskussion typischer Klassifikationen dieser Werkzeuge vgl Kapitel 1 In Kapitel 2 folgte die Diskussion der Anforderungen an Me werkzeuge Die wichtigsten Anforderungen ergaben sich aus der Me aufgabe Im Kontext von Hochgeschwindigkeitsnetzen wurden weitere Anforderungen dis kutiert Es wurde herausgearbeitet da durch den enormen Zuwachs an bertra gungsgeschwindigkeit zuk nftig besonders hohe Anforderungen an die Erweiterbar keit Skalierbarkeit und Leistungsf higkeit der Me werkzeuge gestellt werden In die sem Zusammenhang wurde die Parallelverarbeitung als eine M glichkeit vorgestellt Me werkzeuge an die hohen bertragungsgeschwindigkeiten zuk nftiger Netze anzu passen Das zweite Kapitel wurde mit einer Aufstellung der Anforderungen an ein paralleles Me werkzeug f r Hochgeschwindigkeitsnetze abgeschlossen In Kapitel 3 wurden Konzepte der Parallelverarbeitung diskutiert Neben einer Diskussion der Zuordnungsproblematik die ein zentraler Aspekt jeder Parallelverar beitung ist wurde speziell auf die paral
98. and verbunden ist Au erdem m ten die Zugriffe auf das Ger t Transputerboard dann den Aufrufkonventionen des Subsy stems entsprechen Um ein eigenes Format zu benutzen das besonders f r die Kom munikation mit Transputern geeignet ist w re eine weitere Schnittstelle f r die ent sprechende Umsetzung zu programmieren Ein weiterer Nachteil dieser L sung ist der relativ hohe Overhead der mit dem Zugriff auf Ger te ber Ger tetreiber einhergeht Neben den oben dargestellten sukzessiven Funktionsaufrufen f r jede Schnittstelle mu man noch den Aufwand f r mindestens zwei Proze wechsel hinzurechnen 1Das Anwendungsprogramm hat durch privilegierte Befehle kurzzeitig die gleichen universellen Zugriffsrechte wie der Betriebssystem Kern Daher l sen diese direkten Zugriffe keine Schutzverlet zungen aus 2Mindestens ein Proze wechsel beim bergang von der Anwendung zum Subsystem als Teil des Betriebssystems und ein weiterer Proze wechsel beim bergang vom Betriebssystem zur ck zur Anwendung Dabei ist zu beachten da die Proze wechsel unter OS 2 um ein vielfaches aufwendiger sind als auf einem Transputer KAPITEL A ENTWURF DES MESSWERKZEUGES 90 Die Ansteuerung der Transputerboards unter OS 2 soll durch privilegierte Be fehle erfolgen Zur Programmlaufzeit m ssen mindestens die folgenden Zugriffe auf das Iransputerboard m glich sein e Pr fen der Sendebereitschaft des ersten Tr
99. ander zu einer bestimmten Topologie angeordnet die sich graphentheoretisch als Menge von Knoten Prozesso ren und Menge von gerichteten oder ungerichteten Kanten Verbindungen darstellen lassen Eine Zuordnung eines Programms A hei t zusammenh ngend wenn der durch die Zuordnung entstehende Untergraph Menge der belegten Knoten und deren Kan ten zusammenh ngend ist Eine nicht zusammenh ngende Zuordnung bezeichnet man als gestreut Bei einer disjunkten Partitionierung kann man dar ber hinaus von der Zuordnung zu bestimmten Prozessoren abstrahieren und ausschlie lich festlegen wieviele Prozes soren ein Programm belegen soll Man bezeichnet diese Abbildung von der Menge der Programme auf die Prozessorzahlen 1 n als quantitative Partitionierung A quantitative Partitionierung x A 1 n mit 5 x A lt n 3 4 i 1 Dabei k nnen an alle Programme A nur so viele Prozessoren vergeben werden wie tats chlich vorhanden sind hier n Dies wird durch den Term mit der Summe ber alle Programme in Formel 3 4 sichergestellt Bei der Proze zuordnung werden nicht mehr die Programme den Prozessoren zuge ordnet sondern die Menge aller Prozesse aller Programme T wird auf die Prozessoren abgebildet Proze zuordnung 7 T P 3 5 Sind mindestens so viele Prozessoren vorhanden wie Prozesse T lt n kann man jedem Proze einen Prozessor zuteilen Eine solche Abbildung hei injektiv Vi kefl Thi k a r k 3 6
100. anschlie end in Kapitel 6 be schrieben Anhand von Beispielsmessungen wird gezeigt wie das Me werkzeug ge startet initialisiert und f r verschiedene Me aufgaben eingesetzt wird 5 1 Zusammenstellen der Funktionen zu Prozessen In diesem Abschnitt wird dargestellt wie die essentiellen Funktionen und Unterst t zungsfunktionen zu Prozessen zusammengestellt werden Unter einem Proze wird hier 93 KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 94 eine Menge von Funktionen die sich einen gemeinsamen Datenbereich teilen Umge bung und mindestens ein Kontrollflu auch Ablauffaden Thread genannt der die Reihenfolge der Funktionsaufrufe angibt verstanden Ein Proze kann auch ber mehrere nebenl ufige Threads verf gen Der Unterschied zwischen einem Proze und einem Thread ist da die Threads sich die Umgebung ihres Prozesses teilen jeder Proze hingegen ber eine eigene Umgebung verf gt die typischerweise vom Betriebssystem vor den Umgebungen anderer Prozesse gesch tzt wird Die grundlegende Entwurfsentscheidung nur einen Proze auf jeden Transputer zu plazieren wird im folgenden Abschnitt erl utert 5 1 1 Prozesse und Threads auf Transputern Ein Transputer ist in der Lage Prozesse ohne ein Betriebssystem zu verwalten vgl Abschnitt 3 2 1 2 Auch die geringen Zeiten f r einen Proze wechsel ca 14s lassen Diskussionen ob Threads oder Prozesse auf Transputern ausgef h
101. ansputer Komplexe Kommunikations und Kooperationsmechanis men sind dadurch leicht realisierbar Dar ber hinaus m ssen die Transputer auch mit dem Hostrechner w hrend der Ausf hrung des Programms kommunizieren k nnen Das Betriebssystem des Hostrechners mu daf r um Funktionen zur Ansteue rung der TBs erweitert werden Funktionen zur Ansteuerung bestimmter Hardware werden als Ger tetreiber engl Device Driver bezeichnet Neben der Ansteuerung der Ger te sollen die Ger tetreiber dar ber hinaus von den Besonderheiten einzel ner Ger te abstrahieren so da das Betriebssystem dem Benutzer eine einheitliche Schnittstelle zu allen unterst tzten Ger ten anbieten kann Ger tetreiber f r OS 2 Unter OS 2 ist der Zugriff auf Ger te noch ein wenig komplizierter da innerhalb des Betriebssystems mehrere Schnittstellen zu den Ger ten existieren Der von OS 2 be vorzugte Zugriff auf Ger te ist in Abbildung 4 5 vereinfacht dargestellt Zwischen der eigentlichen Anwendung und dem Ger t gibt es mehrere Schnittstellen die den Zugriff auf das Ger t koordinieren gestrichelt umrandet Die Subsystem Funktionsaufrufe erlauben der Anwendung den asynchronen Zugriff auf das Ger t Diese Funktionsauf rufe werden wiederum in I O Kontroll Kommandos umgesetzt die im wesentlichen einer Funktion des Ger tetreibers entsprechen Die Paket Schnittstelle bereitet die bergebenen Daten noch einmal f r den Ger tet
102. ansputer oder auf dem Hostrechner ist Als Bei spiel ist in Abbildung 5 24 das Empfangen einer Nachricht vom Transputer auf dem Hostrechner dargestellt Dadurch ist es m glich Funktionen dieses Codesegments in einem privilegierten Modus aus zuf hren so da Zugriffe auf die normalerweise vom Betriebssystem gesch tzten Ein Ausgabe adressen keine Schutzverletzungen darstellen KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 137 warte auf Sendebereitschaft des Transputers wiederhole 8 mal pr fe Sendebereitschaft des Transputers empfange ein Byte vom Transputer interpretiere die ersten 4 Byte als L ngenangabe interpretiere die anderen 4 Byte als Nachrichtentyp rest L ngenangabe 8 wiederhole rest mal pr fe Sendebereitschaft des Transputers empfange ein Byte vom Transputer Abbildung 5 24 Empfangen einer Nachricht auf dem Hostrechner 5 5 Anmerkungen zu weiteren Funktionen In Abschnitt 4 6 wurden weitere unterst tzende Funktionen entworfen In den fol genden Abschnitten wird dargestellt wie diese Funktionen zur Unterst tzung anderer Funktionen eingesetzt werden 5 5 1 Realisierung der Ringpuffer Verwaltung S mtliche Analyseergebnisse und sonstige Nachrichten die von den Transputern an den Hostrechner gesendet werden legen die Kommunikationsfunktionen vgl Ab schnitt 5 4 4 in einem Ringpuffer ab Die in Abschnitt 5 4 4 be
103. ansputers e Pr fen der Empfangsbereitschaft des ersten Transputers e Senden von Nachrichten an die Transputer e Empfangen von Nachrichten von den Transputern Auch in diesem Fall soll das Empfangen von Nachrichten vom Transputer nebenl ufig zu anderen Berechnungen auf dem Host erfolgen Das Senden von Nachrichten erfolgt im wesentlichen als Reaktion auf Benutzereingaben und mu daher nicht nebenl ufig realisiert werden 4 6 Sonstige unterst tzende Funktionen Neben den oben dargestellten Funktionen werden eine Reihe weiterer Funktionen zur Unterst tzung ben tigt Diese Funktionen braucht man jedoch nicht explizit zu ent werfen da es f r sie entweder Standardentw rfe gibt oder eine Realisierung ad hoc aufgrund der geringen Komplexit t m glich ist Die wichtigsten Funktionen dieser Kategorie werden kurz vorgestellt 4 6 1 Funktionen zur Ringpuffer Verwaltung Um kurzzeitige Spitzenlasten durch viele Nachrichten ausgleichen zu k nnen ben ti gen die Vermittlungsfunktionen s o Ringpuffer Eintreffende Nachrichten k nnen in Ringpuffern bis zur Verarbeitung kurzzeitig zwischengespeichert werden Das explizite Reservieren und Freigeben von dynamischen Speicher f r eintreffende Nachrichten ist unter hoher Last zu langsam 4 6 2 Funktionen zur Symboltabellen Verwaltung Vordefinierte und benutzerdefinierte Symbole sollen in einer Symboltabelle verwaltet werden Die daf r ben tigten Funktionen sind typi
104. asse an Dazu kommt noch die Proze klasse f r den Hostrechner Proze KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 140 Dazu bernimmt man einerseits die entsprechenden Kombinationen von PSTAT und setzt andererseits das Vermittlungs bit f r Nachrichten an den Hostrechner Der neue Proze verh lt sich damit transparent gegen ber Nachrichten anderer Prozesse untereinander F r den internen Kanal werden die Vermittlungs bits f r Broadcast Nachrichten und Multicast Nachrichten an die eigene Klasse gesetzt das Bit das oben PNOTHING zugeordnet wurde e Es soll nur auf Statusanforderungen vom Hostrechner geantwortet werden Es wird eine Funktion realisiert die eine Volltextnachricht an den Hostrechner Proze generiert Der Text soll lauten PNOTHING OK Die Nachricht wird als Antwort auf die Statusanforderung des Hostrechners generiert Das vorhandene Konfigurationsskript vgl Abschnitt 5 3 4 5 wird so abge ndert da eine Instanz der neuen Proze klasse zwischen Hostrechner Proze und PSTAT plaziert wird Falls vom Benutzer eine Statusinformation angefordert wird sollten sich die ande ren Prozesse mit ihren Statusinformationen melden Zus tzlich sollte die Meldung PNOTHING OK auf dem Terminal ausgegeben werden Erweiterungen um zus tzliche Prozesse einer vorhandenen Klasse beschr nken sich auf Erg nzungen an der Vermittlungstabelle und Sc
105. ast zu messen die durch einen bestimmten Knoten oder eine spezielle Verbindung in das Netz eingebracht wird Bei der Auswahl der Protokolle kreuzt man im Dialogfenster vgl Abbildung 6 8 alle Protokolle an die angezeigt werden sollen Zus tzlich sollte mur Lastinfo ausgew hlt werden Dadurch werden alle Analyseergebnisse die nicht f r die Berech nung der Auslastung ben tigt werden bereits im Transputernetz vernichtet Man erreicht so da auch bei hoher Auslastung keine Dateneinheiten aufgrund von Staus am prim ren Engpa Transputerboard zum Hostrechner verlorengehen vgl Ab schnitt 5 2 5 1 6 4 2 Das Fenster MBit s Nach dem Starten der Messung wird die Auslastung im Fenster MBit s in Megabit pro Sekunde angezeigt Es wird grunds tzlich ein Zeitintervall von 30 Sekunden dar gestellt Die verschiedenen Protokolle sind farblich markiert ber den Men eintrag Legende kann der Benutzer eine Legende ein und ausblenden die die Zuordnung von Farben zu Protokollen verdeutlicht Bei geringer Last ist es u U notwendig den Bereich zu skalieren um die verschiede nen Protokolle unterscheiden zu k nnen Der Benutzer kann dazu ber den Men ein trag Skalieren den Bereich der y Achse in Schritten von einem Megabit skalieren Das Skalieren kann w hrend vor oder nach einer Messung erfolgen Der Benutzer kann das Fenster au erdem in der Gr e ver ndern Abbildung 6 11 zeigt das Fenster
106. auf andere Hostrechner si chergestellt Au erdem brauchen verschiedene Programmodule nur einmal erstellt werden und k nnen dann sowohl auf dem PC als auch auf den Transputer eingesetzt werden Dies w re bei zwei verschiedenen Programmiersprachen nicht m glich Prozesse die auf dem Hostrechner plaziert werden sollen m ssen mit berset zern erstellt werden die Programmcode f r den Prozessor des Hostrechners erstellen vgl Abschnitt 3 2 2 1 Die Entwicklungsumgebung f r die Transputer wird in Ab schnitt 3 2 2 2 beschrieben Beispiele f r solche universellen Module sind abstrakte Datentypen wie Warteschlangen Stapel usw engl Compiler KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 54 3 2 2 1 Entwicklungswerkzeuge f r den Hostrechner Als bersetzer f r den PC wurde der weit verbreitete GNU C Compiler gew hlt Mit Ausnahme der systemspezifischen Funktionen k nnen die Quellprogramme durch einfaches Neu bersetzen auf einen anderen Rechnertyp bertragen werden da der GNU C Compiler f r alle relevanten Systeme frei verf gbar ist Auf dem PC wird OS 2 Version 3 0 als Betriebssystem eingesetzt Gegen ber MS Dos bietet OS 2 ein pr emptives Scheduling f r Prozesse und eine graphische Benutzeroberfl che Damit vereinfacht sich sowohl die Programmierung Verteilen der Funktionen auf Prozesse als auch die Pr sentation der Analyseergebnisse Auf dem PC werden dar ber hinaus folgende We
107. auf die Nachrichten mit den lokalen Statistiken die periodisch von den Pakettr gern eintreffen Beim Prototypen werden lediglich diese lokalen Statistiken zu einer globalen Statistik zusammengefa t und an den Hostrechner gesendet vgl Abschnitt 4 4 3 An dieser Stelle ist viel Raum f r zahlreiche weitere Statistiken beispielsweise Berechnungen zur L ngenverteilung der Dateneinheiten periodisches Erstellen von Verkehrsmatrixen etc Bei ersten Messungen mit dem Prototypen hat sich herausgestellt da die Schnitt stelle vom Hostrechner zum TB vgl Abbildung 3 7 der prim re Engpa bei den Messungen ist Aus diesem Grund wurden au erdem berwachungsfunktionen reali siert die dem Benutzer gegebenenfalls mitteilen da Analysedaten oder Dateneinhei ten verlorengehen Eine dieser berwachungsfunktionen wird von der Ablaufkoordinierung von PSTAT aufgerufen Bevor die Ablaufkoordinierung eine neue Nachricht bearbeitet berpr ft sie dazu eine Flagge die von dem Empfangs Thread gesetzt wird wenn er aufgrund der F llung des Ringpuffers keine weiteren Nachrichten ablegen kann In diesem Fall wird der Benutzer benachrichtigt Auch PSTAT ist als Datenflu diagramm in Ab bildung 5 7 dargestellt lokale Statistik zu Hostrechner Proze Analysedaten Analysedaten zu Hostrechner Proze globale Statistik Analysedaten globale Statistik 5 2 netznahe Statistik zu Hostrechner
108. ber unmittelbar vor der Ausf hrung machen Diese Methode ist e gut geeignet um die Last m glichst gleichm ig auf die Prozessoren zu verteilen da sie abh ngig gemacht werden kann von der aktuellen Last zur Ladezeit e relativ fehlertolerant Ist ein Prozessor zur Ladezeit als defekt erkannt worden k nnen Prozesse auf andere Prozessoren geladen werden 3 1 4 4 Zuordnung zur Laufzeit Bei der Zuordnung zur Laufzeit wird die oben beschriebene aggressive Zuordnung benutzt vgl Abschnitt 3 1 2 Diese Zuordnung ist daher e besonders gut an die sich ndernde Last anpa bar Durch Messung kann das Betriebssystem theoretisch die Auslastung der Prozessoren periodisch bestim men um m glichst gleichm ig alle Prozessoren zu belasten Lastausgleich engl load balancing vgl Hei94 S 279ff e besonders anspruchsvoll Die Algorithmen zur Messung und Bewertung von ver teilten Lasten m ssen Teil des Betriebssystems sein Au erdem mu es Algo rithmen zur Bewertung der Migrationskosten geben damit der Gewinn durch eine Proze migration zum Lastausgleich nicht durch die Kommunikationskosten Zeit wieder ausgeglichen wird e besonders rechenaufwendig Die oben genannten Algorithmen f r die dynamische Verteilung sind in der Regel nicht nur anspruchsvoll sondern auch rechenintensiv meist NP vollst ndig Der Aufwand steigt also exponentiell mit der Anzahl der Prozessoren und den darauf zu verteilenden Prozessen falls man
109. betr gt 10 Megabit pro Se kunde Die minimale L nge einer Ethernet Dateneinheit Frame betr gt 72 Byte inklusive der Pr ambel vgl Abbildung 5 10 Aus 107 24 72Byte a BE ergibt sich ein Grenzdurchsatz von 17361 Frames pro Sekunde Aufgrund des Grenzdurchsatzes eines Pakettr gers in Abh ngigkeit von den Auftr gen aus Tabelle 7 1 ergibt sich der Bedarf an Prozessoren aus Abbildung 7 7 12 Man betrachtet nur die Prozessoren mit Pakettr ger Prozessen 13Im folgenden wird Pakettr ger Proze mit Prozessor gleichgesetzt Es wird angenommen da f r jeden weiteren Pakettr ger ein weiterer Prozessor zur Verf gung steht KAPITEL 7 LEISTUNGSBEWERTUNG DES PROTOTYPEN 172 Anzahl Prozessoren bei Ethernet Analyse 5 T T T T T T T 4 a CH SNE EE Les g ENNEN TR N N N be 2 J 1 J 59 59 78 89 77 77 87 0 L L L L L L L DU i pei peiu piu pe peu 17361 Auftraege pro Sekunde Abbildung 7 7 Anzahl Prozessoren f r Ethernet Analyse Die Prozentangabe gibt die tats chliche Auslastung der Prozessoren in Abh ngig keit von der Last 17361 Auftr ge s und der Auftragsklasse an Mit vier Prozessoren w ren alle Dateneinheiten rechtzeitig analysierbar Die Auslastung von 87 bietet Raum f r weitere aufwendigere Analysen 7 3 2 Anzahl der Prozessoren f r FDDI Analyse Das Fiber Distributed Data Interface FDDI ist ein HSN mit einer b
110. bt es mehrere Statistikprozesse mehrere Pakettr gerprozesse und eventuell auch mehrere Schnittstellen zu einem Netz oder zu verschiedenen Netzen mit den daf r n tigen Prozessen f r die Ansteuerung der Schnittstellen Rohdaten erfassung Vor diesem Hintergrund ist zu berlegen wie die verschiedenen Prozesse beim Nachrichtenaustausch adressiert werden k nnen Die einfachste L sung besteht darin die Prozesse einer Konfiguration zu nume rieren F r jeden Prozessor und jeden Proze der Konfiguration kann dann ein Weg f r eine Nachricht von Sendeproze zu Empfangsproze angegeben werden Diese Vorgehensweise ist offensichtlich sehr unflexibel da Die Definition von Filtern erfolgt ber die Kommandozeile und somit auf dem Hostrechner Dieser verf gt ber einen INTEL Prozessor und nicht ber einen Transputer Es handelt sich also sowohl um einen anderen als auch um einen andersartigen Prozessor KAPITEL A ENTWURF DES MESSWERKZEUGES 85 e jede Ver nderung der Konfiguration eine Neuberechnung der Nachrichtenwege impliziert e keine Proze gruppen angesprochen werden k nnen und e jeder Proze der Nachrichten versenden m chte Kenntnis von allen potentiellen Empf ngern seiner Nachricht haben mu Wesentlich komfortabler bersichtlicher und leicht an neue Konfigurationen anpa bar w re eine L sung bei der die Nachrichten auf jedem Prozessor weitervermittelt wer den Au erdem wird man Namen f r Proze gruppen ver
111. cations in high speed networks as an example Technical report Universit t Hamburg Arbeitsbereich RO 1995 Ebe93 H Ebert Transputer und Occam Das Handbuch f r Systementwickler Heise Hannover 1993 Eck93 F Eckgold Systemprogrammierung OS 2 Vieweg Braunschweig Wiesba den 1993 182 LITERATURVERZEICHNIS 183 Epp95 F 87 FSZ83 FY94 GK94 GN193 Haus8 Hei94 Hin86 H0190 H0192 Inm88 Inm90 Int89 Jai91 Job92 JV87 K Eppele Spa ab 100 IX Multiuser Multitasking Magazin 4 80 90 apr 1995 F Fehlau et al Messung des Leistungsverhaltens Lokaler Netze mit einem Software Monitor Informatik Forschung Entwicklung 2 55 64 1987 D Ferrari G Serazzi and A Zeigner Measurement and Tuning of Computer Systems Prentice Hall Englewood Cliffs New Jersey 1983 P G S Florissiand Y Yemini Management of Application Quality of Service Technical Report NY 10027 DCC Lab Computer Science Dep Columbia University New York 1994 P Gerdsen and P Kr ger Kommunikationssysteme Theorie Entwurf Me technik volume 1 Springer Verlag 1994 M W Goldberg G W Neufeld and M R Ito A Parallel Approach to OSI Connection Oriented Protocols In B Pehrson P Gunningberg and S Pink editors Protocols for High Speed Networks III pages 219 232 North Holland 1993 J S Haugdahl Benchmarking LAN Protocol Analyzers In 13th Conf on
112. ch Ausf hrung dieses Programms sind alle Transputer in einem definierten An fangszustand und die vom Benutzer angegebenen Verbindungen sind im Kreuzschie nenverteiler programmiert Neben diesem eigenst ndigen Programm wurde eine Funktion realisiert die den Algorithmus aus Abbildung 5 17 f r die 6 Transputer Konfiguration aus Abbildung 3 9 ausf hrt Diese Funktion kann ber eine Ladefunktion vgl Abschnitt 5 3 4 6 von einem Proze des Hostrechners gestartet werden 5 3 4 6 Realisierung einer Ladefunktion Die Ladefunktion kann von einem Proze auf dem Hostrechner benutzt werden um die Transputer mit einem Programm zu laden Der Funktion wird der Dateiname der Programmdatei bergeben sowie eine Num mer zur Identifizierung des Transputerboards TB Die Funktion initialisiert den 3 Wenn man sich die symbolischen Namen aus Tabelle 5 2 als Knoten eines Graphen G und die pro grammierten Verbindungen dazwischen als Kanten des Graphen vorstellt dann sollte ein Programm das mit iserver geladen wird zuvor mit config derart konfiguriert werden da die Prozessoren und Verbindungen im Konfigurationsskript einen zusammenh ngenden Teilgraphen von G ergeben KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 129 an die PC Schnittstelle des jeweiligen TB angeschlossenen Transputer in den An fangszustand und kopiert die Informationen aus der bergebenen Datei ber die PC Schnittstelle auf den Transputer
113. cht mit jedem neuen HSN ein neuer Monitor konzipiert werden sollte Vielmehr mu die Skalierung des Monitors mit der Skalierung der Netze mithalten 2 7 4 Zusammenfassung der Anforderungen Die nun folgende Liste der Anforderungen an ein paralleles Me werkzeug mu unter folgenden Restriktionen realisiert werden e Das Me werkzeug soll im Rahmen einer Diplomarbeit konzipiert realisiert und bewertet werden Diese zeitliche Restriktion hat im wesentlichen Auswirkungen auf den realisierbaren Funktionsumfang e Es mu veraltete Hardware benutzt werden da Neubeschaffungen f r diese Di plomarbeit nicht m glich sind Insbesondere gibt es keinen Zugang zu einem Hochgeschwindigkeitsnetz Es mu deshalb mit einem Ethernet Netz gearbeitet werden Die Restriktionen durch die Hardware werden im Abschnitt 4 1 disku tiert Die Sicherheit des Netzes und die der daran angeschlossenen Rechner d rfen durch das Me werkzeug nicht beeintr chtigt werden Das Me werkzeug soll aus schlie lich passiv das Verkehrsaufkommen im Netz beobachten Dies hat ebenfalls Auswirkungen auf den Funktionsumfang der Realisierung Es wird insbesondere darauf verzichtet Empfangene Benutzerdaten in Dateien zu speichern Zugangsberechtigungen und dazugeh rige Pa w rter zu speichern oder durch Versenden von Dateneinheiten seitens des Me werkzeuges das zu un tersuchende Netz zu beeinflussen bertragungsgeschwindigkeiten in der Gr enordnung von e
114. d dieser 1 3 unveraendert message c und message h sind jedoch veraendert worden Diese Version behebt einen Fehler in der Interpretation des Ethernet Typ Feldes short int der Transputer short int der Network Byte Order C B 11 09 95 revision 1 2 date 1995 09 11 14 13 18 author benecke state Exp lines 50 2 Einfache Analysefunktionen fuer Ethernet eingebaut Neue Versionen von mtypes h net h net c und ac_sym c erforderlich C B 11 09 95 revision 1 1 date 1995 09 08 17 51 28 author benecke state Exp Initial revision revision 2 0 1 1 date 1995 11 16 15 49 21 author benecke state Exp lines 20 8 muesste laufen tut es aber nicht KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 143 5 7 2 Wichtige nicht realisierte Funktionen Die Anforderungen an den Prototypen aus Abschnitt 2 7 4 sind erf llt worden Ziel dieser Anforderungen war es einen Prototypen zu spezifizieren der altbekannte Auf gaben aus der Kommunikationsme technik auf Grundlage von Parallelverarbeitung erf llt Bei der Realisierung wurde besonders viel Wert auf die Implementierung der Unterst tzungsfunktionen f r das Konzept der Paketparallelit t gelegt Dieses Vorgehen ist bei der Realisierung eines Prototypen verst ndlich Es m ssen prim r die grundlegenden Funktionen realisiert werden bevor praxisnahen Anforde rungen nachgegangen werden kann Die Erweiterbarkeit und die Skalierbarkeit des Prototypen sind auf Grundlage dieser
115. das Verhalten des Me objektes nicht beeinflussen Insbesondere das zeitliche Verhalten der Zustands nde rungen des Me objektes ist unabh ngig davon ob ein Hardware Monitor angeschlossen ist oder nicht Weitere Vorteile von HW Monitoren HW Monitor sind e Es sind sehr hohe Abtastraten m glich meist um mehrere Gr enordnungen h her als bei vergleichbaren Software Monitoren e Es werden keine Betriebsmittel des untersuchten Systems beansprucht e Es k nnen durch den Einsatz von HW Monitoren kaum Fehler in das zu unter suchende System eingebracht werden e Es sind hardwarenahe Messungen m glich Der Hauptnachteil eines HW Monitors ist da er nur solche Ver nderungen oder Zust nde des Me objektes registrieren kann die durch die Me f hler zug nglich sind 1 4 2 2 Software Monitor Ein Software Monitor ist ein Programm das Teil des Me objektes ist bzw mit dem Me objekt zusammen auf derselben Hardware abl uft vgl Hin86 S 6f Lip88 S 32 Im Gegensatz zum HW Monitor beeinflu t ein Software Monitor SW Monitor i d R das zeitliche Verhalten des Me objektes Wenn man die St rungen des Me objektes durch den SW Monitor bei der Analyse nicht ber cksichtigt kann das zu einer Verf lschung der Me ergebnisse f hren Dies ist der wesentliche Nachteil aller SW Monitore Die Vorteile der SW Monitore sind e Sie sind einfacher realisierbar als HW Monitore e Sie sind leicht ver nderbar erweiterbar e Es
116. den von Nachrichten kom muniziert 5 2 3 4 Thread f r die Ablaufkoordinierung Der Kontroll Thread reagiert im wesentlichen auf interne Nachrichten vgl Ab bildung 5 3 proze spezifische Berechnungen Er koordiniert die Kooperation der anderen T hreads des Prozesses Dazu startet er nicht nur die anderen T hreads im Zuge der Initialisierung sondern initialisiert gemeinsame Variablen und teilt interne Ein berlaufen der Empfangswarteschlange auf P6 bedeutet einen Datenverlust Dateneinheiten die aufgrund einer vollen Warteschlange nur teilweise oder gar nicht empfangen werden konnten stehen f r die Messung nicht zur Verf gung Im schlimmsten Fall sind dadurch die Me ergebnisse falsch Eine interne Funktion geh rt zum aktuellen Proze Eine externe Funktion geh rt zu einem ande ren Proze Aufgrund der oben diskutierten Plazierung maximal eines Prozesses auf jeden Transputer ist eine externe Funktion auch immer auf einem anderen Prozessor T Ausnahmsweise wird diesmal mit Monitor eine Funktion bezeichnet die durch eine Semaphore gesch tzt wird so da nur ein Thread zur Zeit den Funktionscode ausf hren kann KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 100 Kommunikationskan le den anderen Threads zu Ein Beispiel ist die Reaktion auf die Status Anforderung Diese Nachricht wird typischerweise vom Hostrechner mit einer Broadcast Nachricht an alle Prozesse gesendet
117. der auch Idle 17Die Abk rzung steht f r das Transmission Control Protocol aus der TCP IP Protokollfamilie 18Streufunktionen Hash Funktionen erm glichen einen schnellen Zugriff auf unsortierte Listenele mente hier Verbindungskontexte Ein Vergleich verschiedener Streufunktionen wird beispielsweise in ASU88 S 532ff gegeben Detaillierte Realisierungsvorschl ge findet man in Ho190 S 715ff KAPITEL 4 ENTWURF DES MESSWERKZEUGES 88 Analyse der Dateneinheit entscheiden kann welcher Proze die Verbindung ver waltet Die Verbindungsmanagement Funktionen geh ren in die Kategorie der Unterst tzungs funktionen In diesem Fall mu die parallele Analyse unterst tzt werden um Analyse ergebnisse berechnen zu k nnen die in direktem Zusammenhang mit einer Verbindung durch verbindungsorientierte Protokolle stehen Beim Prototyp wird auf die Realisierung der Verbindungsmanagement Funktionen verzichtet Falls sich das Paradigma der Paketparallelit t bei der Analyse bew hrt kann bei Bedarf die Realisierung dieser Funktionen nachgeholt werden 4 5 3 Entwurf der Kommunikationsunterst tzung f r die Hostrech ner Transputer Kommunikation Die Kommunikation der Transputer untereinander wird durch die Transputerlinks abgewickelt Die Ansteuerung der Transputerlinks ist trivial Die Unterst tzung der Interproze und der Interprozessor Kommunikation geht bis auf die Maschinenspra chen Ebene der Tr
118. der entsteht um die Analyse auf ein weiteres zu untersuchendes Protokoll auszudehnen KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 56 Da ein konsequenter modularer Aufbau der Implementierung eine Erweiterung erleichtert w re eine andere Bewertungsm glichkeit f r die Erweiterbarkeit ob das jeweilige Konzept eine funktionale Gruppierung zu Moduln zul t vgl Ab schnitt 3 1 Zus tzlich kann man sich fragen ob bzw wann das jeweilige Konzept die Er weiterung der Hardware erfordert K nnen neue Funktionen als Prozesse auf die vorhandenen Prozessoren plaziert werden oder m ssen f r neue Funktio nen weitere Prozessoren angeschafft werden Wie gro ist der Aufwand f r die Rekonfiguration bei Hardware Erweiterungen Leistungsf higkeit A priori mu eine Realisierung die Benutzeranforderungen erf llen k nnen Aus den funktionalen Anforderungen ergeben sich dann direkt Anforderungen an die Leistungsf higkeit Beispielsweise ist die maximale Anzahl zu analysierender Dateneinheiten pro Sekunde eine dieser Leistungsanforderun gen die sich direkt aus den zugrundeliegenden Netzeigenschaften ergeben Bei Anpassungen und Erweiterungen an andere Netze in Zukunft Hochgeschwindig keitsnetze steigen die Anforderungen an die Leistungsf higkeit Das jeweilige Konzept sollte auch zuk nftigen Leistungsanforderungen gen gen mit anderen Worten das Konzept mu skalierbar sein vgl Abschnitt 2 7 2 und 2 7 3 Vertr glichkeit mit de
119. die Filterfunktionen ausge f hrt werden Die Entscheidung das Filtern von den Pakettr gern zu trennen vgl Abschnitt 4 4 5 1 l t sich dadurch begr nden da der Prozessor PDEV allein durch das Zwischenspeichern von Rohdaten kaum ausgelastet wird Au erdem wird durch das fr hzeitige Filtern die Last der Verteilungsfunktionen die notwendigerweise von PDEV ausgef hrt werden verringert Sie brauchen nur noch die Dateneinheiten KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 97 auf die Pakettr ger zu verteilen die die Filterfunktionen briglassen 5 2 Verfeinerung der Prozesse In diesem Abschnitt werden die Prozesse aus Abbildung 5 2 verfeinert Die Grundlage f r diese Verfeinerung bildet ein allgemeines Proze Template das die Grobstruktur aller Prozesse darstellt die auf den Transputern ausgef hrt werden vgl Abschnitt 5 2 1 5 2 1 Ein allgemeines Proze Template Jeder Proze mu in der Lage sein Nachrichten zu senden und zu empfangen Die daf r notwendigen Vermittlungsfunktionen wurden in Abschnitt 4 5 1 entworfen Es wurden au erdem die Vorteile diskutiert Sende und Empfangsfunktionen voneinander und von den verbleibenden Funktionen zu trennen Es liegt nahe diese drei Funktions klassen als eigenst ndige Threads zu realisieren Um das ineffiziente Kopieren von Nachrichten zu vermeiden sollen alle Threads Zugriff auf einen gemeinsamen Ring puffer haben Die allgemeine Str
120. e entsprechender Fehlermeldungen zust ndig ist sollen Filterdefinitionen auch auf dem Hostrechner in Programmcode bersetzt werden Eine weitere wichtige Begr ndung f r diese Entscheidung ist da sowohl die syntaktische als auch die semantische berpr fung der Filterdefinitionen von Funktionen bernommen werden k nnen die auch die berpr fung der Eingaben in der Kommandozeile vgl Abschnitt 4 4 4 1 durchf hren Diese Funktionen k nnen so in einem Modul f r den Hostrechner zu sammengefa t werden Au erdem wurde entschieden Zwischencode f r einen abstrakten Prozessor zu ge nerieren da dies weniger aufwendig erscheint als die direkte Maschinencodegenerie rung f r Transputer Ein Nachteil von P Code ist der langsamere Ablauf da dieser P Code durch den abstrakten Prozessor interpretiert werden mu 4 5 Entwurf der unterst tzenden Funktionen Die unterst tzenden Funktionen stellen Dienste f r die essentiellen Funktionen zur Verf gung Alle unterst tzenden Funktionen k nnten alternativ in die essentiellen Funktionen integriert werden Die Programmquellen sollten jedoch m glichst modu lar erstellt werden Durch eine Aufteilung in essentielle Funktionen und Funktionen zur Unterst tzung sind Erweiterungen leichter m glich Weitere Gr nde f r diese Einteilung werden in den folgenden Abschnitten genannt 4 5 1 Entwurf von Vermittlungsfunktionen und Verteilungsfunktio nen Im allgemeinen Fall gi
121. e Erkennen eingebetteter Dateneinheiten und Identifizieren des verwendeten Pro tokolls e Analysieren der Dateneinheit e Speichern der Analyseergebnisse in einem einheitlichen Format e Aufrufen der Analysefunktion f r eine erkannte eingebettete Dateneinheit e Berechnen lokaler Statistiken zur Unterst tzung des globalen Statistikprozesses KAPITEL A ENTWURF DES MESSWERKZEUGES 79 4 4 3 Entwurf der essentiellen Funktionen f r die globale Statistik Bei dem Konzept der Paketparallelit t fallen Analysedaten typischerweise dezentral bei den verschiedenen Pakettr gerprozessen an Zwar kann jeder Pakettr ger lokale Statistiken beispielsweise zur Anzahl der empfangenen Dateneinheiten eines bestimm ten Typs f hren die globale Statistik mu jedoch von einem Proze bernommen wer den der Zugriff auf die Analyseergebnisse aller Pakettr ger hat z B Gesamtanzahl der empfangenen Dateneinheiten eines Typs Im allgemeinen Fall bei einer gro en Anzahl von Pakettr gerprozessen kann es auch notwendig werden mehrere Prozesse f r die globale Statistik vorzusehen Die Prozesse k nnten hierarchisch angeordnet werden Auf der untersten Hierarchiestufe werden die Analyseergebnisse von den Pakettr gern weiterverarbeitet Auf h heren Hierarchiestufen werden diese Zwischenergebnisse erneut geb ndelt Der Prototyp ben tigt einen Proze f r die globale Statistik Die einzige Aufgabe der globalen Statistik besteht darin die Standardauswertu
122. e Hardware an HSN anpa bar jedoch nicht durch weitere Prozessoren Die Analyse erfolgt beim Prototypen grunds tzlich in Echtzeit SNIFFER analy siert die Dateneinheiten hingegen off line vgl Abschnitt 1 4 5 In einem Trace Buffer werden Dateneinheiten gesammelt und nach Abschlu der Rohdatenerfassung analysiert Im Kontext von HSN ist dieses Vorgehen nicht zu empfehlen da hierf r enorme Betriebsmittel f r die Zwischenspeicherung der Rohdaten ben tigt werden Der Me f hler ist die Schnittstelle zum Kommunikationssystem In diesem Fall eine Ethernet Schnittstelle 50Der Prototyp k nnte durch weitere Transputer noch mehr Pakettr ger parallel einsetzen Kapitel 6 Arbeiten mit dem Prototypen In diesem Kapitel soll anhand von Beispielen das Arbeiten mit dem Prototypen erkl rt werden Dieses Kapitel ist sozusagen das Benutzerhandbuch des Me werkzeuges Aus zeitlichen Beschr nkungen der Diplomarbeit und Restriktionen der Hardware ergeben sich typische Engp sse beim Einsatz des Prototypen Diese Engp sse werden zusammen mit L sungsvorschl gen zu ihrer Beseitigung in Kapitel 7 aufgezeigt 6 1 Die Benutzerschnittstelle des Prototypen Der Hostrechner Proze kann durch Eingabe des Befehls pmfrontend unter einem OS 2 Befehlsinterpreter gestartet werden Alternativ kann ein Icon des Programms mit der Maus angeklickt werden Vorzuziehen ist jedoch das Starten ber den Befehl sinterprete
123. e die entsprechende Analysefunktion mit einem Zeiger auf den UDP Benutzerdatenbereich aufgerufen werden KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 119 5 3 2 7 Realisierung einer Analysefunktion f r das Transmission Control Protocol Das Transmission Control Protocol TCP stellt einen zuverl ssigen verbindungs orientierten Dienst zur Verf gung Es bietet Flu kontrollmechanismen und gestattet es den beiden Kommunikationspartnern festzulegen wieviele Daten ohne Best tigung vorausgesendet werden d rfen Au erdem erm glicht TCP eine Unterscheidung zwischen normalen Daten und Vorrangdaten die unmittelbar zu bearbeiten sind Bei den normalen Daten sorgt TCP au erdem daf r da diese in der richtigen Reihenfolge an den Empf nger wei tergeleitet werden Aus dieser Funktionsvielfalt ergibt sich die komplexe Struktur der TCP Datenein heiten vgl Abbildung 5 15 Quell Port Senken Port Sequenz Nummer SEQ Best tigungs Nummer ACK DO res KF Fenster Zeiger auf Ende der Pr fsumme Vorrang Daten T f Optionen eventuell F llzeichen l SEET l DO Daten Offset Kopfl nge 4 Bit l Daten i res reserviert KF Kontroll Flaggen 6 Bit Abbildung 5 15 TCP Dateneinheit Die Analysefunktion f r TCP Dateneinheiten berechnet die folgenden Werte e L ngenangaben zur Gesamtl nge Datenl nge und Optionenl nge e Wert der Sequenznummer
124. e f r quali tative und quantitative Restriktionen sind e Proze j darf ausschlie lich auf Prozessor x plaziert werden qualitativ e Die Speicheranforderungen eines Prozesses j darf auf Prozessor x zu keinem Zeit punkt gr er als z MByte sein quantitativ e Die mittlere Antwortzeit eines Prozesses des Typs j soll kleiner als m Millisekun den sein quantitativ Kombiniert man die Optimierung mit Restriktionen so erh lt man eine bedingte Optimierung Eine Optimierung ohne Restriktionen ist unbedingt Abbildung 3 2 zeigt eine m gliche Klassifizierung der Zuordnungsziele Zuordnungsziel Restriktion r qualitativ quantitativ Zelfunkton und Be Restriktion oder KE mi Optimierung unbedingt L pe Zielfunktion max bedingt lt TT einen HI Restriktion max oder Abbildung 3 2 Klassifikation der Zuordnungsziele vgl Hei94 S 90 Es wird nur noch auf den allgemeinen Fall der Zuordnung von Prozessen zu Prozessoren einge gangen da Programme als Menge von kooperierenden Prozessen verstanden werden KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 42 3 1 4 Zeitpunkt der Zuordnung Der Zeitpunkt der Zuordnung von Prozessen zu Prozessoren ist nicht fest vorgegeben sondern f llt in eine der folgenden Kategorien 3 1 4 1 Manuelle Zuordnung Bei der manuellen Zuordnung entscheidet der Programmierer die Zuordnung der Pro zesse eines Programms zu den Prozessoren Diese Methode ist e hardwares
125. e setzen die ber einen Link seriell bertragenen Datenpakete vgl Abbildung 3 6 in ein Byte lange W rter um Diese Byte Sequenz kann der PC auslesen Indirekt k nnten die Transputer auch ber eine Schnittstelle des Hostrechners auf ein Kommu nikationssystem zugreifen Effizienter ist jedoch der direkte Zugriff KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 52 Eine entsprechende Umsetzung von Ein Byte W rtern in Link konforme Datenpa kete erm glicht es dem PC Daten an die Transputer zu versenden F r diese bidirek tionale PC Transputer Kommunikation werden von den TBs vier Ein Ausgabeadres sen des PC belegt Zwei dieser Adressen dienen als Datentore f r die Ein Byte W rter Es gibt jeweils eine Adresse f r jede bertragungsrichtung ber die beiden anderen Adressen hat der PC Zugriff auf Statusinformationen die anzeigen ob der Transputer bereit ist weitere Daten zu empfangen bzw weitere Daten zu senden Durch diesen Mechanismus ist ein einfacher Abfragebetrieb m glich Zus tzlich kann man Daten vom Transputer interrupt gesteuert empfangen Dadurch entf llt das st ndige Abfragen der Statusinformation um Nachrichten vom Transputer zu empfangen 3 2 1 7 Gesamtarchitektur der Hardware Die Hostrechner werden nicht gesondert dargestellt da es sich um weit verbreitete IBM kompatible PCs handelt Diese PCs sind beliebig gegen gleichwertige oder bessere Hardware austauschbar Die Mindestanforderun
126. e zu erwarten sind Bit2 1 Das bedeutet alle Fragmente eines Datagramms mit Ausnahme des letzten m ssen das zweite Bit setzen Das letzte Fragment mu das zweite Bit der Flaggen zur cksetzen ber die Gesamtl nge GS der Fragmentposition und den Flaggen kann bestimmt werden ob ein Datagramm vollst ndig wieder zusammengesetzt wurde Das Bit0 wird nicht benutzt und mu immer den Wert null 0 haben vgl RFC 791 S 13 5 Das Feld Lebenszeit LZ gibt an wieviele Sekunden ein Datagramm in einem Internetzwerk vermittelt werden darf vgl Com91 S 99 Jeder Vermittlungs rechner ist angewiesen dieses Wert um mindestens eins 1 zu vermindern und das Datagramm zu vernichten falls der Wert danach null 0 ist 6 Das Feld Protokoll PR identifiziert analog zum Ethernet Typ Feld das einge bettete Protokoll Aus der Sicht eines h heren Protokolls ist somit auch IP ein sich selbst identifizierendes Protokoll 7 Das Feld Kopfpr fsumme KP enth lt die Pr fsumme ber den gesamten Kopf 17 Bei Ethernet Frames ist die MTU 1500 Byte 18Zur Berechnung nimmt man an da die Pr fsumme den Wert 000016 hat KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 116 8 Die Felder Senderadresse SA und Empf ngeradresse EA enthalten IP Num mern 9 Die optionalen Optionen sind komplex strukturiert Sie erm glichen die Funk tionalisierung von Datagrammen f r einfache Netzmanagement Aufgaben
127. echnen der Analyseergebnisse Die Analyseergebnisse werden in einer proto kollspezifischen Struktur ab der als Parameter bergebenen Adresse f r die Ana lysedaten gespeichert Auf diese protokollspezifische Struktur wird beispielsweise von den weiter unten beschriebenen Verwaltungsfunktionen f r den Datenexport vgl Abschnitt 5 3 4 3 zugegriffen e Berechnen lokaler Statistiken Die lokalen Statistiken werden an die globalen Statistikfunktionen weitergeleitet vgl Abschnitt 5 3 3 der Ethernet Schnittstelle waren jedoch nur f r einen vergleichbaren Compiler der Firma INMOS vorhanden KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 108 Erkennen eines eingebetteten Protokolls Unabh ngig davon ob die Analysefunk tion Analyseergebnisse berechnet mu sie eine eventuell eingebettete Datenein heit eines anderen Protokolls erkennen Wie weiter oben dargestellt wurde sind die daf r notwendigen Informationen protokollspezifisch vgl Abbildung 4 3 Aufrufen der Analysefunktion des erkannten Protokolls Dies geschieht immer wenn ein eingebettetes Protokoll identifiziert wurde Ist kein weiteres Protokoll eingebettet oder handelt es sich um ein unbekanntes Protokoll entf llt dieser Schritt Als Parameter wird der Analysefunktion des eingebetteten Protokolls ein Zei ger auf die zu analysierenden Rohdaten bergeben Dazu mu die aufrufende Analysefunktion einen Zeiger auf den Datenbereich der jeweiligen Dateneinheit berechnen Der zwe
128. echnik wird in RFC 1470 gegeben Der dort vorgeschlagenen Klassifikation folgend m te man den Prototy pen in die Kategorien Analyser Benchmark Traffic Ethernet IP Eavesdrop 08 2 Standanlone Free einordnen Die Datenerfassung und die Funktionen des Prototypen zur Protokollierung von Dateneinheiten sind vergleichbar mit bekannten Werkzeugen wie beispielsweise SNIF 4Dje Bthernet Schnittstelle des Me werkzeuges verf gt ber eine eigene eindeutige Adresse 45Neben der Rohdatenerfassung k nnten optional Statistiken erstellt werden 46 Beispielsweise eine drohende S ttigung des Kommunikationssystems A Beispielsweise durch Aktivieren von Flu kontrollmechanismen zur S ttigungskontrolle 48In RFC 1470 werden Hardware Software Programme und Funktionsbibliotheken und hybride Realisierungen f r die Kommunikationsme technik als Werkzeuge bezeichnet KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 145 FER vgl RFC 1470 S 136ff Beide Werkzeuge sind Hardware Monitore die die Dateneinheiten des Netzes auswerten an das sie angeschlossen sind Der Funktions umfang des kommerziellen Werkzeuges bertrifft den hier realisierten Prototypen bei weitem Ein weiterer Unterschied besteht in der Granularit t der Parallelverarbeitung SNIFFER verf gt neben der Schnittstelle zum Netz nur ber eine weitere Kompo nente die parallel zum Hostrechner arbeitet vgl Hau88 S 379 Eine solche Architektur ist nur durch schneller
129. eder Teilalgorithmus wird auf einer Funktionseinheit einem Prozessor ausgef hrt F r den Programmcode des Algorithmus und die Datenstrukturen auf de nen er arbeitet mu Speicherplatz in der Umgebung zur Verf gung stehen Die Ausf hrung des Programmcodes durch den Thread ist die Abarbeitung des Teilalgorithmus Somit repr sentieren Thread und Umgebung den Teilalgorithmus als Proze auf einem Prozessor Das Hauptargument wenn m glich Threads zu verwenden beruht auf der Beobachtung da ein Thread zu Tread Wechsel innerhalb einer Umgebung weniger Overhead produziert als ein Proze wechsel Die wichtigsten Betriebsmittel des Transputers sind neben der Prozessorzeit die Transputerlinks und der physikalische Speicher KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 95 Entscheidend an der Paketparallelit t ist jedoch der Flu der Dateneinheiten durch die Pakettr ger Daher wird f r jeden Proze eine graphische Darstellung des Daten flusses durch die Funktionen bzw Threads gegeben Besonders geeignet f r eine Darstellung des Datenflusses durch Funktionseinheiten sind die sogenannten Daten flu diagramme vgl You89 Sie erm glichen auf Grundlage weniger graphischer Symbole die Darstellung nebenl ufiger Funktionseinheiten Speicher und der auszu tauschenden Daten Die graphischen Symbole der Datenflu diagramme In Abbildung 5 1 sind alle graphischen Symbole aufgef hrt die in
130. edoch eleganter und aufwands rmer da die Pakettr ger durch die TIMER Nachricht synchronisiert werden Ihre Reaktion auf diese Nachricht kann quasi gleichzeitig erfolgen Bei auto nomen Zeitgebern auf jedem Pakettr ger m te man Mechanismen zum Abgleichen der Uhren realisieren Das Datenflu diagramm des Prozesses ist in Abbildung 5 5 gegeben KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 101 zu PPAKET 3 zu PPAKET 4 Uhrzeit gefilterte Filtern Zeitstempel setzen Vermittlungsinfos setzen Frames Zeitgene rator 2 2 gefilterte Uhrzeit Frames Ethernet Frames Uhrzeit netznahe Statistik Ringpuffer zu PPAKET 3 zu PPAKET 4 d Empf nger Filter von 3 gt 21 lt Filter von 4 netznahe Statistik Ethernet Frames von 1 von 1 Abbildung 5 5 Datenflu diagramm von PDEV 5 2 4 Der Proze PPAKET Bei PPAKET handelt es sich um den bereits mehrfach erw hnten Pakettr ger Je weils eine Instanz dieses Prozesses wird auf P3 und P4 plaziert Es handelt sich um exakt gleichartige Prozesse die sich lediglich in der Auswahl ihres Eintrags aus der Vermittlungstabelle vgl Abschnitt 4 5 1 unterscheiden W hrend ein Proze Nachrichten gegebenenfalls von Pl und P2 an P5 und P6 weiterleitet vermittelt der andere die Nachrichten in die entgegengesetzte Richtung Neben den obligatorischen Threads
131. ehlte Protokolle Ethernet ARP RARP IP UDP TCP ICMP ZEIT ms 1168 EVENT Nr 91 ETH laenge 142 SA 00 00 0c 0c 22 50 RA 08 00 20 20 ab 39 IP IP laenge 124 Opt 0 SA 134 100 9 61 RA 134 100 15 1 IP Routine Normal_Delay Normal_Throughput Normal_Reliability IP Protokoll UDP UDP laenge 104 Source Port 2049 Dest Port 1020 Gs handelt sich hierbei im wesentlichen um den Vorgang des Protokollierens KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 125 ZEIT ms 6138 EVENT Nr 358 ETH laenge 82 SA 00 00 0c 0c 22 50 RA 01 00 5e 00 00 05 IP IP laenge 64 Opt 0 SA 134 100 15 250 RA 224 0 0 5 IP Internetwork Control Normal_Delay Normal_Throughput Normal_Reliability IP Protokoll OSPFIGP ZEIT ms 6146 EVENT Nr 359 ETH laenge 64 SA 00 00 0c 0c 22 50 RA 09 00 2b 01 00 01 UNBEKANNT ZEIT ms 6248 EVENT Nr 360 ETH laenge 64 SA 00 80 d3 a0 72 38 RA 00 00 0c 0c 22 50 IP IP laenge 40 Opt 0 SA 134 100 15 82 RA 134 100 9 61 IP Routine Normal_Delay Normal_Throughput Normal_Reliability IP Protokoll TCP TCP laenge 20 Opt 0 SP 1713 DP 43049 TCP SEQ 318280796 ACK 0 TCP FLAGS FIN RST 5 3 4 4 Realisierung eines maschinennahen Datenexports Anforderung an diese Unterst tzungsfunktion ist es die Analysedaten so aufzuberei ten da ein externes Werkzeug effizient darauf zugreifen kann Da es sich bei diesen We
132. ehr als n Prozessoren vorhanden k nnen die brigen Prozessoren nicht f r die Protokollanalyse eingesetzt werden Die ge ringe Granularit t kann eventuell durch Kombination mit dem Konzept der Sende Empfangspipeline verbessert werden Damit erh ht sich jedoch die protokollabh ngige Interproze kommunikation s o Eine wesentlich feinere Granularit t l t sich mit dem Protokollfunktions Konzept erreichen Zur Leistungsf higkeit ist noch anzumerken da eine unausgewogene Pipeline un terschiedliche Verarbeitungszeiten in den verschiedenen Pipelinestufen zu einer sub optimalen Prozessorauslastung f hrt da einige Prozessoren vor anderen fertig wer den Diese Unausgewogenheit ergibt sich bei einer Protokollpipeline zwangsl ufig da die Protokolle mit zunehmender Protokollschicht komplexer werden und somit der Analyse und Rechenaufwand ebenfalls zunimmt Protokollfunktionen Verbindungs parallelit t und Paketparallelit t vermeiden diesen Nachteil 3 3 4 2 Bewertung der Sende und Empfangspipeline Dieses Konzept ist hnlich leicht zu realisieren wie das Konzept der Protokollfunktio nen da schon in sequentiellen Realisierungen meist zwischen Sende und Empfangs funktionen unterschieden wird Eine Anpassung ist dementsprechend leicht Dieses Konzept sollte jedoch nur in Kombination mit einer Schichtenpipeline verwendet wer den um eine m glichst feine Granularit t zu erreichen Gegen ber einer reinen Schichtenpipeline ist di
133. eim Slicing werden die Dateneinheiten nicht vollst ndig an die Analyse weitergegeben sondern nur eine vom Benutzer festzulegende An zahl Byte Im Kontext von HSN l t sich die Last durch Rohdaten im Werkzeug durch Slicing deutlich reduzieren Werden die oben genannten Funktionen realisiert w re das Werkzeug durchaus praxis tauglich Die Funktionen m ten in Zusammenarbeit mit den potentiellen Benutzern 43 Beispielsweise k nnte der Benutzer die Analyse von UDP Dateneinheiten verlangen Bei einem Ethernet basierten Werkzeug w rden durch Slicing nur die ersten 50 Byte eines Ethernet Frames an die Analyse weitergegeben werden Das entspricht 22 Byte Ethernet Kopf 20 Byte IP Kopf 8 Byte UDP Kopf KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 144 entwickelt werden 5 7 3 Erweiterungsvorschl ge Prim r sollten die im letzten Abschnitt 5 7 2 genannten Funktionen realisiert wer den Dar ber hinaus bietet sich die Integration des Me werkzeuges in ein Netzwerk Managementsystem NMS an Durch eine Integration des Me werkzeugen in ein NMS k nnte man die Messungen automatisieren und unter die Kontrolle des NMS stellen Vorschl ge f r die Architektur eines derartigen NMS sind beispielsweise in MSS93 Eine M glichkeit diese Integration zu erreichen w re die bertragung von Kom mandos an das Me werkzeug ber das Netz Durch adressieren des Me werkzeuges k nnte die Interpretation der Dateneinheit als
134. einem Datenflu diagramm vorkommen k nnen Wesentlich hierbei sind die folgenden Symbole e Funktionen Prozesse und Funktionseinheiten teilen sich dasselbe Symbol Die entsprechenden Symbole stellen aktive Komponenten dar die die Daten verarbei ten und weiterleiten Neben einem Namen werden diese Symbole zus tzlich mit einer Nummer markiert die die gegenw rtige Hierarchiestufe ausdr ckt Hat eine Funktion auf der obersten Hierarchiestufe die Nummer x so sind beispielsweise x y und z z x y z N Verfeinerungen dieser Funktion auf der darunterliegen den Hierarchiestufe e Datenflu Der durch Pfeile dargestellte Datenflu beschreibt Daten die von einer aktiven Komponente zu einer anderen bertragen werden bzw von oder zu einem Speicher bertragen werden Speicher Speicher lagern Daten bis sie von einer aktiven Komponente verarbei tet werden Terminatoren Terminatoren sind die Schnittstellen zum modellierten System Terminatoren und Wechselwirkungen der Terminatoren untereinander werden nicht modelliert ber Terminatoren werden Daten oder Signale an das System abgegeben bzw vom System an die Umgebung abgegeben Kontrollkomponenten und Kontrollflu Kontrollkomponenten senden bzw emp fangen Signale Durch Kontrollkomponenten wird im wesentlichen das zeitliche Verhalten des Modells beschrieben F r eine vertiefende Darstellung vgl MP86 oder You89 N aktive Datenflu Kontrollkomponente J Komponente
135. ellen mu i d R das gleiche Experiment mehrmals durchgef hrt werden um die statistischen Berechnungen abzusichern Der gew nschte Abstraktionsgrad Die Entscheidung auf welchem Abstraktionsgrad eine Analyse durchgef hrt werden soll ist ein weiteres Kriterium f r die Wahl der Methode Meist l t sich ein ma thematisches Modell nicht mit dem gleichen Detaillierungsgrad aufstellen wie ein ver gleichbares Modell f r ein Simulationsexperiment Weitere Faktoren f r oder gegen die Wahl einer bestimmten Analysemethode wer den in Jai91 S 30ff diskutiert 1 3 Messungen am Kommunikationssystem Direkte Analysen am Kommunikationssystem beginnen mit dem Erheben von Daten Neben statischen Angaben zum Kommunikationssystem wie z B maximale bertra gungsgeschwindigkeit einer Netzkomponente sind dies vor allem Me daten die dyna misch durch Messungen am Kommunikationssystem anfallen In diesem Abschnitt soll dargestellt werden warum Messungen erforderlich sind vgl Abschnitt 1 3 1 und welche Werkzeuge man f r Messungen an Kommunika tionssystemen einsetzt Im folgenden Abschnitt 1 4 wird eine Klassifikation dieser Werkzeuge vorgestellt 1 3 1 Die Notwendigkeit f r Messungen am Kommunikationssystem F r Netzverwalter ergeben sich drei gro e Aufgabenbereiche w hrend des laufenden Betriebes bei denen Messungen unverzichtbar sind Dies sind e Erkennen von Fehlern e Erkennen der Belastung des Kommunikationssystems e Erke
136. en vom Eventkanal bindet den lesenden Proze an den Interrupt des Transputers 3 2 1 3 Zeitgeberlogik Die Transputer verf gen ber zwei unabh ngige Zeitgeber mit einer Aufl sung von Jus und 64us Alle Prozesse k nnen diese Zeitgeber abfragen Implementiert sind sie als 32 Bit Register Alle 64us bzw lus werden diese Register um 1 erh ht Ist die gr te positive Zahl in der Abbildung 3 5 als MAX_POS_INT bezeichnet erreicht wird Ein Zeitoffset ist eine positive Zahl die die Anzahl der n tigen Erh hungen des Zeitgeber Re gisters s u angibt In Abh ngigkeit von der Aufl sung des Zeitgebers betr gt ein Zeitoffset von 1 entweder 1us oder 64us KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 48 bei der kleinsten negativen Zahl MIN_NEG_INT fortgefahren Der Zahlenbereich wird also zyklisch durchlaufen Ein Durchlauf dauert Jus 23 1 193046471h 1hllmin35sec Bei 64us verl ngert sich ein solcher Durchlauf entsprechend auf 3 Tage 4h 21 min 18 sec MIN_NEG_INT MAX_POS_INT 1 01 Abbildung 3 5 Wertebereich der Transputer Zeitgeber vgl Ebe93 Seite 454 3 2 1 4 Link Schnittstellen Jeder Transputer verf gt ber vier unabh ngige Link Schnittstellen kurz Links die eine Vernetzung mit anderen Transputern erlauben Bei der Kommunikation ber die Links wird die CPU nicht belastet da jeder Link ber eine eigene Direct Memory Access DMA Schnittstelle verf gt also eigenst ndig
137. en Durchsatz bei der IP und UDP Analyse Die UDP Analyse ist schneller als die IP und Ethernet Analyse obwohl der Erkennungsaufwand bei UDP am gr ten ist Die deutlichen Unterschiede im Grenzdurchsatz zwischen IP und UDP Analyse einerseits und Ethernet Analyse andererseits lassen sich nur anhand der Programmquellen f r die Analysefunktionen erkl ren Vermutlich wird die ausschlie lich bei der Ethernet Analysefunktion verwen dete switch Kontrollanweisung vgl KR92 S 220 vom bersetzer sehr schlecht bersetzt Die Analysefunktionen f r Ethernet Dateneinheiten sollte optimiert wer den Aussagekr ftiger als dieser Grenzdurchsatz ist jedoch die Beobachtung da bei allen bisher durchgef hrten Messungen insbesondere bei denen die zur Identifizie rung des prim ren und sekund ren Engpa f hrten alle Dateneinheiten von einem Pakettr ger rechtzeitig ausgewertet werden konnten 107ur Zeit bedeutet das Analysedaten f r Ethernet IP und UDP zu generieren Durch ndern der Vermittlungsinformationen auf PDEV kann man alle Dateneinheiten zu einem Pakettr ger leiten KAPITEL 7 LEISTUNGSBEWERTUNG DES PROTOTYPEN 171 Der Lastgenerator der bei diesen Messungen eingesetzt wurde konnte maximal 1000 Dateneinheiten pro Sekunde generieren Das entspricht nicht einmal 20 des Grenzdurchsatzes bei den rechenintensivsten Auftr gen an einem Pakettr ger s o Betrachtet man die beiden Pakettr ger der Konfiguration als e
138. en Protokollanalyse Die Paketparallelit t vgl Abschnitt 3 3 3 5 hat sich bei den durchgef hrten Messungen bew hrt Es zeigte sich da die Schnittstelle zum Ethernet vor der parallelen Protokollanalyse zum Engpa wird Der Grenzdurchsatz Zumindest nach Meinung des Autors handelt es sich dabei um die wichtigsten Erweiterungen KAPITEL 8 ZUSAMMENFASSUNG UND AUSBLICK 176 eines Pakettr gers wurde bei Messungen in einem typischen Ethernet Segment nicht einmal ann hernd erreicht Die Messungen f r die Leistungsbewertung haben aber auch gezeigt da der Proto typ noch verbessert werden kann Beispielsweise sollten die Filterfunktionen beschleu nigt werden Au erdem deuten die starken Unterschiede in den Grenzdurchs tzen bei verschiedenen Analyseauftr gen an die Pakettr ger daraufhin da die Analysefunk tion f r Ethernet Frames verbessert werden kann vgl Abbildung 7 6 Ein weiteres wichtiges Ergebnis ist die Erkenntnis da Prozesse und Funktionen die auf Grundlage von Templates realisiert werden den Entwicklungsaufwand deut lich reduzieren Die manuelle Zuordnung von Prozessen zu Prozessoren wird einfacher wenn man gleichartige Prozesse auf Prozessoren plazieren kann Die Entwicklung des Proze Templates auf Grundlage einer allgemeinen Nachrichtenvermittlung war da bei der wesentliche Abstraktionsschritt vgl Abschnitt 5 2 1 Die Leistungsprognose im Abschnitt 7 3 2 hat schlie lich gezeigt da die
139. entweder vernichtet herausgefiltert oder als zu analysierende Dateneinheit mit einem Zeitstempel und einer Ereignisnummer an die Verteilungs funktion weitergeleitet 5 2 3 2 Thread zum Empfangen der Dateneinheiten Der Empfang von Dateneinheiten wird durch einen eigenen Thread realisiert der als einer von zwei Threads auf hoher Priorit t abl uft Durch die hohe Priorit t wird dieser Thread sofort vom Prozessor ausgef hrt wenn eine Dateneinheit von der Roh datenerfassung gesendet wird Dieses Vorgehen ist notwendig um nach M glichkeit ein berlaufen der viel zu klein dimensionierten Empfangswarteschlange auf P6 zu vermeiden Die empfangenen Dateneinheiten werden in einer als Ringpuffer organi sierten Warteschlange gespeichert 5 2 3 3 Threads f r den Nachrichtenaustausch Die Vermittlungsfunktionen vgl Abschnitt 4 5 1 werden auf vier Threads aufge teilt Ein Thread ist f r den Empfang von Nachrichten zust ndig die ebenfalls in einem Ringpuffer abgelegt werden Ein weiterer Thread bernimmt das Vermitteln der Nachrichten Nachrichten die Daten f r eine interne Funktion bermitteln wer den von dem dritten Thread dem Kontroll Thread verarbeitet Unabh ngig davon kann jeder Thread Nachrichten versenden Die daf r realisierte Funktion mu te als Monitor implementiert werden da sie ber einen internen Kanal in diesem Fall das zu sch tzende Betriebsmittel mit dem Thread zum Sen
140. er Proze nur die zur Ausf h rung dieses Prozesses notwendigen Betriebssystemprozesse gestartet werden Durch Starten weiterer Prozesse auf dem Hostrechner verringert sich der Durchsatz an der Schnittstelle zum Transputerboard Daran ndert auch die Vergabe von Priorit ten nichts da OS 2 das Starten weiterer Anwendungen auch dann erlaubt wenn bereits Prozesse auf h chster Priorit t ablaufen KAPITEL 7 LEISTUNGSBEWERTUNG DES PROTOTYPEN 165 7 1 4 Der sekund re Engpa Beseitigt man den prim ren Engpa zeigt sich da der sekund re Engpa der Netz Server ist Eine obere Schranke f r die Auslastung des Ethernet Segmentes ber einen l ngeren Zeitraum gt 10 Sekunden bei der der Netz Server alle Dateneinhei ten ohne Verluste empfangen kann ist 5 Megabit s also 50 Wird diese Schranke berschritten gibt der Prototyp die Warnung an den Benutzer aus Der Grenzdurchsatz bei dem alle Dateneinheiten vom Netz Server empfangen werden k nnen ist abh ngig von der L nge der Dateneinheiten Dies ist in Abbildung 7 3 dargestellt Je kleiner die Dateneinheiten sind desto mehr k nnen in einer Sekunde verarbeitet werden Es k nnen 1000 Ethernet Frames mit einer Brutto L nge von 310 Byte pro Sekunde empfangen werden Bei der maximalen L nge eines Ethernet Frames von 1526 Byte konnten nur noch 275 Dateneinheiten pro Sekunde ohne Verluste empfangen werden Grenzdurchsatz am Netz
141. er Zugriff der PCs auf die Transputer wird in Abschnitt 3 2 1 6 dargestellt Zusammenfassend wird in Abschnitt 3 2 1 7 die Gesamtarchitektur der eingesetz ten HW dargestellt Diese Architektur ist die Grundlage f r die Realisierung des Me werkzeuges 3 2 1 1 Transputer Bei den Transputern handelt es sich um eine Mikroprozessorfamilie der Firma INMOS Ltd Inm88 Inm90 Die Unterschiede zu anderen Mikroprozessoren fallen schon bei der Betrachtung des allgemeinen Blockschaltbildes f r alle Transputer auf KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 45 allgemeine Systemdienste Zentraleinheit Ereignislogik gt On Chip RAM 5 g 2 S Zeitgeberlogik Link Schnittstellen externe anwendungsspezi Speicherschnittstelle fische Schnittstelle Abbildung 3 3 Allgemeines Blockschaltbild f r alle Transputer vgl Ebe93 Seite 3 Transputer verf gen ber Internen Bus Zentraleinheit Prozessor CPU On Chip Ram bereits vorhandenes RAM transputerintern Link Schnittstellen Zeitgeberlogik Ereignislogik Interrupt Schnittstelle Systemdienste Taktgenerierung Speicherkonfigurationen etc anwendungsspezifische Schnittstelle Externe Speicherschnittstelle Gleitkomma Einheit nur bei T8xx Typen Festplattenschnittstelle nur bei M212 KAPITEL 3 ABBILDEN DER PROZE
142. ere Anforderungen dazu e Zusammenf hren von dezentral erhobenen Daten in eine globale Ereignisreihen folge e Versenden von dezentral erhobenen Daten ber ein Netz Eine weiterf hrende Diskussion der Funktionen f r Me werkzeuge in Verteilten Syste men findet man in Jai91 S 101ff sowie in MSS93 und K 95 KAPITEL 2 ANFORDERUNGEN AN EIN MESSWERKZEUG 33 2 6 Anforderungen der Benutzer Die Anforderungen der Benutzer sind blicherweise e leichte und komfortable Bedienbarkeit insbesondere e Wahl der Schnittstelle aus graphischer Oberfl che oder Kommandozeile e Konformit t zu Standardschnittstellen Windows CU AT usw e Wahl zwischen Bedienmodi Anf nger Fortgeschrittener und Experte Eingabehilfen z B vorkonfigurierte Me aufgaben Me templates Fehlertoleranz bei Fehlbedienung Hilfsfunktionen kontextabh ngige Hilfe On Line Hilfe Hypertextdokumenta tion Referenzhandb cher freie Kombinationsm glichkeiten der vorhandenen Funktionen Orthogonalit t Erweiterbarkeit insbesondere durch Programmierschnittstelle Anpassen der On Line Dokumentation Anpassen an neue Protokolle Anpassen an neue Netze u a auch an physikalische bertragungsarten Es sind insbesondere die oben genannten Benutzeranforderungen die bei der Im plementation einen streng modularen Aufbau erforderlich machen Die Wahl einer bestimmten Schnittstelle kann dann leicht durch
143. eren Prozes sor zugeordnet werden Migration oder eine bestimmte Zeit lang warten bis sie wieder zugeordnet werden Bei der konservativen Zuordnung werden nur solche Prozessoren belegt die ihre vorherigen Auftr ge ausgef hrt haben Diese Definitionen sind eine Zusammenfassung der Darstellung in Hei94 S 82ff In Abbildung 3 1 ist eine Klassifikation f r die Zuordnung abgebildet Zuordnung Programmebene Partitionierung m quantitativ qualitativ Programmtrennung 7 disjunkt berlappend Zusammenhang zusammenh ngend gestreut Proze ebene rn Abbildung rr injektiv kontraktiv Vollst ndigkeit r vollst ndig unvollst ndig Vorgehensweise konservativ lL aggressiv Abbildung 3 1 Klassifikation der Zuordnung vgl Hei94 S 87 KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 41 3 1 3 Ziele bei der Zuordnung Eine Zuordnung von Prozessen zu Prozessoren ist nicht willk rlich sondern ziel gerichtet Man m chte eine optimale Zuordnung entsprechend einer oder mehrerer Zielfunktionen erreichen Diese Zuordnung mu im allgemeinen Fall noch unter be stimmten Randbedingungen den Restriktionen erfolgen Zu optimierende Zielfunktionen k nnen u a sein vgl Hei94 S 89 e Durchsatz e gleichm ige Auslastung der Prozessoren e Antwortzeiten Restriktionen k nnen entweder qualitativ oder quantitativ sein Beispiel
144. ertragungs geschwindigkeit von 100 Megabit pro Sekunde In diesem Abschnitt wird eine Lei stungsprognose f r die FDDI Analyse auf Grundlage der Me werte in Abschnitt 7 2 2 erstellt F r die Leistungsprognose sollen folgende Annahmen gelten e Der Prototyp wird mit T9000 Transputern realisiert Ein T9000 hat eine Spitzen leistung von 200 MIPS und 100 MBit s bertragungsgeschwindigkeit pro Link Daraus ergibt sich eine Leistungssteigerung um den Faktor 6 6 bei Berechnungen und um den Faktor 5 bei der Interprozessorkommunikation e Eine EDD Medium Access Control MAC Dateneinheit zur bertragung von Benutzerdaten ist 28 Byte lang Da diese Dateneinheit ber keine Informatio nen verf gt die eine eingebettete Dateneinheit identifizieren wird angenommen 1430 MIPS pro T800 und 200 MIPS pro T9000 sind Herstellerangaben Test BHK94 S 343 KAPITEL 7 LEISTUNGSBEWERTUNG DES PROTOTYPEN 173 da grunds tzlich f nf Byte f r ein Sub Network Access Protocol SNAP in eine FDDI Dateneinheit eingebettet werden Die Informationen dieser f nf Byte werden zur Identifizierung einer IP Dateneinheit 20 Byte ben tigt in die wiederum eine UDP Dateneinheit minimaler L nge 8 Byte eingebettet wird F r die weiteren Berechnungen wird demnach eine FDDI Dateneinheit mit einer L nge von 61 Byte angenommen e Der Analyseaufwand f r die FDDI MAC Dateneinheit und der eingebetteten SNAP Informationen entspricht der Analyse einer Ether
145. es Transputernetzes mit einer Startmeldung Der Benutzer kann so pr fen ob alle Prozesse ordnungsgem geladen wurden Die Aus gabe erfolgt im Standardausgabe Fenster wie in Abbildung 6 2 dargestellt Bei diesem Fenster handelt es sich um ein Textfenster vgl Abschnitt 5 3 4 2 Man erkennt auf der rechten Seite den Rollbalken zum Verschieben des sichtbaren KAPITEL 6 ARBEITEN MIT DEM PROTOTYPEN 148 x PM Frontend STDOUT File Show Messung Help ETH_ANALYSER_FRONTEND Y1 1 Carsten Benecke Mae 95 Status PSTAT Started 1 Status PPAKETI Started 3 Status PPAKET Ringpuffer OK Status PPAKET Started 2 Status PPAKET Ringpuffer OK Status PDEY Started 4 Status PDEY Ringpuffer OK Status PSTAT Ringpuffer OK Abbildung 6 2 Standardausgabe Textausschnittes In der rechten oberen Ecke des Fensters sieht man zwei Schalter zum Minimieren und Maximieren des Fensters Einige Kommandos k nnen ber das Men des Standardausgabe Fensters aus gew hlt werden Die Men eintr ge werden kurz beschrieben 6 1 1 1 Das File Men ber das File Men k nnen folgende Kommandos ausgew hlt werden e Transputer booten Die Prozesse werden normalerweise automatisch in das Transputernetz geladen s o Falls das Laden der Prozesse nicht gelingt kann der Benutzer mit diesem Kommando einen weiteren Versuch zum Laden der Pro zesse ausl sen e About Eth_Analyser Der Benu
146. eses Konzept bei der Verarbeitung von verbindungslosen Protokollen leistungsf higer Da bei verbindungslosen Proto kollen die protokollabh ngige Interproze kommunikation zwischen Sende und Emp fangsproze minimal ist kann die Parallelverarbeitung von den zwei verschiedenen Prozessen f r die Sende und Empfangsfunktionen profitieren Die Anpassung dieses Konzeptes f r ein paralleles Me werkzeug lohnt au erdem nur dann wenn neben der Protokollanalyse auch Protokolldateneinheiten vom Me werkzeug generiert werden sollen da nur in diesem Fall Sendekomponenten in den Protokollschichten n tig sind Dies ist beispielsweise bei einem Protokolltester not wendig KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 64 3 3 4 3 Bewertung der Protokollfunktionen Im direkten Vergleich mit einer Sende Empfangspipeline kann man mit dem Kon zept der Protokollfunktionen eine deutlich feinere Granularit t erreichen Aus der Sicht der Leistungsf higkeit ist dieser Ansatz vorzuziehen Die vorhandenen Prozes soren k nnen durch eine ausgewogene Zuordnung der Protokollprozesse gleichm ig belastet werden Dadurch ist dieser Ansatz gut geeignet um die Protokollverarbeitung einzelner Protokolle zu beschleunigen Allerdings sind bei diesem Ansatz eine Vielzahl von Unterst tzungsfunktionen not wendig Der anfallende Overhead ist deutlich h her als bei Schichtenpipeline und Sende Empfangspipeline da die protokollspezifische Interproze
147. esse des Hostrechners Bei der Beschreibung der Hardware in Abschnitt 3 2 wurde dargestellt da die TBs in einen Hostrechner Host eingesetzt werden m ssen da die TBs nicht ber eigene Peripherie verf gen Nur unter Benutzung der Peripherieger te des Hosts k nnen die Anforderungen bez glich der Interaktion mit dem Benutzer und dem Verwalten der Daten erf llt werden vgl Abschnitt 2 7 4 Es m ssen daher Prozesse realisiert werden die die Anforderungen an die Inter aktion mit dem Benutzer realisieren Dabei m ssen die Standardschnittstellen des Betriebssystems des Hosts benutzt werden F r die Interaktion mit dem Benutzer m ssen folgende Funktionen realisiert werden e Eine textbasierte Ein und Ausgabe Die wichtigsten Kommandos sollte der Be nutzer sowohl ber eine Kommandozeile als Zeichenketten eingeben k nnen als auch ber die Selektion mit einer Maus Fehlermeldungen und andere Nach richten des Werkzeuges sollten als Klar Text Meldungen ausgegeben werden k nnen Eine graphische Ein und Ausgabe Die Vorteile einer graphischen Ausgabe liegt in der anschaulichen Pr sentation umfangreicher Daten Die prinzipiellen M glichkeiten der graphischen Ausgabe wurden bereits in Abschnitt 2 4 verdeut licht Auch die graphische Eingabe kann die Interaktion mit dem Benutzer vereinfa chen Umfangreiche Selektionen aus vorgegebenen M glichkeiten ber Dialoge der graphischen Benutzeroberfl che sind eine
148. essoren eines Parallelrechners dargestellt werden Das Problem der Zuordnung hat drei wesentliche Aspekte Einerseits ist eine Zuordnung abh ngig von der Hardware vgl Abschnitt 3 2 andererseits von dem Zuordnungsziel 37 KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 38 vgl Abschnitt 3 1 3 Au erdem gibt es bei der Zuordnung einen zeitlichen Aspekt Die Entscheidung welche Instanzen bei der Programmentwicklung und Programma usf hrung die Zuordnung vornehmen hat Einflu auf das dynamische Verhalten eines parallelen Programms vgl Abschnitt 3 1 4 3 1 1 Zuordnung von Algorithmen zu Prozessoren Ein Programm realisiert einen oder mehrere Algorithmen Das Programm mu zur Berechnung auf mindestens einem Prozessor ausgef hrt werden Zu den Problemstel lungen der sequentiellen Programmierung wie beispielsweise die prozedurale Dekom position der Algorithmen in berschaubare kleinere Teilalgorithmen kommen bei der parallelen Programmierung die beiden folgenden Problemkomplexe hinzu e Aufsp ren der inh renten Parallelit t eines Algorithmus e Abbilden der parallelen Programme auf die Prozessoren Die inh rente Parallelit t eines Algorithmus besteht aus denjenigen parallel ausf hr baren Teilalgorithmen die nur aufgrund der bisher dominierenden sequentiellen Pro grammierung nacheinander ausgef hrt wurden Diese inh rente Parallelit t mu wie derentdeckt werden vgl Abschnitt 3 3 Realisiert man die inh re
149. fang des Kapitels 4 wird eine Konfiguration auf Grundlage des gew hlten Konzeptes vorgestellt die bereits wesentliche Aspekte des zu reali sierenden Prototypen festlegt Hier wird bereits in groben Z gen festgelegt welche Funktionen als Prozesse zusammenwirken sollen In Kapitel 4 werden die ben tigten Funktionen ausf hrlich beschrieben Es wird dargestellt wozu die jeweilige Funktion ben tigt wird und wie sie zu klassifizieren ist In Kapitel 5 wird schlie lich beschrieben wie die Funktionen letztendlich realisiert wurden Grundlegende Algorithmen werden mit Nassi Schneiderman Diagrammen verdeutlicht Die Funktionen werden zu T hreads und Prozessen zusammengestellt In Kapitel 6 wird der Umgang mit dem Prototypen beschrieben Dieses Kapitel ist sozusagen Benutzerhandbuch Troubleshooting Guide und Referenz In Kapi tel 7 werden Engp sse des Prototypen identifiziert und eine Absch tzung der Lei stungsf higkeit gegeben Die Zusammenfassung und Ausblick auf weitere Forschungsaktivit ten ist im letz ten Kapitel Kapitel 1 Analyse von Kommunikationssystemen Neben einer allgemeinen Definition f r Analyse wird in diesem Kapitel dargestellt aus welchen Gr nden man ein Kommunikationssystem analysieren m chte vgl Abschnitt 1 1 und welche Vorgehensweisen bzw Analysemethoden grunds tzlich m glich sind vgl Abschnitt 1 2 Es wird vor allem auf die Analyse vorhandener Kommunikationssysteme mit Hilfe von Messungen vgl
150. fizieren mit anschlie ender Entwicklung Realisierung Konfigurierung und Inbetriebnahme der betroffenen Komponenten Das Erkennen von potentiellen Fehlern ist ebenfalls wichtig So kann etwa die Lastmessung s u benutzt werden um m gliche Fehler aufgrund von zu hoher Last an einer Komponente fr hzeitig aufzufinden Der Netzverwalter kann dann geeignete Gegenma nahmen treffen bevor es zu Fehlern kommt Auch das Messen von Dienstg te Quality of Service geh rt in diese Kategorie Es ist i d R Verhandlungssache zweier Partnerinstanzen welche Dienstg te f r eine bertragung gelten soll Dennoch kann es bei einer zu hohen Bitfehlerrate einer Leitung zu Abbr chen von bertragungen kommen was zumindest aus Anwendersicht als Fehler zu klassifizieren ist Messungen k nnen auch in diesem Fall helfen eine bestimmte Dienstg te nachzuweisen 1 3 1 2 Erkennen der Belastung eines Kommunikationssystems Das Erkennen der Belastung eines Kommunikationssystems ist notwendig um ent scheiden zu k nnen ob und wie das System zu rekonfigurieren oder zu erweitern ist Insbesondere sind hier zu nennen e Betriebsmittelauslastung Accounting e Verkehrs und Lastanalysen e Messen des Durchsatzes KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 15 Eine Analyse der Betriebsmittelauslastung zeigt schnell auf wo es zu Engp ssen einerseits und unn tiger Redundanz andererseits kommt Zeigen beispielsweise die Accounti
151. funktionen Rohdatenerfassung Ger tetreiber TB Umwandlungsfunktionen Tabelle 4 1 Klassifikation der Funktionen Kapitel 5 Realisierung eines parallelen Me werkzeuges f r Ethernet basierte Netze In diesem Kapitel wird die Implementierung des Me werkzeuges beschrieben Es wird dargestellt wie die Anforderungen aus Abschnitt 2 7 unter Beachtung der Restriktio nen aus Abschnitt 2 7 4 und 4 1 auf Grundlage des Konzeptes der Paketparallelit t vgl Abschnitt 3 3 3 5 realisiert werden In Abschnitt 5 1 wird Abbildung 4 1 wieder aufgegriffen Durch den Entwurf der Funktionen in Kapitel 4 ist es m glich die Funktionen Prozessen zuzuordnen so da sich eine gegen ber Abbildung 4 1 verfeinerte Darstellung ergibt Die einzelnen Pro zesse werden benannt und auf Grundlage eines allgemeinen Proze Templates verfei nert vgl Abschnitt 5 2 In den Abschnitten 5 3 und 5 4 werden schlie lich die Realisierungen der einzelnen Funktionen diskutiert Die Darstellungsreihenfolge orientiert sich am Entwurf aus Kapitel 4 Das Vorgehen bei Erweiterungen wird in Abschnitt 5 6 diskutiert Als Beispiel f r die Erweiterung des Prototypen wird die Vorgehensweise zur Implementierung einer neuen Proze klasse dargestellt Au erdem werden in diesem Abschnitt sinnvolle Erweiterungen diskutiert In Abschnitt 5 7 wird der Prototyp mit anderen Werkzeugen der Kommunikations me technik verglichen Das dynamische Verhalten der Konfiguration wird
152. g 3 13 N I I I O _ 4 Weitergabe v PDUs else gt Realisierung Schicht n za u CE lt __ gt Interproze kommunikation N I Proze I I I y Protokollinstanz Abbildung 3 13 Protokollfunktionen vgl Zit91b S 52f 3 3 3 4 Verbindungsparallelit t Die Verbindungsparallelit t entsteht durch die verschiedenen Verbindungen die in einem Endsystem aufgebaut werden k nnen Die Protokollverarbeitung kann i d R f r verschiedene Verbindungen v llig parallel erfolgen Offensichtlich l t sich der Grad der erreichbaren Parallelit t nicht im voraus angeben Vielmehr entspricht dieser exakt der Anzahl der zu einem Zeitpunkt aktiven Verbindungen in einem Endsystem Die Granularit t der Parallelit t kann sich also dynamisch ver ndern vgl Abbildung 3 14 f r eine schematische Darstellung 167g Abschnitt 3 1 Je feiner die funktionale Dekomposition ist desto h her ist der erreichbare Grad an m glicher Parallelverarbeitung 17 Angenommen in einem Endsystem wird eine Protokollhierarchie aus n Protokollen eingesetzt dann gibt es nach der funktionalen Dekomposition in horizontale und vertikale Parallelit t genau 2n parallel ausf hrbare Funktionen die als eigenst ndige Prozesse realisiert werden k nnen KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 61 5 Ko i i i i i E REAN H j k i ame 3 f C O Schicht n S f Schicht n SR f t
153. g 5 20 dargestellt Byte Byte 0 4 8 n L ngen Feld Tag Feld Daten Feld L nge in Byte hier n Typ Datenl nge n 8 Byte 16 Vermitt lungs bits i Abbildung 5 20 Allgemeines Nachrichtenformat 5 4 1 2 Vermittlungsalgorithmus Jeder Prozessor verf gt ber eine eigene Vermittlungstabelle Darin sind folgende Angaben enthalten e Anzahl der zu unterst tzenden Kommunikationskan le KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 133 e Bezeichnung dieser Kommunikationskan le e Angaben welche Proze gruppen bzw Richtungen ber den jeweiligen Kommu nikationskanal erreichbar sind Eine eintreffende Nachricht wird nun ber alle Kommunikationskan le ausgegeben bei deren Tabelleneintrag mindestens eine Proze gruppe bzw Richtungsangabe mit der im Nachrichten Tag bereinstimmt Dazu ist nur eine AND Verkn pfung von Ta belleneintrag und Nachrichten Tag erforderlich Die Vermittlungsentscheidung kann sehr schnell getroffen werden Die Nachricht wird jedoch nie ber denselben Kanal aus gegeben ber den sie eingetroffen ist Dadurch werden endlos laufende sich st ndig vervielfachende Nachrichten vermieden Durch diesen einfachen Algorithmus lassen sich die Nachteile einer ad hoc L sung vermeiden vgl Abschnitt 4 5 1 Durch getrennte Prozesse f r das Senden und Empfangen von Nachrichten vermeidet man au erdem Verklemmungen und trennt die Kommunikation von ande
154. g an einen Hostrechner ist ein Intel 486 Prozessor da die Entwicklungsumgebung s u diesen voraussetzt In Abbildung 3 9 ist die gesamte Hardware Architektur schematisch dargestellt Auf Grundlage dieser Hardware Architektur werden in Abschnitt 4 1 die Restriktio nen durch die Hardware beschrieben Durch st ndiges pollen kann der PC pr fen ob der Transputer Daten senden m chte oder bereit ist selber Nachrichten zu empfangen KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 53 4Mbyte 4Mbyte 4Mbyte 4Mbyte PC Speicher ek PC T800 T800 T800 T800 Schnitt R stelle Kreuzschienenverteiler fs 3 OO m i1586 Y Konfigurationsbuchsen Verbindung ber externe Verbindungsbuchse Ethernet Kommunika SE Schnitt tionssystem stelle PC Peripherie PC 64 Kbyte T225 lt Schnitt stelle Abbildung 3 9 Hardware Architektur 3 2 2 Entwicklungsumgebung F r die Programmerstellung werden zwei verschiedene Entwicklungsumgebungen ein gesetzt In beiden F llen wird die Programmiersprache C benutzt Wegen der weiten Verbreitung dieser Sprache ist so eine gute Portierbarkeit
155. ge der Messung angelegt wurden Bei Erweiterungen sollten an dieser Stelle alle Funktionen aufgerufen werden die ein ordentliches Freigeben von Betriebsmittel veranlassen die f r die Messung angefordert wurden Zuvor gibt der Benutzer in Zeile 30 den Befehl drop filter ein Bei einem Neustart der Messung werden dann wieder alle Dateneinheiten ausgewertet Ein Filter bleibt In diesem Fall sind das Eintr ge in der Symboltabelle die mit dem Namen _arp verbunden waren KAPITEL 6 ARBEITEN MIT DEM PROTOTYPEN 159 immer solange erhalten bis er vom Benutzer explizit gel scht wird Das Kommando spool off Zeile 34 unterbricht das Protokollieren der Stan dardausgabe in eine Datei Die Kommandos show und spool sind grunds tzlich unabh ngig von einer Messung Sie k nnen zu jeder Zeit eingegeben werden also auch w hrend einer Messung 6 4 Fallbeispiel II Durchf hren einer Lastmessung Als zweites Beispiel wird eine Lastmessung durchgef hrt Durch eine Lastmessung kann man sich anzeigen lassen wie gro die Auslastung des Ethernet Segmentes ist und durch welche Art von Auftr gen die Last erzeugt wird 6 4 1 Ausw hlen der anzuzeigenden Protokolle Es soll die Auslastung des Ethernet Segmentes w hrend der Messung graphisch dar gestellt werden Dabei wird analog zum obigen Beispiel vorgegangen Der Messung wird ein Name gegeben und es wird gegebenenfalls ein Filter gesetzt z B um nur die L
156. geben wollen um nicht jeden Proze einzeln adressieren zu m ssen Eine Nachricht wird nur dann mehrfach ver sendet wenn die Empf nger ber verschiedene physikalische Verbindungen Transpu terlinks zu erreichen sind Die Kenntnis ber Proze gruppen und die Entscheidung ob eine Nachricht vervielf ltigt werden mu sollte in Vermittlungsfunktionen verbor gen werden Der Nachrichtenaustausch w re f r die Prozesse transparent Auch der obligatorische gegenseitige Ausschlu beim Zugriff auf die Transputerlinks kann in den Vermittlungsfunktionen verborgen werden Ein weiterer Grund die Nachrichtenvermittlung als unterst tzende Funktionen be reitzustellen ist die Erfahrung da die Trennung von Verarbeitung und Kommuni kation in der Regel die Verarbeitungsleistung der Transputer erh ht vgl Ben94 S 114f Dar ber hinaus sollten die Vermittlungsfunktionen weiter unterteilt werden in Funktionen zum Senden und Funktionen zum Empfangen Realisiert man die Sende und Empfangsfunktionen als eigenst ndige Prozesse vermeidet man Verklemmungen wie in Abbildung 4 4 dargestellt 15 Eine Nachricht die bei einer solchen L sung an mehr als einen Proze gesendet werden soll mu f r alle Empfangsprozesse einzeln versendet werden Auch das Benennen von Proze gruppen mit eindeutigen Nummern ndert an der Notwendigkeit Nachrichten mehrfach zu versenden nichts Viel mehr mu jeder Proze neben den einzelnen Nummern al
157. grammen n tzlich sein Der Scheduler vergi t sozusagen den angehaltenen Proze da solche Prozesse nicht in einer Liste gef hrt werden Nor malerweise terminieren Prozesse nach der Ausf hrung des Maschinenbefehls endp Sie gehen in den Zustand beendet ber Der Scheduler verwaltet beendete Prozesse nicht l nger in der Proze liste Aktive Prozesse die auf ein Ereignis warten gehen in den Zustand wartend ber Es gibt grunds tzlich drei verschiedene Ereignisse auf die ein Proze warten kann 1 Es ergibt sich ein Rendezvous Ein Proze der auf einen OCCAM Kanal schrei ben oder von ihm lesen will wird vom Scheduler solange in den Zustand war tend versetzt bis der entsprechende Sende bzw Empfangsproze ebenfalls be reit ist zu kommunizieren 2 Eine programmierte Zeitdauer ist abgelaufen Ein Proze kann sich selbst f r eine bestimmte Zeit in den Zustand wartend berf hren indem er ein Zeitoffset beim Zugriff auf einen Zeitgeber s u angibt Nach Verstreichen der dem Zeitoff set entsprechenden Zeit benachrichtigt der Zeitgeber den Scheduler da der entsprechende Proze wieder in die Bereitschaftsliste aufzunehmen ist 3 Ein Proze der auf einen Interrupt reagieren soll wird durch den Interrupt ak tiviert Ein Proze der von dem speziellen Kanal Event lesen will wird auto matisch zum Interrupt Bearbeitungs Proze Mit anderen Worten Das Les
158. haben Alle anderen Eintr ge haben variable Werte mit folgender Bedeutung 1 Das Feld KL Kopfl nge gibt die L nge des Datagrammkopfes in 32bit Worten an Der Datagrammkopf hat aufgrund der variablen Anzahl von Optionen s u keine feste L nge Er umfa t alle Felder bis einschlie lich des F llfeldes F LL Das F llfeld besteht ausschlie lich aus Nullen 0 und erweitert die letzte Option gegebenenfalls auf eine L nge von 32bit so da die anschlie enden Daten IP Daten auf 32bit innerhalb des Datagramms ausgerichtet sind Ein typischer Eintrag f r KL ist f nf 5 Ein 20 Byte langer IP Kopf KL 5 4 hat weder Optionen noch ein F llfeld 2 Der Diensttyp DT ist seinerseits unterstrukturiert Das Vorrangfeld VR enth lt einen Wert von null 0 bis sieben 7 Dieser Wert wird von den mei sten Vermittlungsrechnern ignoriert Konzeptionell sollte ein Datagramm mit h herem Wert in VR vor einem Datagramm mit niedrigerem Wert in VR ver mittelt werden Die Bits V D und Z sollten im gegenseitigen Ausschlu gesetzt sein Sie geben an ob ein Datagramm mit geringer Verz gerung V 1 mit KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 115 hohem Durchsatz D 1 oder mit hoher Zuverl ssigkeit vermittelt werden soll F r einige anwendungsorientierte Protokolle gibt es Vorschl ge wie diese Bits in Abh ngigkeit vom Typ der eingebetteten Dateneinheiten zu setzen sind Die beiden letzten Bits des DT Feldes werden nicht benutzt
159. hen Dia logfeldern und Men strukturen hnlich sein um dem Benutzer eine intuitive Auswahl zu erm glichen vgl Abschnitt 2 6 Die Ausgabe von Fehlermeldungen und textbasierter Informationen soll in einem Fenster der graphischen Oberfl che erscheinen Dazu werden Funktionen ben tigt die e die Informationen in das Fenster einschreiben e Gr e und Lage des Fensters auf der graphischen Oberfl che kontrollieren e optional die Ausgaben zus tzlich in eine Datei schreiben und e aus dem Fenster herausgerollte Informationen durch Verschieben des Fenster ausschnittes erneut anzeigen 10Symbole k nnen Elemente eines Men s oder Schalter und hnliche Kontrollelemente eines Dia logfeldes sein Die Terminologie bei der Programmierung der graphischen Schnittstelle von OS 2 wird beispielsweise in Eck93 dargestellt Die grundlegenden Techniken der Fensterprogrammierung werden beispielsweise in Roc90 dargestellt KAPITEL A ENTWURF DES MESSWERKZEUGES 81 4 4 4 2 Essentielle Funktionen zur Darstellung und Export der Analyse ergebnisse Analysedaten werden entweder on line dargestellt oder in einer Datei gespeichert Werden die Daten on line angezeigt kann eine beliebige programminh rente Dar stellung gew hlt werden Sollen hingegen externe Werkzeuge auf den Daten arbeiten mu man eine m glichst kompakte maschinell leicht weiterverarbeitbare Darstellung w hlen vgl Abschnitt 2 5 und 2 7 1
160. hread abgearbeitet so da die ben tigte Zeit bis auf eine Mikrosekunde genau gemessen werden konnte Die minimalen Abweichun gen bei den Messungen ergeben sich aus der unterschiedlichen Auslastung der DMA Schnittstelle des Transputerlinks ber den Dateneinheiten von PDEV empfangen wurden w hrend die Messungen durchgef hrt wurden Vollst ndig bedeutet da der Prototyp alle bisher realisierten Analysefunktionen f r die Proto kolle aufruft KAPITEL 7 LEISTUNGSBEWERTUNG DES PROTOTYPEN 170 Grenzdurchsatz eines Pakettraegers T T T T T pu data iacob 2 3 g g pidata piu data o 14000 pe data x 4 peu data A pei data x peiu data 12000 bh o Pe e e IS 0 o o o o o A O E 10000 J o D o g E 3 lt 8000 u x x x x x x x x x 6000 u D D D A D D D D A Ki Ki Ki Ki Ki Ki Ki 4500 L L L 1 L 0 200 400 600 800 1000 1200 Anzahl der Wiederholungen Abbildung 7 6 Grenzdurchsatz eines Pakettr gers Der Grenzdurchsatz eines Pakettr gers liegt bei 14880 UDP Dateneinheiten pro Sekunde pu data Wird hingegen der Protokollstapel so weit wie m glich ausgewer Let sinkt der Grenzdurchsatz auf 5024 Dateneinheiten pro Sekunde peiu data Offensichtlich ist die in Abschnitt 4 4 2 2 gemachte Unterscheidung zwischen Erken nen und Analysieren auch von praktischer Relevanz Das Erkennen eines Protokolls unabh ngig von der Analyse vorzunehmen erm glicht den hoh
161. hreiben neuer Konfigurations skripte 5 7 Anmerkungen zur Realisierung und zu Erweiterun gen Um k nftige Erweiterungen des Prototypen vorzubereiten wurden die Programmquel len modular programmiert und dokumentiert Das Kapitel 5 ist als Teil der Dokumen tation zu verstehen Angaben zu besonderen Algorithmen und die Beschreibung der verwendeten Datenstrukturen und abstrakten Datentypen sind in den Programmauel len enthalten Die Verwaltung der Programmquellen mit einem Versionskontrollsystem wird in Abschnitt 5 7 1 beschrieben In Abschnitt 5 7 2 werden einige Erweiterungs vorschl ge dargestellt Abschnitt 5 7 3 zeigt zwei M glichkeiten zur Integration des Prototypen in Managementsysteme Eine Abgrenzung des Prototypen von anderen Werkzeugen der Kommunikationsme technik folgt in Abschnitt 5 7 4 5 7 1 Verwaltung der Programmquellen mit einem Versionskontroll system Die einzelnen Programmodule sind nat rlich nicht sofort in ihrer vorl ufigen Endfas sung entstanden sondern durch sukzessive Erweiterungen und Fehlerbehebungen Der Nachrichtentyp ist TEXTINFO das zu setzende Vermittlungs Bit ist ROUTE_USER Dazu ist eine Erweiterung um einen Transputer erforderlich Das ist die Fassung in der der Prototyp zur Zeit Februar 1996 vorliegt KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 141 Die einzelnen Erweiterungen und Fehlerbehebungen an den Modulen sind ebenfalls dokumentiert Dazu wurde ein Versionskontrollsystem
162. ich um Protokolle die jedem Knoten bekannt sein sollten der TCP IP basierte Kommu nikation unterst tzt Diese Protokolle bilden den rudiment ren Teil der TCP IP Protokollfamilie vgl Abschnitt 2 7 4 5 3 2 1 Template einer Analysefunktion Aufgrund des Entwurfs in Abschnitt 4 4 2 kann hier ein allgemeines Template einer Analysefunktion angegeben werden Jeder Analysefunktion m ssen mindestens zwei Parameter bergeben werden Es sind dies e Ein Zeiger auf die zu analysierenden Rohdaten e Ein Zeiger auf einen Speicherbereich in dem die Analyseergebnisse abgelegt wer den k nnen Die beiden Parameter werden entweder von einer Unterst tzungsfunktion bereitge stellt oder von einer anderen Analysefunktion bergeben Da die Analyseergebnisse aller Analysefunktionen an andere Prozesse gesendet werden m ssen bietet es sich an den Speicherbereich f r alle Analyseergebnisse zusammenh ngend bereitzustellen Dadurch k nnen nach Abschlu der Analyse einer Dateneinheit alle Ergebnisse als Block versendet werden Eine Analysefunktion mu grunds tzlich folgende Aktionen durchf hren e Berechnen des Speicherbedarfs f r die eigenen Analyseergebnisse Dieser Speicher bedarf ist abh ngig von der Anzahl und der Kardinalit t der Analyseergebnisse und von den Benutzerw nschen Sollen f r ein bestimmtes Protokoll keine Ana lysen durchgef hrt werden ben tigt die Funktion auch keinen Speicherplatz f r Ergebnisse Ber
163. ich ist In Tabelle 5 1 sind alle m glichen Kombinationen aufgef hrt Options Options L nge Beschreibung klasse nummer Ende der Optionsliste Immer dann wenn die Optionen nicht mit dem IP Kopf enden Ausrichten von Byte in einer Opti onsliste 2 nun F r milit rische Anwendungen Vorgaben f r einen zu verwenden 3 variabel den Pfad Pfad aufzeichnen den das Data 7 variabel i 3 gramm vermittelt wird ul SI 4 Historisch wird nicht mehr benutzt j Strikte Vorgabe f r einen zu verwen variabel denden Pfad 9 4 variabel Zeitstempel der Vermittlungsrech ner anfordern Tabelle 5 1 IP Optionen Es f llt auf da bei weitem nicht alle 32 m glichen Optionsnummern in Kombi nation mit den beiden m glichen Optionsklassen zul ssig sind Au erdem ist von den acht 8 m glichen Kombinationen nur die Optionsnummer vier 4 mit der Options klasse Fehlersuche und Messungen 2 vertr glich 5 3 2 5 Realisierung der Analysefunktion f r das Internet Control Mes sage Protocol Das Internet Control Message Protocol ICMP wird in der TCP IP Protokoll Fami lie benutzt um Fehlermeldungen und Kontrollnachrichten zu versenden Das Format einer ICMP Nachricht wird durch die beiden Felder TYP und CODE bestimmt Das allgemeine Nachrichten Format einer ICMP Dateneinheit ist in Abbildung 5 13 abgebildet ICMP Dateneinheiten werden in Datagramme eingebettet Der Wert Pro tokoll
164. ie Proze gruppe der Pakettr ger mit einem weiteren Vermittlungs bit kombiniert das die jeweilige Richtung des Empf ngers einer der beiden Pakettr ger bez glich des Senders angibt Bei jeder neuen Dateneinheit wird die Richtung ge ndert so da sich die oben gew hlte Aufteilung ergibt Auch die Verteilungsfunktionen lassen sich f r den allgemeinen Fall mit mehre ren Pakettr gern gt gt 2 hierarchisch anordnen Bei dem eben dargestellten Ver teilungsverfahren w rde man einen bin ren Baum erhalten an dessen inneren Knoten 33Diese Anzahl gilt pro Proze da jeder Proze ber eine eigene Vermittlungstabelle verf gen kann Es w ren sehr gro e Analysewerkzeuge realisierbar Das mu nicht zwangsl ufig so sein Eine andere Verteilung k nnte ebensogut lastabh ngig oder zuf llig erfolgen 35 Auch hier sind andere Vorgehensweisen denkbar Dateneinheiten k nnten gesammelt und dann schlagartig in einem burst an einen Pakettr ger weitergegeben werden KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 135 Verteilungsfunktionen die Dateneinheiten auf die Bl tter hier die Pakettr ger ver teilen vgl Abbildung 5 22 O Verteilungsfunktion Pakettr ger Abbildung 5 22 Verteilen von Dateneinheiten auf mehrere Pakettr ger 5 4 3 Anmerkung zu Verbindungsmanagement Funktionen Die Verbindungsmanagement Funktionen wurden in Abschnitt 4 5 2 entworfen In Abschnitt 5 3 2 7 wurde dargestellt wie derart
165. ieren Kommandos werden mit einem Semi kolon abgeschlossen und dann an den Kommandointerpreter abgeschickt Einga befehler werden in dem Fenster Standardausgabe angezeigt Mit Ausnahme des Fensters Benutzereingabe das sich relativ zur Standardausgabe bewegt sind alle Fenster frei skalierbar und auf der graphischen Oberfl che frei beweg bar Die Fenster k nnen einzeln geschlossen und wieder ge ffnet werden In Abbildung 6 1 ist eine m gliche Anordnung der Fenster dargestellt x PM Frontend STDOUT File Show Messung Help OK init_tr x ARP RARP Tabelle OK PDEV DEBUGINFO R enable ARP RARP Tabelle Ok Format Anfragen Antworten Protokolladresse HW Adresse FILTER DEBUGINFO 91 11 22 00 04 00 07 PDEV DEBUGINFO Ri ARP_RESPONSE 0 1 aa 00 04 00 07 78 134 100 8 4 FILTER DEBUGINFO PDEV DEBUGINFO R PDEY DEBUGINFO ROUTF RFVICF DEM STOP disable Mbit s OK kalieren Legende PDEY DEBUGINFO ROL EINGABE filter eth_type ip DEET TEE Sekunden Abbildung 6 1 Fenster des Hostrechner Prozesses 6 1 1 Das Fenster Standardausgabe Der Hostrechner Proze versucht nach dem Start die Transputer zu konfigurieren und die Prozesse in das Transputernetz zu laden Dieser Vorgang dauert ein paar Sekun den In dieser Zeit kann der Benutzer keine Eingaben machen Ist die Konfigurierung gelungen melden sich die Prozesse d
166. ierung von Diensten Verarbeitet in der Regel die Protokolle einer Protokollfamilie Protokollautomaten werden als Pro zesse realisiert Monitor Mu potentiell alle Dateneinheiten im untersuchten System empfangen k nnen Kann gegebenenfalls ein an deres System simulieren Protokollverarbeitung zur statisti schen syntaktischen und semantischen Analyse von PDUs Analyse des zeit lichen Ablaufs Protokoll Timing Protokollhierarchie als Teil Menge zu analysierender Protokolle Analysiert verschiedenartige Proto kolle und Protokollfamilien Analyse braucht nicht durch Protokoll automaten realisiert werden Der Vergleich zeigt da sowohl das Endsystem als auch der Monitor die PDUs hierarchisch auswerten Diese hierarchische Auswertung der Informationen erfolgt nach der verwendeten Protokollhierarchie Die Motivation f r diese Hierarchisierung im Endsystem ist die Strukturierung und Bereitstellung der Dienste wobei Dienste einer h heren Schicht die einer niedrigeren benutzen k nnen um die eigene Dienstleistung einer h heren Schicht zur Verf gung zu stellen Der Monitor mu ebenfalls diese hierarchische Auswertung durchf hren da nur durch sukzessives Erkennen eines Protokolls der n chsth heren Schicht nach dem Emp fang einer Dateneinheit entschieden werden kann welche Bedeutung die PDU Daten haben Die Auswertung der PDUs gem einer Protokollhierarchie ist die Grundlage f r die Adaptio
167. ifikation einteilbar Das Ausl sen der Datenerfassung durch bestimmte Maschinen befehle und durch den Einzelschrittmodus sind ereignisgesteuerte Me verfahren Eine Datenerfassung ausgel st durch Zeitgeberunterbrechungen ist dagegen zeitgesteuert 1 4 5 Klassifikation nach der Ergebnispr sentation Diese Klassifikation unterscheidet zwischen e n line Monitoren und e Batch Monitoren Monitore die ihre Ergebnisse w hrend der Datenerfassung darstellen bezeichnet man als On line Monitore Batch Monitore hingegen sammeln die Me daten und 16Das ist der sogenannte Batch Betrieb Ergebnis ist hier ganz allgemein zu verstehen Me daten analysierte Daten graphische Darstel lungen oder Bewertungen des Monitors sind Ergebnisse KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 25 verarbeiten sie zu einem sp teren Zeitpunkt bzw sie berlassen die Analyse und gra phische Aufbereitung der Me daten monitor externen Werkzeugen On line Monitore kann man f r Messungen verwenden bei denen die Anzeige der Me ergebnisse unmittelbar nach ihrer Erfassung erforderlich ist Dies ist bei spielsweise bei berwachungsaufgaben w nschenswert bei denen eine Reaktion auf bestimmte Ereignisse Me ergebnisse erst nach der visuellen Bewertung eines Verant wortlichen erw nscht ist On line Monitore sind jedoch nur dann verwendbar wenn die anzuzeigenden Informationen vom menschlichen Betrachter noch
168. ige Funktionen f r das TCP Protokoll realisiert werden k nnten Diese Funktionen konnten leider nicht implementiert werden da die verbleibende Zeit bis zur Abgabe der Diplomarbeit f r die Bewertung des Prototypen ben tigt wurde vgl Kapitel 7 5 4 4 Realisierung der Kommunikationsunterst tzung f r den Host rechner Beim Entwurf der Kommunikationsunterst tzung wurde bereits die Entscheidung ge troffen keinen vollst ndigen Ger tetreiber f r OS 2 zu implementieren Als Grund wurde der gro e Aufwand f r die Programmierung eines Ger tetreibers genannt vgl Abschnitt 4 5 3 Ein weiterer Grund ist da nur veraltete Dokumentation zur Verf gung steht vgl Int89 Die Dokumentation beschreibt eine alte 16 bit Version von OS 2 und ist f r die Programmierung unter OS 2 Version 3 nicht zu gebrauchen Die Nachteile der Realisierung eines vollst ndigen Ger tetreibers konnten umgan gen werden indem eine Besonderheit des Betriebssystems ausgenutzt wurde Das 3OTCP ist das einzige verbindungsorientierte Protokoll das vom Prototypen analysiert werden kann KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 136 Betriebssystem gestattet eine Umgehung der Kern Funktionen beim Zugriff auf Ein und Ausgabeadressen Anwendungsprogramme k nnen f r bestimmte Adre bereiche Zugriffsprivilegien erlangen um so unter Umgehung der Kern Funktionen direkt auf Ein Ausgabeadressen bestimmter Ger te zuzugreifen Dar ber hinaus kann ma
169. igt man eine weitere Pipelinestufe f r die ses Protokoll Ver nderungen sind nur an der Stelle notwendig wo das neue Protokoll identifiziert wird also auf der jeweils davor liegenden Protokollschicht Allerdings f hren Erweiterungen um neue Protokollschichten unweigerlich zu Hardware Erweite rungen wenn man sich f r eine isomorphe Zuordnung von Prozessen zu Prozessoren 18Die Abk rzungen stehen f r das Internet Protocol und das User Datagram Protocol KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 63 entschieden hat In diesem Fall mu f r jedes neue Protokoll das als Proze realisiert wird ein weiterer Prozessor zur Verf gung gestellt werden Positiv auf die Leistungsf higkeit wirkt sich aus da die protokollabh ngige Inter proze kommunikation entf llt Ein Proze bearbeitet vollst ndig ein Protokoll So ist beispielsweise bei einem Protokolltester der auf diesem Konzept beruht keine In terproze kommunikation n tig wenn die Sendekomponente auf Ereignisse der Emp fangskomponente reagieren mu Dies ist ein Vorteil gegen ber der L sung gem Sende Empfangspipeline und dem Konzept der Protokollfunktionen s u Negativ auf die Leistungsf higkeit wirkt sich die geringe Granularit t bei dem Kon zept der Schichtenpipeline aus Sollen beispielsweise n Protokolle analysiert werden so ergeben sich maximal n Pipelinestufen und Prozesse die auf maximal n Pro zessoren plaziert werden k nnen Sind m
170. imal im Mittel seit Beginn der Messung pro Zeiteinheit e Angaben zur Verkehrsbelastung einzelner Knoten Antwortzeiten sofern das jeweilige Protokoll die Unterscheidung zwischen einer Aktion hier Senden einer antwortausl senden Nachricht und Reaktion hier Senden einer Antwort Nachricht erlaubt beispielsweise beim Handshake eines Verbindungsaufbaus KAPITEL 2 ANFORDERUNGEN AN EIN MESSWERKZEUG 29 e Testen einer Protokollinstanz Stimulieren der zu pr fenden Instanz durch PDUs und Analysieren der Antwort PDUs bez glich der Protokollspezifikation vgl GK94 S 354ff e Testen von Komponenten die in Netzen auf der Schicht 2 operieren beispiels weise Test ob eine Bridge genau die PDUs passieren l t die gem ihrer Zieladresse passieren d rfen 2 1 3 Schicht 3 Vermittlungsschicht Zus tzlich zu den Messungen der Schicht 2 sind hier Messungen n tig die die typischen Funktionen der Schicht 3 berpr fen Zu diesen Funktionen geh ren vor allem die Adre vergabe die Wegwahl Vermitteln und eventuell das Aufbauen Halten und Beenden von Verbindungen Daraus ergeben sich folgende Me und Analyseaufgaben e berpr fen der Bindung von physikalischen Adressen zu Schicht 3 Adressen vgl Abschnitt 5 11 e berpr fen der Wegwahl von Vermittlungsrechnern f r PDUs e berpr fen der Funktionen zum Segmentieren und Reassemblieren von PDUs e Zugriffskontrolle von fremden Netzen auf das eigene
171. in Denkbar sind auch hybride L sungen bei der die Analyse verbindungsloser Protokolle durch die Paketparallelit t erfolgt Verbindungsorientierte Protokolle k nnten durch dedizierte Prozesse analy siert werden so da eine Protokollpipeline entsteht Eine Konfiguration besteht aus den Prozessoren und den Verbindungen der Prozessoren unterein ander sowie einer Abbildung der Prozesse auf die Prozessoren KAPITEL 4 ENTWURF DES MESSWERKZEUGES 69 4 3 Grobgliederung des Me werkzeuges durch Prozesse Der Entwurf der Grobgliederung des Me werkzeuges ergibt sich aus den Anforde rungen und dem gew hlten Paradigma zur Parallelverarbeitung In Abschnitt 3 1 1 wurde dargestellt da beim Zuordnen von Algorithmen zu Prozessoren die inh rente Parallelit t aufgesp rt werden mu um dann die parallelen Prozesse auf Prozesso ren abzubilden Im folgenden Abschnitt wird begr ndet wie viele Prozessoren f r den Prototypen verwendet werden sollen In Abschnitt 4 3 2 k nnen dann die wesentlichen Prozesse des Me werkzeuges identifiziert werden Diese Prozesse werden in Abschnitt 4 3 3 Prozessoren zugeordnet so da sich die Grobgliederung des Me werkzeuges er gibt 4 3 1 Die Anzahl der Prozessoren F r den Prototypen sollen sechs Prozessoren verwendet werden Dies ist die minimale Anzahl an Prozessoren die sich aus der Kombination eines Transputerboards TBs aus Abbildung 3 7 und eines Boards aus Abbildung 3 8 zusammen mit dem Prozes
172. ine Analyse Bediensta tion mit zwei Bedieneinheiten so kann man feststellen da die mittlere Auslastung dieser Funktionseinheit bei den Messungen zum prim ren und sekund ren Engpa immer kleiner als 10 war 7 3 Leistungsprognose Typischerweise wird die Durchsatzsteigerung durch Parallelverarbeitung mit Hilfe des Speedup angegeben Der Gewinn G durch die Parallelverarbeitung wird auf Grund lage des schnellsten sequentiellen Algorithmus f r ein gegebenes Problem berechnet Dazu wird die Zeit f r die sequentielle Berechnung gemessen T und mit der Zeit f r die parallele Berechnung T auf n Prozessoren verglichen G n an gt 0 7 1 Idealerweise entspricht der Gewinn der Anzahl der eingesetzten Prozessoren Dieser lineare Speedup wird in der Praxis selten erreicht da mit jedem weiteren Prozessor der Kommunikationsoverhead zunimmt Die Bewertung der Paketparallelit t mit einer Gewinnkurve bringt kaum neue Erkenntnisse Unter der Voraussetzung da der sekund re Engpa beseitigt wird und gen gend Rohdaten f r die Analyse zur Verf gung stehen bekommt man bei der Paketparallelit t einen linearen Gewinn Interessanter ist die Frage wieviele Pakettr ger in Abh ngigkeit vom Analyseauf wand ben tigt werden um bei maximaler Auslastung des Netzes alle Dateneinheiten auszuwerten 7 3 1 Anzahl der Prozessoren f r Ethernet Analyse Die Brutto bertragungsgeschwindigkeit von Ethernet
173. inem Gigabit pro Sekunde realisiert und die Forschung geht in Richtung Terabit Netze Die zur Verf gung stehende Zeit betr gt ein Jahr KAPITEL 2 ANFORDERUNGEN AN EIN MESSWERKZEUG 36 Die Anforderungen an ein paralleles Me werkzeug sind unter Ber cksichtigung der Restriktionen Realisierung auf Grundlage eines noch zu w hlenden Paradigmas f r die parallele Protokollanalyse vgl Abschnitt 3 3 3 Erfassen von Me werten an noch zu definierenden Schnittstellen vgl Abschnitt 4 4 2 1 Spezifizieren dieser Schnittstellen mit Hilfe von Filtern vgl Abschnitt 2 2 Protokollieren eines Teils der TCP IP Protokollfamilie Auswahl der zu analysierenden Me werte und Protokolle durch den Benutzer Auswahl der zu erfassenden Me werte ber Dialoge einer graphischen Benut zerschnittstelle Anzeigen einer Standardauswertung w hrend des Betriebs ber eine graphische Benutzerschnittstelle Exportieren der Me ergebnisse in eine Datei f r Auswertungen mit externen Werkzeugen Die Erweiterbarkeit mu durch einen modularen Aufbau gew hrleistet sein Kapitel 3 Abbilden der Monitor Prozesse auf die Hardware Nachdem im vorherigen Abschnitt die Anforderungen an ein Me werkzeug aufgestellt wurden vgl Abschnitt 2 7 und die grunds tzliche Notwendigkeit f r eine parallele Realisierung motiviert wurde kann in diesem Kapitel gezielt auf die Parallelverarbei tung eingegangen werden Es sollen grunds
174. innen und auswerten F r die Planungs und Entwurfsphase eines Kommunikationssystems ist man grunds tzlich auf die modellgest tzte Analyse ange wiesen da in diesen Stadien das zu analysierende System nicht existiert vgl Wo193 S 1 Die modellgest tzte Analyse kann wiederum simulativ oder mathematisch analy tisch erfolgen Auch die Kombination beider Verfahren ist m glich Voraussetzung f r eine modellbasierte Analyse ist in jedem Fall die Erstellung und Validierung eines Modells vgl Pag91 S 13011 Ideal w re f r die Durchf hrung einer Analyse die geeigneteste Analysemethode f r den jeweiligen Fall d h f r das Ziel der Untersuchung zu w hlen In der Praxis ist die Wahl einer Analysemethode jedoch auch von anderen Faktoren abh ngig Beispiele hierf r sind Mangelhafte Kenntnisse F higkeiten des Analysierenden In der Regel ben tigt man f r die mathematisch analytische Methode umfassende mathematische Kenntnisse da bereits kleine Modelle eine sehr komplexe formale Be schreibung haben k nnen Dar ber hinaus gibt es mehrere verschiedene formale Be schreibungstechniken f r die Modellierung eines Systems Der Analysierende w hlt f r die Beschreibung meist den Formalismus den er selber am besten beherrscht Die Eignung des gew hlten Formalismus f r die durchzuf hrende Untersuchung sollte jedoch das prim re Kriterium f r die Auswahl sein Mangelhafte Werkzeugunterst tzung F r alle Analysemethoden gibt es
175. ionen zum Filtern Die Funktionen zum Filtern der Rohdaten sind bisher noch keinem Proze zugeordnet worden In Abschnitt 4 4 5 1 wird darauf eingegangen Unabh ngig davon wann und wo gefiltert wird m ssen die Filterfunktionen entworfen werden Der Entwurf der Filterfunktionen wird in Abschnitt 4 4 5 2 dargestellt 4 4 5 1 Zeitpunkt des Filterns Die weiter oben diskutierten Funktionen konnten bereits Prozessen zugeordnet werden Funktionen zum Filtern der Rohdaten sind ebenfalls unbedingt erforderlich vgl Ab schnitt 2 7 4 Die Zuordnung zu einem Proze kann an dieser Stelle jedoch noch nicht entschieden werden Das Filtern sollte so fr h wie m glich geschehen um die Last durch Rohdaten im Werkzeug zu verringern vgl Abschnitt 1 3 2 1 Insbesondere vor Ausf hren der Analysefunktionen ist eine Reduktion der Rohdaten w nschens wert Die beiden folgenden M glichkeiten zum Ausf hren der Filterfunktionen sind denkbar 1 Filtern im Pakettr ger Die Filterfunktionen werden unmittelbar vor dem Aufruf der Analysefunktionen ausgef hrt 2 Filtern im Proze zur Rohdatenerfassung Unmittelbar nach der Rohdatenerfas sung werden die Filterfunktionen aufgerufen Das Filtern im Pakettr ger hat den Vorteil analog zur Paketparallelit t ein paralleles Filtern der Dateneinheiten zu erm glichen Es g be in diesem Fall eine der Anzahl der Pakettr ger entsprechende Anzahl an Filterfunktionen Dieses Vorgehen ist an gebracht wenn das
176. is zur physi kalischen Adresse Das bedeutet eine wesentliche Erleichterung f r den Benutzer der bei der Eingabe von Rechneradressen i d R symbolische Namen bevorzugt 16Eine berpr fung auf mehrfache Adre vergabe kann auch automatisch erfolgen KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 114 0 31 Hardware Typ 16 bit Protokoll Typ 16 bit 63 HLEN 8 bit PLEN 8 bit Funktion 16 bit E 95 physikalische Senderadresse Byte 0 3 127 physikalische Senderadresse Byte 4 5 IP Senderadresse Byte 0 1 159 IP Senderadresse Byte 2 3 physikalische Empf ngeradresse 191 physikalische Empf ngeradresse Byte 2 5 223 IP Empf ngeradresse Byte 0 3 Abbildung 5 11 R ARP Dateneinheit vgl Com91 S 80 5 3 2 4 Realisierung der Analysefunktion f r Datagramme IP Dateneinheiten Datagramme sind die Grundlage aller Daten bertragungen in nerhalb der TCP IP Protokollfamilie Datagramme und ARP RARP Dateneinheiten sind die einzigen Dateneinheiten der TCP IP Protokollfamilie die unmittelbar in Ethernet Frames eingebettet werden Alle anderen Dateneinheiten dieser Protokoll familie werden in Datagramme eingebettet Identifiziert wird ein Datagramm durch den Eintrag 080016 im Typ Feld des Ethernet Frame Das in Abbildung 5 12 dargestellte Nachrichtenformat hat nur einen konstanten Eintrag Das Feld VER Version gibt die aktuelle Versionsnummer f r Datagramme laut RFC 791 an und mu den Wert vier 4
177. isierbar berpr fun gen des gew hlten Dateinamens und Betriebssystemaufrufe zum ffnen Schreiben und Schlie en der Datei sind einfach realisierbar Die Ausgabe von Text in Fenstern wurde als abstrakter Datentyp implementiert Der Ringpuffer die Funktionen f r obige Berechnungen und die Funktionen zur Aus gabe in Fenstern und Dateien sind vollst ndig gekapselt Weitere Textfenster k nnen bei Bedarf erstellt werden Die Benutzung ist trivial Der Aufruf der Funktion wprintf schreibt in das als Parameter zu bergebene Fenster Die weiteren Parame ter und deren Bedeutung sind identisch mit der in C bekannten printf Funktion 5 3 4 3 Realisierung eines benutzernahen Datenexports Mit Hilfe von Umwandlungsfunktionen werden die Me daten in ein lesbares Format verschriftlicht und anschlie end in eine Datei geschrieben Das Verschriftlichen der Analysedaten geschieht durch das Markieren jeder Information mit einer Beschrei bung die das folgende Datum identifiziert Dadurch kann ein Benutzer leicht die Bedeutung des jeweiligen Datums identifizieren Dar ber hinaus wird beim Export darauf geachtet da die Zeilenl nge 80 Zeichen nicht berschreitet Eine solche Datei kann dann mit jedem g ngigen Editor angezeigt und auf jedem Drucker ausgedruckt werden Das folgende Beispiel zeigt einen Auszug aus einer Datei mit benutzernahen Protokollinformationen ETH_ANALYSER MODUS protokollieren Gewa
178. isse ber sichtlich und kompakt dargestellt werden Auch die Darstellung sich schnell ndernder dynamischer Prozesse ist in der Regel nur graphisch m glich In diesem Fall ist das Me objekt immer ein Teil des Kommunikationssystems KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 18 1 3 2 5 Verwalten der Daten Das Verwalten der Daten ist erforderlich wenn auf sie ber l ngere Zeit zugegriffen werden soll Bei Messungen die sehr gro e Datenmengen in kurzer Zeit erheben ist trotz Filtern s o meist keine Analyse und Anzeige der Daten in Echtzeit m glich Daher ist es n tig die anfallenden Daten auf Massenspeicher f r eine sp tere Weiter verarbeitung zwischenzulagern In Verteilten Systemen k nnen Messungen parallel an verschiedenen Stellen Sub systemen erfolgen Zum Verwalten der Daten geh rt in diesem Fall auch die de zentral anfallenden Daten lokal f r eine Auswertung bereitzustellen Hierzu geh rt beispielsweise das Zusammenf hren verschiedener Me reihen durch Sortieren der er fa ten Daten Ein weiterer Aspekt der Datenverwaltung ist eine Zugriffskontrolle bei sensiblen Daten 1 3 2 6 Aktives Testen Aktives Testen von Komponenten durch einen Monitor kann f r verschiedene Me auf gaben eingesetzt werden Beispielsweise kann durch einen Lastgenerator eine spezifi sche Last f r das Kommunikationssystem f r Lastmessungen s u generiert werden Bei Protokolltestern s u simulier
179. ite zu bergebene Parameter ist ein Zeiger auf den Speicher platz f r die Analyseergebnisse der aufgerufenen Analysefunktion Dazu addiert die aufrufende Funktion ihren eigenen Speicherbedarf zu dem ihr bergebenen Zeiger Mit anderen Worten die aufgerufene Funktion legt ihre Ergebnisse un mittelbar hinter die Analyseergebnisse der aufrufenden Funktion im Speicherbe reich ab Die aufgerufene Funktion terminiert mit einem R ckgabewert der ihren eigenen Speicherbedarf und den Speicherbedarf iterativ aufgerufener Analysefunktionen angibt Berechnen des Gesamtspeicherbedarfs Dieser Wert setzt sich zusammen aus dem eigenen Speicherbedarf f r Analyseergebnisse s o und dem R ckgabewert der Analysefunktion des eingebetteten Protokolls Terminieren und bergeben des Gesamtspeicherbedarfs an die aufrufende Funk tion In Abbildung 5 9 ist der Algorithmus noch einmal als Nassi Schneiderman Diagramm dargestellt 12 n OSI Terminologie Es mu ein Zeiger auf die n SDU der aktuellen n PDU berechnet werden Die n SDU ist gerade die n 1 PDU also das Rohdatum f r die folgende Analysefunktion KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES w N OO JO OI A 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Sollen Analyseergebnisse f r dieses Protokoll angefertigt werden J N berechne den eigenen Speicherbedarf eigener Spei cherbedarf 0 berechne und speichere die Analyseergebnis
180. itliche Verh ltnis zwischen verf gbarem System und nicht verf gbarem bzw teilweise verf gbarem System ist Leistungsf higkeit Komplexere Anforderungen der Benutzer ben tigen immer leistungsf higere Kommunikations und Rechensysteme Bei der Analyse der Leistungsf higkeit soll in der Regel festgestellt werden welchen Durchsatz ein System bei der Abarbeitung verschiedener Auftr ge hat Zuverl ssigkeit Die Kommunikation sollte zuverl ssig sein Hiermit ist insbe sondere fehlerfrei gemeint Erweiterbarkeit Durch neue Aufgaben oder h here Leistungsanforderungen kann es n tig werden ein Kommunikationssystem zu erweitern Beispielsweise m ssen neue Segmente in ein vorhandenes Netz aufgenommen werden um weitere End ger te anzuschlie en Auch die Integration neuer oder ge nderter Protokolle ist ein Aspekt der Erweiterbarkeit Die quantifizierbaren Benutzer Anforderungen eignen sich besonders gut als Be wertungskriterien f r Kommunikationssysteme Anhand quantifizierbarer Gr en wie Verf gbarkeit und Leistungsf higkeit k nnen verschiedene geplante Systeme mit einander verglichen werden vgl Wo193 S 5 Die Analyse als Grundlage f r die Bewertung eines Kommunikationssystems wird ben tigt um entscheiden zu k nnen ob die Anforderungen der Benutzer von einem geplanten vorhandenen Kommu nikationssystem erf llt werden k nnen bzw wie ein Kommunikationssystem aussehen m te um die Anforder
181. l der verwendeten Transputer Schon f r wenige Prozessoren lohnt sich das Konzept der Paketparalle lit t Dies ist ein Vorteil gegen ber der Schichtenpipeline bei der mindestens so viele Prozessoren vorhanden sein sollten wie zu analysierende Protokollschichten Kapitel 4 Entwurf des Me werkzeuges In diesem Kapitel wird das Me werkzeug entworfen Dazu werden in Abschnitt 4 1 die Restriktionen durch die Hardware beschrieben da durch diese Restriktionen die Freiheiten beim Entwurf festgelegt werden Anschlie end wird eines der Konzepte der parallelen Protokollverarbeitung f r eine Adaption an die parallele Protokollanalyse ausgew hlt vgl Abschnitt 4 2 Durch die Festlegung des Konzeptes zur parallelen Protokollanalyse kann dann in Abschnitt 4 3 die Grobgliederung des Me werkzeuges unter Ber cksichtigung der Restriktionen durch die Hardware angegeben werden Eine Verfeinerung der Grob gliederung f hrt in Abschnitt 4 4 zum Entwurf der essentiellen Funktionen Diese Funktionen dienen direkt der Realisierung der Benutzeranforderungen und sind daher unverzichtbar f r das Me werkzeug Neben den essentiellen Funktionen werden unterst tzende Funktionen in Abschnitt 4 5 entworfen Diese Funktionen unterst tzen die essentiellen Funktionen bei ihrer Arbeit Abschlie end werden die Funktionen in Abschnitt 4 7 klassifiziert um die Ergebnisse des Entwurfs zusammenzufassen bevor in Kapitel 5 die Realisierung des Me werkzeuges dargestel
182. l wieder durch die geringe Aussagekraft der Dies sind sogenannte Trap Instructions I d R wird der Programmz hler und somit die Ausf hrung des Programms durch Trap Instructions auf den Monitor gesetzt rap Instructions sind abh ngig vom Prozessortyp engl Trace Mode 14 Beispielsweise eine erneute bersetzung der Programmquellen des SW Monitors auf dem zu un tersuchenden System 15Der Begriff Ereignis wird weiter unten eingef hrt KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 23 Me ergebnisse ausgeglichen Beispielsweise kann ein HW Monitor gut den Durchsatz in Bit s einer Leitung messen Das Erkennen der Struktur der bertragenen Informa tionen leisten HW Monitore jedoch nicht F r eine weitere Diskussion siehe Jai91 S 98ff 1 4 2 4 Firmware Monitor Ein Firmware Monitor ist Teil des Mikrocodes eines Prozessors Seine Funktion beschr nkt sich meist darauf die H ufigkeit f r das Auftreten bestimmter Maschinen befehle zu z hlen Auf Firmware Monitore wird nicht weiter eingegangen 1 4 2 5 Hybrid Monitor Ein Hybrid Monitor ist eine Kombination aus HW und SW Monitor Man ver sucht durch einen Hybrid Monitor die Vorteile von HW und SW Monitor zu vereinen vgl Lip88 S 33 G ngige Realisierungen benutzen spezielle Hardware f r den Empfang und die Auswertung der Me daten sowie f r Schnittstellen am Me objekt ber die programmgesteuert die Me date
183. le Prozesse Ober mir Lokationstransparenz Ein Proze kann seine Nachricht unabh ngig davon ver mitteln lassen ob der Empfangsproze auf demselben Prozessor plaziert wurde oder auf einem anderen Der Prototyp benutzt sieben der 16 Vermittlungs bits VBs Sollte sich bei Er weiterungen herausstellen da 16 VBs nicht ausreichen um alle Proze gruppen zu adressieren gibt es zwei M glichkeiten f r eine Erweiterung des Adre bereiches e Das Tag Feld vgl Abbildung 5 20 kann beispielsweise auf 64 bit vergr ert werden Man h tte dann 48 VBs Diese Methode w rde nur kleine nderungen in den Programmquellen erfordern e Indizieren einer Vermittlungstabelle mit den vorhandenen VBs Die VBs w rden als Zahl interpretiert werden die als Index in eine Vermittlungstabelle mit Weg wahlinformationen dient Mit den vorhandenen 16 VBs k nnte man maximal 65536 Eintr ge in der Vermittlungstabelle indizieren Durch die oben getroffene Wahl jedem VB eine Proze gruppe zuzuordnen ist die Vermittlungstabelle sehr einfach strukturiert und berschaubar 5 4 2 Realisierung der Verteilungsfunktionen Bei diesem Prototypen sollen eintreffende Dateneinheiten gleichm ig auf die Pa kettr ger aufgeteilt werden Au erdem sollen die Dateneinheiten abwechselnd auf beide Pakettr ger verteilt werden Auf Grundlage der Vermittlungsfunktionen ist die Verteilung trivial realisierbar Es wird ein Vermittlungs bit f r d
184. lele Protokollverarbeitung eingegangen Die Motivation f r die Diskussion verschiedener Ans tze der parallelen Protokollverarbei 174 KAPITEL 8 ZUSAMMENFASSUNG UND AUSBLICK 175 tung war die Idee eines dieser Konzepte f r die parallele Protokollanalyse anzupassen Ein weiterer Schwerpunkt des dritten Kapitels bildete die Darstellung der verf gbaren Parallelrechner und der Restriktionen durch diese Hardware Der Entwurf eines parallelen Me werkzeuges wurde im vierten Kapitel dargestellt Es zeigte sich da der Entwurf von den Restriktionen durch die Hardware einer seits und dem gew hlten Konzept zur Parallelverarbeitung andererseits gepr gt ist W hrend des Entwurfs wurden zwei verschiedene Klassen von Funktionen vorge stellt Die essentiellen Funktionen wurden entworfen um die wesentlichen parallel auszuf hrenden Aufgaben des Me werkzeuges zu realisieren Die unterst tzenden Funktionen wurden entworfen um die Infrastruktur zu realisieren auf der die es sentiellen Funktionen aufbauen Die einzelnen Entwurfsentscheidungen wurden mit den Anforderungen an den Prototypen und den Restriktionen durch die Hardware begr ndet Es konnte eine erste Grobgliederung des Prototypen durch Prozesse vor gestellt werden In Kapitel 5 wurden die Prozesse auf Grundlage eines allgemeinen Proze Temp late verfeinert Das Zusammenwirken der einzelnen Funktionen in den Prozessen wurde anhand der Implementation diskutiert Die wichtigsten Alg
185. ler anderen Prozesse auch deren Zugeh rigkeit zu den verschiedenen Gruppen kennen KAPITEL 4 ENTWURF DES MESSWERKZEUGES 86 Idle Prozessor x Idle Prozessor y 1 1 4 1 1 1 Nachricht Nachricht Nachricht Nachricht senden empfangen senden empfangen 5 z 1 sendebereit auf Rendezvous empfangsbereit sendebereit auf Rendezvous empfangsbereit IT mit dem Kommuni 2 mit dem Kommuni 2 kationspartner kationspartner warten warten 1 1 2 1 j Ser 1 TS1 Nachricht Nachricht Nachricht Nachricht TS1 senden empfangen senden empfangen j 1 1 1 Rendezvous beendet A Rendezvous beendet 1 1 Nachbear Nachbear beitung beitung Abbildung 4 4 Verklemmung beim Nachrichtenaustausch Die Vermittlungsfunktionen sollen folgende Funktionalit t umfassen e Empfangen von Nachrichten ber ausw hlbare Kommunikationskan le Ein Kom munikationskanal ist dabei entweder einer der Transputerlinks vgl Abschnitt 3 2 1 4 oder ein interner Kanal eines anderen Prozesses Vermitteln von Nachrichten ber die ausgew hlten Kommunikationskan le gem einer Vermittlungstabelle Unterst tzen von Multieast und Broadcast Nachrichten Entkoppeln der Sendefunktionen von den Empfangsfunktionen zur Vermeidung von Verklemmungen beim Nachrichtenaustausch vgl Abbildung 4 4 Darauf aufbauen k nnen spezielle
186. lescher Wahrheits Wert sein der angibt ob das Rohdatum der Spezifikation durch den Benutzer gen gt Die Codegenerierung erzeugt aus den Regeln P Code f r eine Stapelmaschine die folgende Befehle kennt e rel_opr Vergleiche gem rel_opr und lege das Ergebnis auf den Stapel Eine Eins repr sentiert einen erfolgreichen Vergleich eine Null einen nicht erfolgrei chen Vergleich e puschand Verkn pfe die beiden obersten Werte des Stapels mit der logischen Operation AND und lege das Ergebnis wieder auf den Stapel Diese Junktorenmenge ist nicht vollst ndig Das fehlende un re nicht kann jedoch durch die Klammerung und die relationalen Operatoren ausgedr ckt werden so da beliebige boolesche Funk tionen realisierbar sind KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 131 e pushor Verkn pfe die beiden obersten Werte des Stapels mit der logischen Operation OR und lege das Ergebnis wieder auf den Stapel e pop Hole den obersten Wert vom Stapel Dazu wird w hrend der syntaktischen berpr fung der Benutzereingabe ein Ablei tungsbaum erstellt der es einer anschlie enden Funktion f r die P Code Generierung erm glicht die Infix Ausdr cke in die f r die Stapelmaschine notwendige Postfix Notation umzuwandeln 5 3 5 2 Realisierung eines P Code Interpreters f r Filterausdr cke Anhand eines Beispiels wird das Ergebnis der Codegenerierung verdeutlicht Der f
187. line der eventuell aus vorangegangenen sequentiellen Realisierungen vorhandene Programmcode bei einer Anpassung verwendet werden Der Hauptnachteil dieses Konzeptes ergibt sich aus der geringen Leistungsf higkeit bei wenigen Verbindungen Sind weniger Verbindungen als Prozessoren vorhanden k nnen die brachliegenden Prozessoren nicht zur Beschleunigung beitragen Au erdem werden die Prozessoren im allgemeinen nicht gleichm ig ausgelastet da verschiedene Verbindungen typischerweise auch verschiedene Lasten generieren Bei sich schnell auf und abbauenden Verbindungen kann es au erdem dazu kommen da einzelne Prozesse mehrere Verbindungen verwalten w hrend andere deren Verbin dungen zwischenzeitlich abgebaut wurden nicht ausgelastet sind Diese drei Nachteile vermeidet der Ansatz der Paketparallelit t s u Allerdings gibt es bei der Verbindungsparallelit t keine protokollspezifische Inter KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 65 proze kommunikation da verschiedene Verbindungen i d R v llig unabh ngig vonein ander sind Dennoch f llt Overhead an da die verschiedenen Prozesse nicht nur die Protokollanalyse leisten sondern zuvor die Dateneinheiten hrer Verbindung selektie ren m ssen Will man dies effizient realisieren m te man eintreffende Dateneinheiten in gemeinsamen Speicher legen so da alle Prozesse die M glichkeit haben nebenl ufig auf Zugeh rigkeit zu ihrer Verbindung zu pr fen
188. lleinbettung indirekt zug nglich f r Mes sungen vgl Abbildung 4 2 TEs werden gegebenenfalls Dateneinheiten einer Protokollschicht in Dateneinheiten einer ande ren Protokollschicht eingebettet Entsprechend werden Dateneinheiten eines Protokolls erkannt Im folgenden wird dies durch Protokolleinbettung und Erkennen von Protokollen abgek rzt KAPITEL A ENTWURF DES MESSWERKZEUGES 76 Knoten A Knoten B Knoten n s7 s7 i s6 be s6 l s5 i 7 i s5 S4 S4 53 S3 S2 S2 S1 S1 GC S1 S7 Protokollschicht und indirekt zug ngliche Schnittstelle indirekte Messung an Knoten A Schnittstelle S6 direkte Messung am Ethernet Segment Abbildung 4 2 Direkte und indirekte Messung Zusammenfassend ergibt sich da jede Protokollschicht im Kommunikationssy stem als Schnittstelle f r Messungen zug nglich sein kann Dar ber hinaus kann die Messung auf einen Teil bzw auf Teile des Kommunikationssystems eingeschr nkt wer den Beispielsweise k nnte man nur Auftr ge eines Knotens im Netz messen oder nur Auftr ge an einer bestimmten Schnittstelle die durch Dateneinheiten eines bestimm ten Protokolls erkennbar ist 4 4 2 2 Erkennen und Analysieren von Protokollen Aufgrund des berwiegend indirekten Zugriffs des Me werkzeuges auf eine Schnitt stelle mu man beim Auswerten der Me daten in zwei Schritten vorgehen F r jede Datenei
189. ls keine Benutzerdaten vorhanden sind generiert die ATM Schnittstelle leere Dateneinheiten die versendet werden vgl BHK94 S 427 In Abbildung 8 2 ist ein typisches ATM LAN abgebildet Die Stationen sind ber einen Vermittlungsknoten sternf rmig angeordnet Durch diese Topologie hat die Posi tionierung des Me werkzeuges entscheidenden Einflu auf den beobachtbaren Verkehr im Netz Bei einer Ankoppelung an Position A kann beispielsweise nur der Verkehr von und zu Station 1 beobachtet werden Das gesamte Verkehrsaufkommen im LAN kann nur beobachtet werden wenn das Werkzeug in den ATM Vermittlungsknoten integriert wird Position B KAPITEL 8 ZUSAMMENFASSUNG UND AUSBLICK 180 Wide Area Network ee 3 Station m 1 Station m ATM Vermittlungs Knoten LI S O J A Stantion 1 Monitor Station n Abbildung 8 2 Typisches ATM LAN Ein hnliches Problem ergibt sich bei Messungen in 100VG AnyLAN Netzen Hier kann berhaupt keine globale Sicht auf das Verkehrsaufkommen durch ein Me ger t erreicht werden Die Kommunikation in einzelnen sten dieser Baumtopologie ist weitgehend unabh ngig voneinander Eine L sung k nnte eine verteilte Datenerfas sung sein An jeden Hub m te ein Modul zur Rohdatenerfassung gekoppelt werden 8 3 2 Neue Protokolle mit Verschl sselungsmechanismen Ein weiteres Problem k nnten
190. lst ndige Beschreibung einer Dateneinheit ist protokollspezifisch Eine Analyse kann demnach nur durchgef hrt werden wenn das zuvor erkannte Protokoll dem Analysewerkzeug auch bekannt ist Typischerweise kann ein Analysewerkzeug wesentlich mehr Protokolle erkennen als analysieren Dies liegt vor allem an der deutlich geringeren Komplexit t des Erken nens im Vergleich zur Analyse Die vollst ndige Beschreibung einer Dateneinheit bein haltet neben protokollspezifischen Angaben weitere Angaben Beispielsweise hat jede Dateneinheit eine bestimmte L nge in Byte die f r jede Dateneinheit verschieden sein kann L ngenangaben k nnen wiederum zu weiteren Informationen f hren Beispiels weise kann ber die L ngenangaben aller Dateneinheiten innerhalb eines bestimmten Zeitintervalls eine Brutto Last berechnet werden F r ein bestimmtes Analysewerk zeug mu entsprechend den Benutzeranforderungen festgelegt werden was zu einer vollst ndigen Beschreibung einer Dateneinheit geh rt 4 4 2 3 Anforderungen an die Analysefunktionen Die zu realisierenden Analysefunktionen m ssen f r jedes zu analysierende Protokoll entwickelt werden Entscheidend dabei ist da sie so flexibel miteinander kombinier bar sein m ssen da bei sp teren Erweiterungen m glichst keine bzw nur minimale nderungen an existierenden Funktionen vorzunehmen sind Nur so sind einfache Erweiterungen m glich Die einzelnen Analysefunktionen sollten folgendes leisten
191. lt wird 4 1 Restriktionen durch die Hardware In Abschnitt 2 7 4 wurde bereits angedeutet da veraltete Hardware eingesetzt werden mu Diese Hardware wurde in Abschnitt 3 2 vorgestellt so da hier die Restriktio nen durch die Hardware besprochen werden k nnen die bei dem Entwurf und der Realisierung des Me werkzeuges beachtet werden m ssen In der Darstellung der Hardware in Abschnitt 3 2 wurde deutlich da es zwischen Hostrechner und den Transputer Boards TBs jeweils nur eine bidirektionale Ver bindung gibt Die Verbindung des zweiten TBs vgl Abbildung 3 8 kann au erdem nur zum Laden von Programmen nicht aber zur PC Transputer Kommunikation be nutzt werden Eine weitere Restriktion ist da nur ein einziger Transputer mit dem T225 verbun den werden kann Der Zugriff der anderen Transputer auf die Ethernet Schnittstelle 67 KAPITEL A ENTWURF DES MESSWERKZEUGES 68 kann nur indirekt erfolgen Weitere Restriktionen ergeben sich durch die Anzahl der Links pro Transputer Hier stehen maximal vier Links pro Transputer zur Verf gung Der mit einem Stern markierte Transputer in Abbildung 3 7 verf gt nur ber zwei freie Links Damit sind schon bei nur vier Transputern nicht mehr alle direkt miteinander koppelbar Au erdem erkennt man auf der Abbildung da es pro TB genau vier Transpu ter gibt Die zu w hlende Konfiguration sollte also immer ein Vielfaches von vier Transputern verwenden um alle eingeset
192. mit verbundene Aufwand wird jedoch leicht untersch tzt Die Pro R ckblickend war dieses Mi trauen bertrieben Unbegr ndet war es jedoch nicht Es wurde ein gravierender Fehler in der Entwicklungsumgebung gefunden 3Ein Werkzeug zur Fehlersuche in Programmen Es erm glicht die Einzelschrittausf hrung eines Programms und das Anzeigen der Ver nderungen an Variablen KAPITEL 8 ZUSAMMENFASSUNG UND AUSBLICK 178 grammierung Einarbeitung und Implementation der Benutzerschnittstelle war zeit aufwendig und teuer Die Programmierung der rudiment ren Analysefunktionen f r die Transputer dauerte drei Tage Die Programmierung der rudiment ren Funktionen f r die Benutzerschnittstelle dauerte drei Wochen Besonders hilfreich bei der Bew ltigung der vielen Probleme war der Kontakt zu einer Vielzahl hochqualifizierter Personen ber Interessengruppen in den Net News Durch die vielen Interessengruppen lassen sich vermeintlich unl sbare Probleme darauf reduzieren die richtigen Fragen zu stellen und Informationen zu recherchieren 8 2 3 Gruppenarbeit Bei der Programmierung der Transputer erwies sich die Gruppenarbeit mit einem anderen Studenten als besonders vorteilhaft Ein regelm iger Erfahrungsaustausch bewahrte uns vor einer vielzahl unn tiger Fehler und Fehlentscheidungen bei der Pro grammierung 8 3 Offene Fragen M gliche Erweiterungen des Prototypen wurden bereits am Ende des f nften Kapitels diskutiert An dieser
193. n OK status process 0K Status PSTAT 0K Status PPAKET OR Status PPAKET OR Status PDEV OK nicht gebootet nicht terminiert Empfang nicht eingeschaltet 8 PDEV DEBUGINFO ROUTE_BROADCAST SI 9 init_tr 10 OK 11 PDEV DEBUGINFO ROUTE_DEVICE STARTUP 12 mess _arp 13 OK 14 filter eth_type arp or eth_type rarp 15 SYNTAX FEHLER 16 filter eth_type arp or eth_type rarp 17 OK 18 enable 19 OK 20 PDEV DEBUGINFO ROUTE_DEVICE NEW_FILTER 21 FILTER DEBUGINFO NEW_FILTER 22 FILTER DEBUGINFO RESET 23 PDEV DEBUGINFO ROUTE_DEVICE DEVICE_START 24 disable 25 OK not GA H r Der Benutzer kann bei entsprechender Kenntnis des Betriebssystems das Programm durch ein programm externes Kommando beenden Dieses Vorgehen ist nur sinnvoll falls der Prototyp nicht mehr auf Kommandos reagiert KAPITEL 6 ARBEITEN MIT DEM PROTOTYPEN 155 26 PDEV DEBUGINFO ROUTE_DEVICE DEVICE_STOP 27 status 28 _arp Messung DISABLED 29 OK 30 drop filter 31 OK 32 drop _arp 33 OK 34 spool off Dieses Protokoll wurde von einer Funktion erstellt die mit dem Befehl spool da teiname alle Ausgaben in das Standardausgabe Fenster zus tzlich in eine Datei der Name wird anstelle von dateiname angegeben schreibt Das Ok in Zeile 1 ist die Best tigung f r dieses Kommando Zu jeder Zeit kann der Benutzer Statusinformationen von den Prozessen erfragen Der Benutzer kann so fes
194. n Da Standardfilter zu inflexibel sind und eine Realisierung der Kombination beider Filtertechniken aus Zeitgr nden nicht m glich ist soll der Prototyp mit universellen Filtern realisiert werden Eine weitere Schwierigkeit beim Entwurf dieser Funktionen liegt darin da die Analyse und damit das Filtern der Rohdaten auf einem anderen Prozessor abl uft als die Definition der Filter Ein weiteres Problem in diesem Zusammenhang ist da beim Filtern nicht nur einfache direkt kodierbare Vergleiche durchzuf hren sind sondern ber Pr zedenzrelationen anzuordnende Kombinationen von Vergleichsoperationen Es mu demnach Codegenerierung f r das Filtern zur Laufzeit des Analysewerkzeuges m glich sein 1 Beispiele f r Standardfilter Selektiere alle IP Dateneinheiten Selektiere die Dateneinheiten des Knotens X 13Der Benutzer ben tigt demnach kein Wissen ber den Aufbau von Dateneinheiten und Knotenadressen KAPITEL A ENTWURF DES MESSWERKZEUGES 84 Da die Definition von Filtern auf einem anderen Prozessor erfolgt als das Filtern mu entschieden werden ob die Filterdefinition oder bereits generierter Programmcode an den anderen Prozessor gesendet werden soll Au erdem mu entschieden werden ob Programmcode f r einen abstrakten Prozessor sogenannter Zwischencode oder P Code oder Maschinencode f r die Transputer erstellt wird Da bei Fehlern in der Filterdefinition der Hostrechner ohnehin f r die Ausgab
195. n 7 1 5 Ma nahmen w hrend und am Ende der Messung Bewertung weiterer Komponenten 7 2 1 Grenzdurchsatz beim Filtern 72 2 Grenzdurchsatz des Pakettr gers Leistungsprognose aooaa 7 3 1 Anzahl der Prozessoren f r Ethernet Analyse 7 3 2 Anzahl der Prozessoren f r FDDI Analyse 8 Zusammenfassung und Ausblick 8 1 8 2 8 3 Zusammenfassung der Ergebnisse 8 1 1 Ein R ckblick auf die Diplomarbeit 2 22 22 8 1 2 Die wichtigsten Ergebnisse 2 2 2 non Erfahrungen bei der Realisierung 8 2 1 Probleme mit der Hardware 8 2 2 Probleme bei der Programmierung 8 2 3 Gruppenarbeit sars 4 ws 222 H EEN EN E A EI Offene Fragen 22 Comm onen 8 3 1 Die Schnittstelle f r Messungen in Hochgeschwindigkeitsnetzen 8 3 2 Neue Protokolle mit Verschl sselungsmechanismen 152 152 153 153 153 153 153 154 155 156 156 157 157 158 159 159 159 161 161 162 162 164 165 166 167 167 169 171 171 172 174 174 174 175 176 176 177 178 178 178 INHALTSVERZEICHNIS 6 Literatur 182 Tabelle der Abk rzungen 186 Abbildungsverzeichnis 2 1 3 1 3 2 3 3 3 4 3 5 3 6 3 7 3 8 3 9 3 10 3 11 3 12 3 13 3 14 3 15 4 1 4 2 4 3 4 4 4 5 5 1 5 2 5 3 5 4 5 5 5 6 5 7 5 8 5 9 5 10 Me gr en der physikalischen Schicht 2 222 220 27 Klassifikation der Zuordnung 40 Klassifikation der Zuordnungsziele 22
196. n ei gene Aufrufkonventionen beibehalten Au erdem ist kein Proze wechsel erforderlich da keine Kern Funktionen benutzt werden Diese Funktionen wurden wie oben dargestellt unter Umgehung der Kern Funktio nen realisiert Dazu war es n tig den Programmcode der Funktionen in eigenst ndige privilegierte Codesegmente zu bersetzen Die Sende und Empfangsbereitschaft des ersten Transputers kann nun durch Zugriff auf die daf r vorgesehene Ein Aus gabeadressen berpr ft werden Abbildung 5 23 zeigt diesen vereinfachten Zugriff auf Ger te Man erkennt die Umgehung der Kern Funktionen gestrichelt umrandet durch Programmcode in privilegierten Segmenten f r VO Zugriffe privileg Segment OS 2 Anwendung Ger t Abbildung 5 23 Vereinfachter Zugriff auf Ger te Bei der Realisierung der Funktionen zum Senden und Empfangen von Nachrichten mu te die Sende bzw Empfangsbereitschaft f r jedes zu bertragene Byte berpr ft werden da die Zugriffsgeschwindigkeit des Hostrechners auf die Ein Ausgabeadres sen gr er ist als die Geschwindigkeit bei der bertragung der Byte von und zum Transputer Die Sende und Empfangsfunktionen wurden so realisiert da sie Nachrichten ver arbeiten k nnen die dem Format aus Abbildung 5 20 entsprechen Damit ist sicherge stellt da die Interproze kommunikation unabh ngig davon ist ob Quelle oder Senke der Nachricht ein Proze auf dem Tr
197. n in der Praxis nie erreicht werden Dennoch k nnten alle Frames gefiltert werden wenn man nur einen Vergleich pro Frame durchf hrt Bei komplexeren Vergleichen k nnten die Filter u U zu einem dritten Engpa werden Das ist jedoch sehr unwahrscheinlich da nicht nur Frames minima ler L nge versendet werden und mit zunehmender Last auch die Wahrscheinlichkeit f r Kollisionen steigt Dadurch wird der Grenzdurchsatz eines Ethernet Segmentes von 17361 Frames pro Sekunde in der Praxis weit unterschritten Sollten die Filterfunktionen jedoch zu einem Engpa werden gibt es zwei einfache M glichkeiten diesen Engpa zu beseitigen Einerseits bietet es sich an den P Code Dies entspricht der Aufl sung des niedrigpriorisierten Zeitgebers Durch einen hoch priorisierten Zeitgeber mit einer Aufl sung von einer Mikrosekunde w re zu viel Overhead in die Messungen eingegangen KAPITEL 7 LEISTUNGSBEWERTUNG DES PROTOTYPEN 169 der Filterfunktionen vgl Abschnitt 5 3 5 1 in Maschinencode f r die Transputer zu bersetzen Dies w rde sich besonders gut auf den Grenzdurchsatz der komplexeren Filter mit vielen Vergleichen auswirken da der P Code hierf r am aufwendigsten ist Die geschachtelten Funktionsaufrufe beim Interpretieren des P Codes sind deutlich teurer als der Vergleich der Bitmuster Durch Maschinencode w re ein f nffacher Grenzdurchsatz bei komplexen Filtern wahrscheinlich Andererseits k
198. n physikalischen Verbindungen zwischen Transputern Hierbei kann angegeben werden welche Transputerlinks miteinander verbunden sind Die Ver bindung wird jedoch von diesem Programm nicht hergestellt Daf r ist die in Abschnitt 5 3 4 5 beschriebene Funktion zu verwenden e Benennen von Prozessen und plazieren der Prozesse auf die zuvor benannten Transputer Der Benutzer macht diese Angaben in einer Datei Konfigurationsskript Das config Programm berpr ft anhand der Datei ob die benannten Prozesse als Bin r dateien existieren und ber die Verbindungen auf die entsprechenden Transputer plaziert werden k nnen Die Prozesse werden dann in eine Programmdatei kopiert und mit einer Bootstrap Funktion versehen Diese Bootstrap Funktion l dt die Prozesse nach dem Laden der Programmdatei auf den an die PC Schnittstelle ange schlossenen Transputer s o Ladefunktion ber die physikalischen Verbindungen der Transputer untereinander auf die vom Benutzer festgelegten Prozessoren KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 130 5 3 5 Realisierung der Filterfunktionen Bei der Realisierung der Filterfunktionen werden Funktionen zum Definieren von Fil tern von Funktionen zum Ausf hren der Filter unterschieden 5 3 5 1 Realisierung der Definition von Filtern Die Syntax der Filterdefinition ist durch folgende Grammatik terminale Symbole sind gro geschrieben nicht terminale Symbole sind klein geschrieben festgeleg
199. n von Methoden der parallelen Protokollverarbeitung f r die parallele Pro tokollanalyse 3 3 3 Klassifikation der parallelen Protokollverarbeitung Eine m gliche Klassifikation der parallelen Protokollverarbeitung geht von der hierar chischen Schichtenstruktur des Open System Interconnection Reference Model aus Dieses Referenzmodell OSIRM beschreibt eine f r Protokolle typische hierarchische Anordnung die Grundlage f r die verschiedenen Ans tze zur parallelen Protokollver arbeitung ist vgl Abschnitt 3 3 2 Es lassen sich Methoden zur parallelen Protokollverarbeitung aus der Die Bedeutung ergibt sich aus dem PDU Format Dieses Format ist in einer entsprechenden Protokolldefinition festgelegt KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 58 e statischen Struktur und der e dynamischen Struktur im Referenzmodell ableiten Die statische Struktur des Referenzmodells vgl Ker92 beschreibt die Hierarchisierung der Protokolle die Dienste die die Protokolle erbrin gen sowie die Struktur und Adressierung der Instanzen die das Potential der Pro tokollverarbeitung in einem System bilden Die sich hieraus ableitbaren Methoden der Parallelverarbeitung unterscheiden sich in der funktionalen Dekomposition vgl Abschnitt 3 1 der Aufgaben bei der Protokollverarbeitung Die dynamische Struktur des Referenzmodells vgl Ker92 beschreibt das Ver halten der Kommunikationspartner bei der Daten bertragung z B das Aufbauen
200. n wird aber die Sender und Empf ngeradressen ignoriert werden k nnen 6 2 4 Durchf hren der Messung Die Me datenerfassung wird aktiviert Es werden so lange Me daten erhoben bis der Benutzer die Messung unterbricht Nach einer Unterbrechung kann die Messung erneut gestartet oder beendet werden Der Benutzer unterbricht eine Messung in der Regel um einen neuen Filter einzugeben oder um die Messung zu beenden 6 2 5 Beenden einer Messung Nach dem Unterbrechen kann der Benutzer eine Messung beenden Dadurch werden alle Betriebsmittel die f r die Messung reserviert wurden wieder freigegeben Der Name der Messung ist nach dem Beenden nicht mehr g ltig Nach dem Beenden einer Der Name kann f r eine weitere Messung erneut vergeben werden KAPITEL 6 ARBEITEN MIT DEM PROTOTYPEN 154 Messung kann der Benutzer das Programm beenden W hrend der Me datenerfassung ist das Beenden des Programms nicht erlaubt Ein Versuch das Programm w hrend der Me datenerfassung zu beenden wird mit einer Fehlermeldung vom Prototypen abgelehnt In den folgenden Abschnitten werden zwei Fallbeispiele f r die Durchf hrung von Me experimenten gegeben In Abschnitt 6 3 werden ARP RARP Dateneinheiten aus gewertet In Abschnitt 6 4 wird eine Lastmessung durgef hrt 6 3 Fallbeispiel I Analysieren von ARP RARP Daten einheiten Das folgende Protokoll einer Messung zeigt wie das Analysieren von ARP RARP Dateneinheiten durchgef hrt werden kan
201. n zum Hardware Teil gesendet werden Die programmgesteuerte Datenerfassung nutzt die Vorteile der SW Monitore Durch die externe Weiterverarbeitung der Me werte wird jedoch die Beeinflussung des Me ob jektes minimiert 1 4 3 Klassifikation nach dem Funktionsumfang Diese Klassifikationsm glichkeit wurde in Abschnitt 1 3 2 7 kurz angesprochen Es handelt sich bei dieser Klassifikation um den Versuch wesentliche Funktionsmerkmale zusammenzufassen Im Gegensatz zur Klassifikation nach der Me aufgabe ergibt sich so eine abgeschlossene Einteilung der Werkzeuge vgl Wo0193 S 16 e Me instrument Ein Werkzeug mit Komponenten zur Datenerfassung und Da tenreduktion e Me datenerfassungsger t Ein Me instrument erweitert um Funktionen zur An zeige der Daten e Me datenerfassungs und analyseger t MEAG Ein Me datenerfassungsger t mit Komponenten zur Datenanalyse Diagnoseger t Ein MEAG erweitert um Diagnose und Testeinrichtungen Performance Managementsystem Ein MEAG erweitert um Netzadministrati onsfunktionen Ein Nachteil dieser Klassifikation ist da eine strikte Zuordnung eines Monitors zu ei ner dieser Kategorien diesen eventuell unterbewertet Beispielsweise w re ein Werk zeug mit Funktionen zur Datenerfassung reduktion und analyse kein MEAG da ihm KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 24 die Funktionen zur Anzeige fehlen Dies ist jedoch bei Werkzeugen die im Hintergrund a
202. nalit t verf gen Man erreicht eine vollst ndige Kapselung aller Analysefunktionen kann jedes Rohda tum von einem beliebigen Pakettr ger analysieren lassen und braucht bei Erweiterun gen um neue Analysefunktionen keine Fallunterscheidungen bez glich des Typs eines Pakettr gers treffen Die Realisierung des Prototypen und zuk nftige Erweiterungen werden so erleichtert 4 3 2 3 Prozesse f r globale Statistiken Die Analyseergebnisse fallen dezentral bei den Pakettr gern an Durch diese Eigen schaft der Paketparallelit t ergibt sich die Notwendigkeit die dezentral anfallenden Daten vor der Weitergabe an den Benutzer zu sammeln um globale Berechnungen durchf hren zu k nnen F r das Bewerten der Analyseergebnisse vgl Abschnitt 1 3 2 3 kann es ebenfalls erforderlich sein alle Analyseergebnisse zentral zusammen zuf hren Alle Berechnungen die auf bisher angefallenen Analyseergebnissen dur gef hrt werden m ssen werden in einem Proze f r die globale Statistik gekapselt Voraussetzung hierf r ist eine entsprechende Anzahl Me f hler hier Ethernet Schnittstellen wie in Abbildung 3 8 dargestellt Bei nur einem Analyseproze k nnte man nicht von Paketparallelit t sprechen da alle Daten einheiten sequentiell von diesem einen Proze ausgewertet werden m ten Die Analyseprozesse werden im folgenden als Pakettr ger bezeichnet KAPITEL A ENTWURF DES MESSWERKZEUGES 71 4 3 2 4 Proz
203. nander und unabh ngig vom Server Proze Der Server Proze stellt die Funktionen des Ger tetreibers zur Verf gung die von den Clients angefor dert werden k nnen vgl SGS91 Der Server Proze mu im Verlauf der Initialisierung des Werkzeuges von einem anderen Proze ber den Transputerlink des T225 von seinem Nachbarprozessor ge laden werden vgl Abschnitt 5 2 2 Dies wird von einer Funktion auf PDEV ber nommen Die Aufteilung des Ger tetreibers in Server und Olient Prozesse ist in Abbildung 5 8 dargestellt KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 106 Sende Client Sendefunktionen Empfangs funktionen Ger tetreiber Server S Proze Interproze kommunikation Empfangs Client Abbildung 5 8 Ger tetreiber als Cents und Server 5 3 1 1 Realisierung des Empfangs Clients Ein Sende Client wird zur Zeit nicht ben tigt Das Werkzeug verh lt sich v llig passiv Es beeinflu t das Netz in keiner Weise vgl Abschnitt 2 7 4 Der Empfangs Client mu hingegen die Initialisierung und Konfigurierung der Schnittstelle veranlassen Dazu l dt er den Server auf den T225 der Ethernet Schnittstelle initiiert die Selbsttest der Schnittstelle und konfiguriert die Schnittstelle Die Funktion des Empfangs Client bernimmt die Ablaufkoordinierung von PDEV Beim Konfigurieren wird die Ethe
204. nehmen Teilweise lassen sich auch automatisch inh rente Par allelit ten vgl Abschnitt 3 1 1 erkennen und dementsprechend als eigenst ndige Prozesse realisieren Ein Beispiel daf r w re die Parallelisierung einer sequentiellen Wiederholungsanweisung Diese Methode ist e hardwareunabh ngig Der entsprechende bersetzer mu nat rlich f r die Ar chitektur verf gbar sein 3Eine genaue Anzahl von Prozessen und Prozessoren kann man freilich nicht angeben Je nach Er fahrung zur Verf gung stehender Werkzeuge und Komplexit t der Verkn pfungen einzelner Prozesse oder Prozessoren kann eine Grenze f r das Menschenm gliche angegeben werden Beispielsweise OCCAM Concurrent Prolog Linda u a vgl Pen92 Car88 KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 43 e kaum fehlertr chtig bersetzer werden h ufig benutzt Fehler durch falsche Zu ordnungsalgorithmen der bersetzer werden meist bei Folgeversionen des Uber setzers behoben e f r viele Prozesse und Prozessoren geeignet Dies setzt eine gewisse Skalierbarkeit der Zuordnungsalgorithmen des bersetzers voraus Vorteilhaft bei wachsender Prozessorzahl ist auch eine regul re Verkn pfung der Prozessoren beispielsweise konstante Anzahl von Nachbarn f r alle Prozessoren e auch f r unge bte Parallel Programmierer geeignet 3 1 4 3 Zuordnung zur Ladezeit Das Betriebssystem des Parallelrechners sofern vorhanden kann die Zuordnung sel
205. ner anschlie enden Analyse folgende Werte ermittelt werden 1 Gesamtl nge des Frames um gegebenenfalls die Brutto Last Utilization be rechnen zu k nnen 2 L nge des Datenfeldes um gegebenenfalls die Netto Last bzw den Protokoll overhead berechnen zu k nnen Der Protokolloverhead ist der Anteil an der Brutto Last der durch bertragen von Informationen au erhalb des Datenfeldes verursacht wird Der Protokolloverhead wird demnach durch alle nicht zum Da tenfeld geh renden Teile des Frames verursacht Er ist in diesem Fall umgekehrt proportional zur L nge des Frames Die L nge des Datenfeldes kann auch an Analysefunktionen f r eingebettete Pro tokolle optional bergeben werden Dies bietet sich vor allem in F llen an in denen das eingebettete Protokoll nicht ber eine explizite Angabe zur jeweiligen L nge der Dateneinheit verf gt Man vermeidet so aufwendige Berechnungen der L ngenangabe mittels anderer protokollspezifischer Angaben 3 Erkennen des eingebetteten Protokolls Bei Ethernet Frames ist dies trivial durch den Wert des Frame Type Feldes m glich wie in RFC 1700 spezifiziert Aus diesem Grund werden Ethernet Frames aus der Sicht einer h heren Pro tokollschicht auch als selbst identifizierende Frames bezeichnet Bei IEEE 802 3 Frames ist grunds tzlich ein LLC Frame laut IEEE 802 2 Spezifikation eingebettet vgl Abbildung
206. net Dateneinheit 7 Ein Pakettr gerproze auf einem T9000 hat einen um den Faktor 6 6 gr eren Grenz durchsatz bei den Auftr gen aus Tabelle 7 1 Es k nnen maximal 10 s ien 61Byte x S i 204918 Frames pro Sekunde bertragen werden Daraus ergibt sich folgender Bedarf an Prozessoren f r die FDDI Analyse Anzahl Prozessoren FDDI Analyse 8 T T F T T T T Prozessoren gt I 1 70 70 93 96 91 92 88 4 6 L L L L L L L i pei peiu piu pe peu 204918 Auftraege pro Sekunde Abbildung 7 8 Anzahl Prozessoren f r FDDI Analyse Trotz schnellerer Hardware werden mehr Prozessoren bis zu sieben f r die Analyse von FDDI Dateneinheiten ben tigt Au erdem werden mindestens drei Prozessoren ben tigt und der Raum f r Erweiterungen der Analysefunktionalit t ist im Mittel kleiner als bei der Ethernet Analyse vgl Abbildung 7 7 Test BHK94 S 100 IFE wird angenommen da der Grenzdurchsatz dem aus Abbildung 7 6 f r pe data entspricht Kapitel 8 Zusammenfassung und Ausblick In diesem Kapitel werden die wichtigsten qualitativen Ergebnisse der Diplomarbeit zusammengefa t vgl Abschnitt 8 1 In Abschnitt 8 2 wird auf die Erfahrungen bei der Realisierung des Prototypen eingegangen In einem Ausblick vgl Abschnitt 8 3 werden zwei offene Fragen angesprochen die bei zuk nftigen Werkzeugen der Kommunikationsme technik beachtet werden m ssen 8 1 Zus
207. neue Protokolle darstellen die die Benutzerdaten teil weise oder vollst ndig verschl sseln Ein Beispiel f r ein Protokoll mit Verschl sse lungsmechanismen ist die IP Version 6 vgl RFC 1752 Die in Abbildung 8 3 gestri chelten Bereiche der Dateneinheit sind f r ein Me werkzeug nicht zug nglich Gl cklicherweise k nnen Daten mit diesem Protokoll auch unverschl sselt bertra gen werden In der Konfigurations und Testphase eines Netzes kann ein Me werkzeug weiterhin beim Aufsp ren von Fehlern helfen Ist die Verschl sselung im normalen Netzbetrieb erlaubt sind auftretende Fehler eventuell nicht mehr maschinell zu erken nen Bei dieser Alternative zum 100 Megabit Fthernet wird ein LAN hierarchisch aufgebaut Statio nen werden ber Hubs sternf rmig angeordnet Mehrere Hubs werden hierarchisch miteinander verbunden vgl Epp95 KAPITEL 8 ZUSAMMENFASSUNG UND AUSBLICK Version spezielle Infos f r Vermittlungsrechner Datenl nge NK max Hops Senderadresse Empf ngeradresse Security Assosiation Identifier SAID Initialisierungs Vektor NK L nge reserviert gesch tzte Daten x Trailer NK n chster Kopf identifiziert die eingebetteten Daten m gliche NK IPv4 Protokoll und zus tzlich Hop by Hop Informationen Vermittlungs Informationen Fragment Informationen Authentifizierungs Informationen Gesch t
208. ng vgl Abschnitt 2 7 4 vorzubereiten Als Standardauswertung soll die Auslastung des Ethernet Segmentes periodisch angezeigt werden Die Auslastung soll entsprechend den verwendeten Pro tokollen aufgeschl sselt werden Die globale Statistik mu demnach Funktionen bereitstellen die e periodisch z B jede Sekunde lokale Statistiken der Pakettr ger sammeln e die Auslastung entsprechend der verwendeten Protokolle berechnen und e die Ergebnisse in ein Format umwandeln da dem Hostrechner eine schnelle Weiterverarbeitung z B graphische Pr sentation der Ergebnisse erm glicht Sollen zus tzlich zu dieser Standardauswertung weitere Statistiken bereitgestellt wer den kann nach dem gleichen Schema vorgegangen werden Entscheidend ist da die globale Statistik von Funktionen zur lokalen Statistik in den Pakettr gern unterst tzt wird s o Der globale Statistikproze k nnte zum Engpa im Prototypen werden wenn er alle Rohdaten selber statistisch auszuwerten h tte 4 4 A Entwurf der essentiellen Funktionen f r den Hostrechner Aus der Darstellung in Abschnitt 4 3 2 4 geht hervor da der Hostrechner Host viele verschiedene Funktionen bereitstellen mu um die e Interaktion mit dem Benutzer zu erm glichen die e Analyseergebnisse darzustellen und zu exportieren und die e Konfigurierung der Transputer vorzunehmen Ausnahmen bilden Konfigurationen mit nur einem Pakettr gerproze In diesem Fall
209. ng Eintr ge f r Drucker in einem lokalen Netz da vor allem die Drucker in unmittelbarer N he zu den Arbeitsplatzrechnern benutzt werden so k nnte dies Grundlage f r die Entscheidung sein zentrale Druckerpools aufzul sen Die so frei werdenden Drucker k nnten dann auf die R ume mit den Arbeitsplatzrechnern auf geteilt werden Verkehrs und Lastanalysen zeigen schnell potentielle Engp sse in einem Kom munikationssystem auf Wenn beispielsweise die Verkehrsanalyse in einem stark be anspruchten Teil eines Kommunikationssystems ergibt da bestimmte Gruppen von Komponenten vorwiegend untereinander kommunizieren so k nnte man die Last in diesem Teil des Kommunikationssystems verringern indem man durch Br cken oder Vermittlungsrechner die verschiedenen Gruppen voneinander trennt Das Messen des Durchsatzes soll vor allem zeigen welche Klassen von Auftr gen ein System besonders belasten Derartige Messungen k nnen Entscheidungsgrundlage f r die Beschaffung von neuen Komponenten sein die bestimmte Klassen von Auftr gen schneller oder auch sicherer bearbeiten 1 3 1 3 Erkennen von Sicherheitsrisiken Das Erkennen von Sicherheitsrisiken ist notwendig um fr hzeitig Ma nahmen zum Schutz der Anwender und deren Daten ergreifen zu k nnen Gerade offene Sy steme bieten durch ihre Vernetzung in Kommunikationssystemen eine Vielzahl an Ein bruchsm glichkeiten Neben der M glichkeit das lokale Netz von berregionalen Net
210. ngs und Verteilungsfunktionen wird in Abschnitt 5 4 1 eingegangen Die Kommunikationsunterst tzung f r den Hostrechner wird in Abschnitt 5 4 4 beschrieben Anmerkungen zu weiteren unterst tzenden Funktionen folgen in Abschnitt 5 5 5 4 1 Realisierung der Vermittlungsfunktionen Die Vermittlungsfunktionen sollen den Nachrichtenaustausch zwischen den Transpu tern und dem Hostrechner vereinfachen Die Struktur der Nachrichten mu einem festgelegten Nachrichtenformat gen gen um von den Vermittlungsfunktionen richtig interpretiert zu werden 5 4 1 1 Nachrichtenformat Um zu verstehen wie Nachrichten vermittelt werden mu zuvor das Nachrichten format f r die Interprozessorkommunikation vorgestellt werden Alle Nachrichten beginnen mit einer L ngenangabe die die Gesamtl nge der Nachricht angibt Der L ngenangabe folgt eine Markierung engl Tag die den Typ der Nachricht angibt und gleichzeitig den oder die Empfangsprozesse adressiert Der Nachrichtentyp wird vom Benutzer durch ein 16 Bit Wort angegeben Er hat jedoch keine Auswirkung auf das Vermitteln der Nachricht Die verbleibenden 16 Bit des Tags entsprechen jeweils einer Proze gruppe oder einer Richtung Sie k nnen einzeln gesetzt und somit frei kombiniert werden Daraus ergeben sich 65536 verschiedene Nachrichtentypen und 16 verschiedene Proze gruppen bzw Richtungsangaben f r die Vermittlungsfunktion Das allgemeine Nachrichtenformat ist in Abbildun
211. nheit die ber die Ethernet Schnittstelle empfangen wird mu festgestellt werden ob sie auch Informationen ber eine Schnittstelle beinhaltet f r die Me da ten analysiert werden sollen Dieser erste obligatorische Schritt bei der Auswertung wird im folgenden als Erkennen bezeichnet Da die zu erkennenden Schnittstellen in diesem Fall die Schnittstellen zwischen den Protokollebenen sind mu erkannt werden ob in dem jeweiligen Ethernet Frame Dateneinheiten der zu analysierenden Proto kolle enthalten sind Der zweite Schritt ist die Analyse unter der hier das Selektieren und Berechnen von Informationen auf Grundlage von Benutzerspezifikationen aus den erkannten Dateneinheiten verstanden wird Erkennen von Dateneinheiten Ziel der Erkennung von unausgewerteten Dateneinheiten ist eine Typisierung Die Typisierung mu aufgrund der Einbettung von Dateneinheiten eines Protokolls in Dateneinheiten eines tieferliegenden Protokolls innerhalb der Protokollhierarchie ite rativ erfolgen Ist der Typ einer Dateneinheit auf der Protokollebene n erkannt worden kann eine weitere Typisierung auf der Ebene n 1 erfolgen bis schlie lich die gesamte Sequenz der sukzessive angewendeten Protokolle f r die Dateneinheit be kannt ist oder keine weitere Typisierung m glich ist Eine weitere Typisierung ist KAPITEL A ENTWURF DES MESSWERKZEUGES 77 genau dann unm glich wenn auf einer Protokollebene ein unbekanntes Protokoll ver wendet w
212. nnen von Sicherheitsrisiken Neben diesen Aufgaben s u die zum Netzmanagement geh ren k nnen Messun gen bei der Systemanalyse benutzt werden um e Sch tzwerte f r Modellparameter durch empirische Daten zu ersetzen und e Ergebnisse von Modellexperimenten mit empirischen Daten zu vergleichen z B zum Zwecke der Modellvalidierung KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 14 1 3 1 1 Erkennen von Fehlern Das Erkennen von Fehlern ist offensichtlich notwendig um den st rungsfreien und sicheren Betrieb des Kommunikationssystems zu gew hrleisten Die h ufigsten Feh lerursachen in Kommunikationssystemen sind vgl GK94 S 331 e fehlerhafte oder mehrdeutige Spezifikationen einzelner Komponenten e h here Verkehrslasten im Betrieb als in der Planung e Fehler bei der Realisierung der Komponenten Hardwarefehler und Software fehler e fehlerhafte Installation oder Konfiguration e Ausfall von Komponenten Der Fehler ist um so schwerwiegender je h her er in der Liste steht Bei einem Ausfall von Komponenten kann man den Fehler durch Austauschen der betreffenden Komponenten beseitigen Eine Anpassung des Kommunikationssystems an h here Verkehrslasten ist wesentlich umfangreicher da Teile oder auch das ganze System neu strukturiert und erweitert werden m ssen Stellen sich w hrend des Betriebs Spezifi kationsfehler heraus erfordert dies in der Regel ein aufwendiges weil nachtr gliches Neuspezi
213. nte Parallelit t eines Algorithmus als nebenl ufige Pro zesse erh lt man parallele Programme die aus einer Menge kooperierender Prozesse bestehen Der zweite Problemkomplex ist dann das Abbilden Zuordnen engl map ping der parallelen Programme bzw der Prozesse auf die Prozessoren des Parallel rechners 3 1 2 Formale Pr zisierung der Zuordnung Einige Begriffe der Zuordnungsproblematik lassen sich formal darstellen P Menge der Prozessoren P n A A1 Aa Aral Last bestehend aus einer Menge paralleler Programme T Menge der Prozesse des Programms A 1 4 3 1 Als Programmzuordnung bezeichnet man die Abbildung von der Menge der Programme A auf die Potenzmenge der Prozessoren p P da durchaus zwei oder mehr Pro gramme einem Prozessor zugeordnet werden k nnen Programmzuordnung 9 A p P 3 2 Will man eine disjunkte Abbildung der Programme auf die Prozessoren so da ein Prozessor einem Programm exklusiv zur Verf gung steht kann man eine disjunkte Die Kooperation der Prozesse besteht darin da sich zwei oder mehr Prozesse synchronisieren m ssen um beispielsweise Daten auszutauschen KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 39 Programmzuordnung durch folgende Abbildung erreichen disjunkte Programmzuordnung o A gt p P Mik g A Nnp A P9 3 3 Die Programmzuordnung ist demnach entweder disjunkt oder berlappend Die Prozessoren sind durch ihre Verbindungen unterein
214. olgende Ausdruck filter offset 0x12 0x0815 and offset 0x20 lt 0x64 or offset 0x22 gt 0x20 mit der nat rlich sprachlichen Semantik Vergleiche ob ab dem Offset 0x20 ein Wert kleiner 0x64 steht oder ob ab dem Offset 01x22 ein Wert gr er oder gleich 0x20 steht Mindestens eine dieser beiden Bedingungen mu erf llt sein Zus tzlich vergleiche ob ab dem Offset 0x12 der Wert 020815 steht wird in das Programm aus Abbildung 5 19 bersetzt Dieses Programm mu in einer Nachricht vom Hostrechner an den Proze PDEV gesendet werden der den P Code ausf hrt s u na 0x22 0x20 Em 0x20 0x64 pushor HSE 0x12 0x0815 pushand pop Abbildung 5 19 P Code eines Filterausdrucks Die Vergleiche wurden durch entsprechende Funktionsaufrufe realisiert Die eben falls auf Funktionsaufrufe abgebildeten Operationen pushand pushor und pop arbeiten auf einem last in first out Stapel Der eigentliche P Code Interpreter arbeitet die Befehle nacheinander ab und setzt sie in Funktionsaufrufe um Bei den einzelnen Vergleichen wird entsprechend der Kardinalit t des zweiten Ar gumentes verglichen In obigem Beispiel wird demnach zweimal ein Byte verglichen 0x20 und 0x64 und einmal zwei Byte 0x0815 KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 132 5 4 Realisierung der unterst tzenden Funktionen Auf die Realisierung der Vermittlu
215. ond IEEE Workshop on Future Trends of Distributed Computing Systems Cairo Agypt sep oct 1990 B E Wolfinger Analyse Optimierung und Performance Management von Kommunikationsnetzen und verteilten Anwendungen In Proceedings Net works 93 1993 E Yourdon Modern Structured Analysis Prentice Hall 1989 M Zitterbart Funktionale Parallelit t in transportorientierten Kommuni kationsprotokollen Fortschritt Berichte VDI Reihe 10 Nummer 183 VDI Verlag 1991 M Zitterbart High Speed Transport Components IEEE Network Magazine pages 54 63 jan 1991 C Zimmermann and A W Kraas Mach Konzepte und Programmierung Springer Verlag Berlin Heidelberg New York 1993 LITERATURVERZEICHNIS 186 Abk rzungen ARP ASCH ATM BER CPU CSMA CD CUA DMA DNS EA FDDI GNU HSN HW ICMP IEEE IGP IP ISO KByte LAN LLC MBit MByte MEAG MHz MIB MTU NBO NMS Address Resolution Protocol vgl RFC 826 American Standard Code for Information Interchange Asynchronous Transfer Mode Bit Error Rate Bitfehlerh ufigkeit Central Processing Unit carrier sensing multiple access with collision detection Common User Access Direct Memory Access Domain Name System vgl RFC 1034 Empf nger Adresse Fiber Distributed Data Interface GNU ist not UNIX High Speed Network Hochgeschwindigkeitsnetz Hardware Internet Control Message Protocol vgl RFC 792 Institute of Electrical and Electronics Engineers Interior Gateway
216. onen sind sehr leicht realisierbar allgorithmisch ein fach Da diese Funktionen jedoch h ufig aufgerufen werden ist eine schnelle Imple mentation erforderlich Typische Realisierungen verwenden Makros durch die der Programmcode immer an die entsprechende Stelle im Programm kopiert wird Diese Vorgehensweise ist schneller als die Verwendung von Funktionsaufrufe vgl beispiels weise CS91 S 581 Die effiziente bersetzung mu vom Compiler vorgenommen werden Alternativ kann man diese zeitkritischen Umwandlungsfunktionen in der Ma schinensprache des Prozessors programmieren In diesem Fall liegt die Verantwortung f r die Effizienz der Realisierung beim Programmierer 4 7 Klassifikation der Funktionen In diesem Kapitel wurden verschiedene Funktionen entworfen Einige dieser Funktio nen wurden als essenziell bezeichnet da sie unmittelbar der Realisierung der Benut zeranforderungen dienen Die unterst tzenden Funktionen bilden die Plattform auf der die essentiellen Funktionen aufbauen Ihre Funktionalit t soll von den essentiellen Funktionen getrennt werden um die e Modularit t zu erh hen e Realisierung und Erweiterungen zu vereinfachen und e Programm Redundanz zu vermeiden Eine weitere M glichkeit die Funktionen einzuteilen ergibt sich wenn man von den Restriktionen durch die Hardware und dem gew hlten Paradigma der Paketpar allelit t ausgeht Bei dieser Sicht ergibt sich da viele Funktionen entworfen
217. optimale L sungen sucht Erg nzend zu den hier gemachten Angaben vgl Hei94 S 95ff zu Basisalgorith men f r Zuordnungen nach bestimmten Optimierungskriterien KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 44 3 2 Verf gbare Hardware und Entwicklungsumgebung In diesem Abschnitt werden die eingesetzte Hardware HW und die verschiedenen Entwicklungswerkzeuge beschrieben die f r die Realisierung des Me werkzeuges be nutzt werden Aus der HW vgl Abschnitt 3 2 1 7 ergeben sich einige Restriktionen bez glich der Zuordnung von Prozessen zu Prozessoren die weiter unten Abschnitt 4 1 dargestellt werden Die zur Verf gung stehenden Entwicklungswerkzeuge vgl Abschnitt 3 2 2 ins besondere der einzusetzende Compiler haben starken Einflu auf die Umsetzung der Algorithmen des Me werkzeuges Der Compiler mu die vorhandene HW m glichst optimal unterst tzen 3 2 1 Transputer und Transputer Boards f r PCs Die Beschreibung der HW l t sich in drei Bereiche unterteilen Wesentlich sind die Leistungsmerkmale der parallel arbeitenden Prozessoren vgl Abschnitt 3 2 1 1 Diese sogenannten Transputer werden zusammen mit Speicher und weiteren spezia lisierten Funktionseinheiten als Transputer Boards TBs bereitgestellt vgl Ab schnitt 3 2 1 5 Diese TBs verf gen ber Busschnittstellen f r verschiedene Host rechner In unserem Fall handelt es sich hierbei um Personal Computer PCs D
218. orgenom men werden wenn Prozesse dieser Klasse mit Prozessen der neuen Klasse kooperie ren sollen Eventuell m ssen auch vorhandene Eintr ge in der Vermittlungstabelle ge ndert werden um die neue Proze klasse in eine geplante Konfiguration zu integrie ren Erweiterungen an vorhandenen Proze klassen sind in der Regel deutlich aufwands rmer da meist nur neue Nachrichten definiert werden f r die dann entsprechende Funktionen der Ablaufkoordinierung bereitzustellen sind 5 6 2 Erweitern des Werkzeuges um die Proze klasse PNOTHING Um die Arbeitsschritte zu verdeutlichen wird eine Erweiterung um die imagin re Proze klasse PNOTHING skizziert Ein Proze dieser Klasse soll nur auf Statusmel dungen antworten k nnen Minimalanforderung e Die Proze klasse ist PNOTHING Dieser Klasse wird ein bisher unbenutztes Vermittlungs bit zugeordnet Sp ter ist durch setzen dieses Bits in Nachrichten eine Gruppenadressierung der neuen Klasse m glich vgl Abschnitt 5 4 1 1 e Es soll nur einen Proze dieser Klasse geben der zwischen PSTAT und Hostre chner Proze plaziert werden soll Es mu daher einen Eintrag in die Vermitt lungstabelle f r diesen Proze geben der alle Nachrichten des Hostrechners nach PSTAT und alle Nachrichten von PSTAT zum Hostrechner weiterleitet 39Es gibt zur Zeit vier Proze klassen Alle oben dargestellten Prozesse geh ren einer eigenen dedi zierten Kl
219. orithmen wurden mit Nassi Schneiderman Diagrammen dargestellt und im Detail diskutiert Es wurde eine Methode f r systematische Erweiterungen zuk nftige Realisierungen vorge schlagen und es wurden die wichtigsten Erweiterungen benannt Mit der Darstellung der Unterschiede zwischen dem Prototypen und einem anderen Werkzeug wurde das f nfte Kapitel abgesschlossen Die Darstellung der Benutzerschnittstelle und zwei Fallbeispiele f r Messungen mit dem Prototypen waren Gegenstand des sechsten Kapitels Die Beispiele zeigten das Vorgehen zur Durchf hrung von Me experimenten Im siebten Kapitel wurde die Leistung des Prototypen bewertet Es wurden zwei Engp sse identifiziert die durch modernere Hardware beseitigt werden k nnen An schlie end wurde der Grenzdurchsatz der Filter und der parallelen Protokollanalyse mit systematisch generierten Auftr gen gemessen Diese Me ergebnisse bildeten die Grundlage f r eine Leistungsprognose beim Einsatz des Prototypen in einem Hochge schwindigkeitsnetz 8 1 2 Die wichtigsten Ergebnisse Die wichtigsten Ergebnisse k nnen erst an dieser Stelle nach der Leistungsbewer tung in Abschnitt 7 vorgestellt werden Bei der Leistungsbewertung hat sich gezeigt da man trotz veralteter Hardware mit Parallelverarbeitung in der Lage ist typische Me aufgaben der Kommunikationsme technik on line zu bew ltigen Der Hauptgrund liegt in der Wahl eines geeigneten skalierbaren Konzeptes zur parallel
220. ortable Editierm glichkeiten gegeben e D Zahlen IP Adressen etc 4 Fine ausf hrliche Beschreibung der Werkzeuge Lex und Yacc wird in LMB92 gegeben Fine praktische Einf hrung in die Benutzung der Werkzeuge findet man beispielsweise in SF85 Der detaillierte Entwurf und die Realisierung vergleichbarer Werkzeuge wird in Ho190 beschrieben 5Durch einen Austausch der Schl sselw rter k nnte man das Werkzeug an andere Sprachen anpas sen beispielsweise an Franz sisch oder Polnisch 26 F r einen ausf hrlichen Vergleich handgeschriebener Funktionen mit werkzeuggenerierten vgl Job92 Diese sogenannten Editier Fenster werden als Standardfenster von OS 2 bereitgestellt KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 123 Beispielsweise kann der Benutzer in seinem Kommando weitere Teile einf gen l schen und automatisch formatieren lassen Das Dialogelement liefert nach der Eingabe eine Zeichenkette mit der Benutzereingabe und initiiert die lexikalische und syntaktische berpr fung Bei Eingabe eines korrekten Kommandos wird die entsprechende Aktion ausgel st und das Dialogelement l scht die Eingabezeilen Ein weiteres Kommando kann ein getippt werden Eine falsche Eingabe lexikalisch oder syntaktisch falsch wird durch einen Warnton und eine Fehlermeldung im Ausgabefenster s u angezeigt In die sem Fall werden die Eingabezeilen nicht gel scht um dem Benutzer eine Korrektur zu erm glichen
221. pezifisch Eine manuelle Zuordnung mu f r jeden Parallelrechner auf dem das Programm eingesetzt werden soll erneut gemacht werden statisch Eine einmal gemachte Zuordnung ndert sich nicht ber der Zeit zeitaufwendig und arbeitsintensiv Mit steigender Anzahl an Prozessoren wird der Aufwand f r den Programmierer f r die Zuordnung gr er fehleranf llig Manuelle Zuordnungen sind fehleranf llig insbesondere weil der Programmierer die Einhaltung der Restriktionen s o selber berpr fen mu ungeeignet f r bestimmte Rechnerarchitekturen Nur f r eine berschaubare Menge von Prozessen und Prozessoren ist eine manuelle Zuordnung vorstellbar z B Anzahl der Prozessoren 100 Bei einigen Rechnerarchitekturen ist sie sogar unm glich beispielsweise bei Datenflu rechnern geeignet f r irregul r vermaschte Prozessoren Besonders bei hochspezialisier ten Topologien bestehend aus einer bestimmten Anzahl von Prozessoren mit unterschiedlichen F higkeiten ist dies oft die einzig m gliche Methode f r die Zuordnung 3 1 4 2 Zuordnung zur bersetzungszeit F r eine gro e Anzahl von Prozessoren ist eine manuelle Zuordnung zu kompliziert und zu zeitaufwendig Geeignete Werkzeuge k nnen dem Programmierer viel Arbeit abneh men Beispielsweise k nnen bersetzer f r explizit parallele Programmiersprachen Sprachkonstrukte f r parallele Anweisungsfolgen als Grundlage f r eine Zuordnung zur bersetzungszeit
222. r Trigger setzt ein bestimmtes Ma an Experten wissen voraus Eine Schnittstelle zu einem Expertensystem k nnte eventuell hilfreich sein falls das Me werkzeug zur Fehlersuche in einem heterogenen Netz eingesetzt wird das auch f r Experten aufgrund der Ger te und Protokollvielfalt un bersichtlich ist 2 4 Anforderungen an das Anzeigen der Daten Die Visualisierung der Me daten und der Analyseergebnisse ist wichtig f r eine Be wertung der Messung durch die Benutzer Grunds tzlich m ssen Me werte e tabellarisch und e sraphisch darstellbar sein Die Wahl des jeweiligen Anzeigeformates sollte immer dem Benutzer berlassen werden Typische Diagrammformen f r Me werte sind e Liniendiagramme e Histogramme e Kiviat Diagramme und e Gantt Diagramme F r eine ausf hrliche Darstellung vgl FSZ83 S 174ff Dar ber hinaus sind f r die Visualisierung verschiedener Aspekte der dynamischen Protokollverarbeitung in einem Kommunikationssystem weitere graphische Darstellungen denkbar Das Internet Control Message Protocol wird in Abschnitt 5 3 2 5 ausf hrlich beschrieben KAPITEL 2 ANFORDERUNGEN AN EIN MESSWERKZEUG 32 e Balkendiagramme Speedbars beispielsweise zum Anzeigen der gegenw rtigen Last e Jeitfolgediagramme die automatisch f r zu analysierende Verbindungen erstellt werden e Diagramme mit Darstellungen der Netztopologie Endger te Segmente Br cken Vermittlungsrechner usw 2 5 Anfo
223. r analysiert werden Die Analyseergebnisse jeder Dateneinheit werden dann an den Hostrechner gesendet vgl Abbildung 5 6 lokale Statistik zu PSTAT 5 Analysedaten Analysedaten zu PSTAT 5 lokale Statistik Analysevorgaben Paket tr ger 3 2 netznahe Statistik Ethernet Frames zu PSTAT 5 eg Uhrzeit netznahe Statistik Ringpuffer Empf nger 3 1 Analysevorgaben von 5 Ethernet Frames von 2 netznahe Statistik von 2 Uhrzeit von 2 Abbildung 5 6 Datenflu diagramm von PPAKET 5 2 5 Der Proze PSTAT Der Proze PSTAT berechnet die globalen Statistiken auf Basis der Me daten die ihm periodisch von den Pakettr gern gesendet werden Er ist hnlich simpel organi siert wie die Pakettr ger Neben den obligatorischen Threads f r die Nachrichten verwaltung gibt es auch hier nur einen weiteren Thread Auf die Informationen dieser Auswahl Nachricht wird bei der Analyse st ndig zugegriffen Sie erm glichen nicht nur die Entscheidung ob Dateneinheiten eines bestimmten Protokolls berhaupt analysiert werden sollen vgl Abbildung 5 9 sondern auch die Selektion der Protokollparameter die der Benutzer f r die Analyse ausgew hlt hat KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 103 5 2 5 1 Thread f r Statistik und Ablaufkoordinierung Die Ablaufkoordinierung reagiert im wesentlichen
224. r da der Anwender sich so vergewissern kann in welches Datei Verzeichnis die Dateien geschrieben werden die im Zuge einer Messung vom Hostrechner Proze angelegt werden Unmittelbar nach dem Start werden verschiedene Fenster des Programms auf der graphischen Oberfl che dargestellt Es handelt sich dabei um folgende Fenster mit den Fensternamen in runden Klammern e Die Standardausgabe PM STDOUT In diesem Fenster werden alle Status nachrichten der Prozesse ausgegeben Au erdem werden hier die Benutzereinga ben protokolliert Fehlermeldungen und Hinweise ausgegeben Die ARP RARP Tabelle ARP RARP Tabelle Alle Informationen aus ARP und RARP Nachrichten werden in diesem Fenster angezeigt sofern der Benutzer die ARP und RARP Protokollanalyse einschaltet Bei einer Erweiterung um Analysefunktionen f r Domain Name System Informationen k nnte man hier zus tzlich symbolische Namen zu den Adressen anzeigen e Die Auslastungsanzeige MBit s In diesem Fenster wird die Auslastung des Ethernet Segmentes auf den verschiedenen Protokollebenen angezeigt Die Ska lierung ist in Schritten von einem MB einstellbar Zus tzlich kann eine Le 146 KAPITEL 6 ARBEITEN MIT DEM PROTOTYPEN 147 gende eingeblendet werden um die farblich markierte Auslastung den Protokollen zuordnen zu k nnen e Die Benutzereingabe EINGABE Der Benutzer kann hier die Kommandos eintippen und gegebenenfalls korrig
225. r Hardware In Abschnitt 3 2 wurde die zu verwen dende Hardware HW beschrieben Ein Konzept sollte so gew hlt werden da es nicht nur trotz bestimmter Restriktionen durch die HW realisierbar ist son dern vielmehr die Vorz ge und Eigenschaften der jeweiligen HW nutzen kann Beispielsweise w re ein Konzept das von der Speichersynchronisation der par allelen Prozesse ausgeht ungeeignet um auf der vorgestellten HW realisiert zu werden 3 3 2 Vergleich zwischen Endsystem und Monitor Bei dem Versuch ein Konzept der parallelen Protokollverarbeitung f r die paralle le Analyse von Protokoll Dateneinheiten einzusetzen mu man die verschiedenen Sichtweisen auf das Kommunikationssystem kennen Ein Vergleich zwischen einem am Kommunikationssystem angeschlossenen End system einerseits und einem ebenfalls am Kommunikationssystem angeschlossenen Me werkzeug Monitor andererseits soll die unterschiedlichen Sichtweisen verdeutli chen 13 Wie in Abschnitt 3 2 dargestellt wurde beruht die Interprozessorkommunikation der Transputer auf Nachrichtenaustausch ber Kommunikationskan le und nicht auf Synchronisationsmechanismen im gemeinsamen Speicher KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 57 Endsystem Empf ngt nur Dateneinheiten mit ei gener Empf ngeradresse Normale Protokollverarbeitung Die Analyse der PDUs dient zur R ck gewinnung der eingekapselten Nach richten Protokollhierarchie zur Struktur
226. r Verbindungen auf die Pakettr ger mu allerdings durch Kooperation der Pakettr ger untereinander erfolgen Die daf r vorgesehenen Funktionen wurden in Abschnitt 4 5 2 entworfen und werden anhand von TCP konkretisiert Erkennen und Verwalten von Verbindungen Das Erkennen und Aufteilen der Verbindungen wird hier kurz anhand von TCP dis kutiert Im Prototypen ist dies bisher nicht realisiert Jeder Pakettr ger der eine Dateneinheit eines verbindungsorientierten Protokolls empf ngt mu folgende Aktionen durchf hren e Erkennen der Verbindung Bei TCP ist eine Verbindung eindeutig durch das Adre paar von Sender und Empf nger im IP Datagramm und den Portnum mern identifizierbar Feststellen ob der Pakettr ger diese Verbindung verwaltet Handelt es sich um die erste Dateneinheit eines Verbindungsaufbaus ist der Pakettr ger der diese Dateneinheit auswertet auch f r die Verwaltung der Verbindung zust ndig An dere Dateneinheiten gibt er z B mit einer Multicast Nachricht an die anderen Pakettr ger weiter Empf ngt er keine Best tigung da ein anderer f r eine weitergeleitete Daten einheit zust ndig ist ist er auch f r diese Verbindung zust ndig Ein solcher Fall tritt immer dann ein wenn eine Dateneinheit empfangen wird die zu einer Verbindung geh rt die vor Beginn der Messung aufgebaut wurde KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 121 e Optional k nnen die Pakettr ger bei geringer Ausla
227. r spezifiziert beliebige Bitmuster die an bestimm ten Positionen in den Dateneinheiten auftreten m ssen 3 Eine Kombination aus universellen Filtern und Standardfiltern Ein Vorteil der Standardfilter ist da der Benutzer nur auszuw hlen braucht wel che Dateneinheiten weiterverarbeitet werden sollen jedoch nicht wie gefiltert werden sollt Au erdem k nnen Standardfilter ber Dialogfelder einer graphischen Benut zeroberfl che s o ausgew hlt werden Ein Nachteil dieser L sung ist da Stan dardfilter a priori bei der Realisierung vorgegeben werden m ssen Es k nnen dann nur Filter ausgew hlt werden die der Entwickler bei der Realisierung als notwendig ansieht Flexibler als Standardfilter sind universelle Filter Durch diese Filter k nnen belie bige Dateneinheiten selektiert oder vernichtet werden Es sind auch keine nderungen oder nachtr gliche Erweiterungen erforderlich Der Nachteil dieser L sung ist da der Benutzer ber das Expertenwissen verf gen mu um spezifizieren zu k nnen wie der Filtervorgang durchzuf hren ist Der Benutzer mu selber die Kriterien angeben die f r die Entscheidung notwendig sind welche Dateneinheiten zu vernichten sind Alternativ kann man die Vorteile beider Verfahren kombinieren Der Benutzer w hlt weitgehend passende Standardfilter aus die in universelle Filter bersetzt wer den Die universellen Filter k nnen dann vom Benutzer ver ndert oder erweitert werde
228. rbeiten der Regelfall s u 1 4 4 Klassifikation nach dem Me verfahren Ein Monitor kann Daten entweder e ereignisgesteuert oder e zeitgesteuert erfassen Bei ereignisgesteuerten Monitoren event driven erfolgt die Datenerfassung nur nach dem Auftreten bestimmter Ereignisse im Me objekt Der Vorteil dieses Me ver fahrens ist da Daten nur dann erhoben werden wenn ein vorher definiertes Ereignis eintritt Besonders bei SW Monitoren verringert dies die Beeinflussung des Me ob jektes falls die zu erfassenden Ereignisse selten eintreten Bei h ufig eintretenden Ereignissen produziert dieses Me verfahren bei SW Monitoren erheblichen Overhead im beobachteten System Der Platzbedarf f r das Speichern der Daten ist nicht im voraus berechenbar Ein zeitgesteuerter Monitor erfa t die Daten zu bestimmten Zeitpunkten Dies geschieht meist periodisch nach Verstreichen einer definierten Zeit Ein Monitor der seine Daten zeitgesteuert sampling erfa t bietet die M glichkeit den Betriebs mittelbedarf f r die Datenspeicherung genau berechnen zu k nnen Aus der Abtast frequenz und der Anzahl der erfa ten Bit pro Abtastung kann der Speicherbedarf errechnet werden sofern die letztgenannte Datenmenge konstant ist Ein Nachteil dieser Methode ist da Ereignisse die nicht mit dem Abtastzeitpunkt auftreten auch nicht erfa t werden Die oben vorgestellte Subklassifikation der SW Monitore ist auch unter dieser Klas s
229. rchsatz in Auftr ge s Eine andere Sicht auf die Daten zeigt Abbildung 7 2 Der Durchsatz in Kilobyte pro Sekunde nimmt mit der Auftragsgr e zu Das liegt an den Vorlaufzeiten die bei jedem Kommunikationsvorgang ber einen Transputerlink als Overhead anfallen vgl Ben94 S 112 Je kleiner der Auftrag desto mehr Auftr ge erzeugen im und stehen nicht f r die Analyse zur Verf gung KAPITEL 7 LEISTUNGSBEWERTUNG DES PROTOTYPEN 164 Beobachtungsintervall hier eine Sekunde Overhead durch die Vorlaufzeiten Grenzdurchsatz an der Schnittstelle zum Hostrechner 55 T T T T T Ethernet IP UDP S 50 t 45 40 J KByte s UDP 1 0 L L L L L 0 20 40 60 80 100 120 Auftragsgroesse in Byte Abbildung 7 2 Grenzdurchsatz in KByte s 7 1 3 Vorbeugende Ma nahmen Der Benutzer sollte m glichst restriktive Filter definieren die die Menge der zu analy sierenden Dateneinheiten weitgehend reduzieren Besonders n tzlich sind hier Filter die die Anzahl der beobachteten Knoten verringern Auf der zweiten Filterstufe sollten nur die Protokolle ausgew hlt werden die tat s chlich f r die Me aufgabe analysiert werden m ssen Je mehr Protokolle ausgew hlt werden desto mehr Analysedaten werden erzeugt und desto kleiner ist der Grenzdurch satz in Auftr gen pro Sekunde beim bertragen dieser Ergebnisse an den Hostrech ner Auf dem Hostrechner sollten neben dem Hostrechn
230. rderungen an das Verwalten der Daten Die Me daten m ssen in der Regel f r eine sp tere Weiterverarbeitung verwaltet wer den Anforderungen an die Verwaltung der Me daten sind e Exportfunktionen f r die Daten e Schnittstelle zu Datenbanken e Schnittstelle zu Remote Monitoring Management Information Base RMON MIB ber das Simple Network Management Protocol SNMP e Verschl sselung sensibler Daten Besonders wichtig ist hier die Exportfunktion Alle Me und Analysedaten sollten in einem Standardformat z B US ASCII ISO Latin1 exportierbar sein Dazu werden die erfa ten Daten gegebenenfalls von einer internen Darstellung in ein Standardformat gewandelt und anschlie end in eine Datei geschrieben Die so erstellte Datei kann als Grundlage f r alle weiteren oben aufgef hrten Funktionen in externen Werkzeugen dienen Auch wenn das Me werkzeug selbst nicht in der Lage ist die exportierten Daten weiterzuverarbeiten k nnen viele externe Werkzeuge die Daten aus der Datei lesen Der Export der Daten in eine Datei ist ein allgemeines Konzept um Unzul ng lichkeiten des Me werkzeuges auf fast allen Ebenen ausgleichen zu k nnen Es kann somit auch als Grundlage f r die Erweiterung des Werkzeuges genutzt werden Rei chen die eingebauten Analyse und Anzeigefunktionen nicht aus so kann durch den Export mit anderen Werkzeugen auf die Daten zugegriffen werden Im Falle von Me ger ten f r Verteilte Systeme kommen weit
231. reiber auf bevor dieser letztendlich auf das jeweilige Ger t zugreifen kann Der Programmierer kann bei dieser Art der Realisierung ber ein generisches Ein und Ausgabekommando vgl Mue94 S 19 Beispiele f r solche Ergebnisse w ren Mittlere Dauer einer Verbindung Anzahl der Verbindun gen zu einem Knoten Summe der Verbindungsabbr che w hrend der Messung usw 20 Das Betriebssystem unterst tzt die Programmierung von Anwendungen durch diverse Funktionen u a auch durch Funktionen zur Ansteuerung der Peripherie Ger te Der nat rliche Platz f r die Funktionen zur Ansteuerung der Transputerboards w re daher im Betriebssystem des Hostrechners KAPITEL A ENTWURF DES MESSWERKZEUGES 89 357f auf das Ger t zugreifen Eine ausf hrlichere Darstellung der Einbettung von Ger tetreibern in das Betriebssystem OS 2 wird in Int89 gegeben OS 2 Anwendung Ger t Abbildung 4 5 Zugriff einer OS 2 Anwendung auf Ger te Alternativ kann man unter OS 2 auf Ger te durch privilegierte Befehle zugrei fen Der Anwendungsproze greift dabei ohne Betriebssystemunterst tzung direkt auf die Ein und Ausgabeadressen der Ger te zu Der Hauptnachteil dieser Methode ist da verschiedene Anwendungen jeweils ihre eigene Ger teunterst tzung realisieren Die Realisierung eines Ger tetreibers f r die Transputerboards wurde verworfen da hiermit ein enormer Programmieraufw
232. ren Berechnungen auf dem Prozessor vgl Zit91a S 99 Ben94 S 114f In Abbildung 5 21 ist der Algorithmus zum Vermitteln von Nachrichten dargestellt wiederhole hole n chste Nachricht aus der Warteschlange wiederhole f r alle Kommunikationskan le Mu die Nachricht ber diesen Kanal ausgegeben werden Ja Nein sende die Nachricht ber diesen Kanal Abbildung 5 21 Vermitteln von Nachrichten Ein Proze der eine Nachricht versenden m chte spezifiziert mit den Vermitt lungs bits welche Prozesse seine Nachricht empfangen sollen Danach bergibt er die Nachricht der Sendefunktion die die Weitervermittlung bernimmt Nachrichten anderer Prozesse die aufgrund ihrer Vermittlungs bits nicht f r die lokalen Prozesse eines Prozessors bestimmt sind werden f r die lokalen Verarbeitungsprozesse v llig transparent ohne deren Mithilfe weitervermittelt Die Vorteile dieser allgemeinen Vermittlungsfunktionen lassen sich wie folgt zusam menfassen e Vermeiden von Verklemmungen beim Nachrichtenaustausch KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 134 Vermitteln von Nachrichten an Proze gruppen ber beliebig viele Prozessoren nebenl ufiges Senden Empfangen und Verarbeiten der Nachrichten flexible Anpa barkeit an neue Konfigurationen durch Vermittlungstabellen relative Adressierung einzelner Proze gruppen durch Richtungsangaben m glich z B Nachricht an al
233. reuzschienenverteiler m CO OC Q O Konfigurationsbuchsen externe Verbindungsbuchsen Abbildung 3 7 Struktur eines MTM PC Board KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 5l INMOS kompatibles Board Auch dieses TB verf gt ber eine Busschnittstelle f r IBM PC kompatible Rechner und ber Buchsen f r eine TB bergreifende Vernetzung der Transputer Auf diesem TB ist jedoch nur ein einzelner T225 Transputer untergebracht der ber gemeinsamen Speicher an eine Ethernet Schnittstelle gekoppelt ist Damit ist es m glich von den Transputern direkt auf ein Kommunikationssystem zuzugreifen In Abbildung 3 8 ist dieses TB schematisch dargestellt Ethernet PC Kommunika a Schnitt Schnitt Ben tionssystem stelle stelle 64 Kbyte T225 OO CO externe Verbindungsbuchse Abbildung 3 8 INMOS kompatibles Board mit Ethernet Schnittstelle 3 2 1 6 Koppelung mit dem Hostrechner Die oben beschriebenen TB werden in IBM PC kompatible Rechner PCs eingesetzt Ein solcher PC dient als Hostrechner und stellt den Transputern seine Peripherie zur Verf gung Insbesondere sind zu nennen e Tastatur f r Benutzereingaben e Bildschirm f r Ausgaben e Massenspeicher Disketten Festplatten etc zum Speichern gro er Datenmen gen Die Ankoppelung TB an PCs erfolgt ber die oben genannten Busschnittstellen Dies
234. rkzeuge eingesetzt e der GNU Debugger zur Fehlersuche e Fast Lex ein Scanner Generator e GNU Bison ein Parser Generator e GNU make zur Projektverwaltung e GNU RCS zur Versionsverwaltung der Quelltexte Auch diese Werkzeuge sind f r alle relevanten Systeme frei verf gbar 3 2 2 2 Entwicklungsumgebung f r die Transputer Alle Programme f r die Transputer werden mit einem speziellen C Compiler erstellt Neben dem blichen ANSI C Sprachumfang stellt er transputerspezifische Funktionen zur Verf gung Durch diese Erweiterungen ist es m glich e Prozesse zu generieren und zu synchronisieren e die Kanalkommunikation der Transputer zu benutzen e die Zeitgeber der Transputer abzufragen Au erdem werden f r die Programmentwicklung ben tigt e iserver zum Laden der Prozesse in ein Transputernetz e onbe zum Beschreiben der Transputernetze und Erstellen von Ladeprogam men f r iserver Leider verf gen wir nicht ber einen Debugger f r die Transputer Die Fehlersuche in den nebenl ufigen Algorithmen ist dementsprechend aufwendiger ORs existieren Anpassungen f r praktisch alle Unix Derivate MS Dos und OS 2 sowie f r VMS Rechner Es werden au erdem diverse andere Betriebssysteme unterst tzt die aufgrund ihrer geringen Verbreitung hier nicht genannt sind TT Es handelt sich hierbei um Par C der Firma 3L Ltd 12iserver startet nur den ersten Transpu
235. rkzeugen in der Regel um bekannte Textprozessoren wie AWK SED oder PERL handelt vgl z B Ho192 wird auch in diesem Fall eine ASCII Datei erzeugt Im Gegensatz zu einer benutzernahen Aufbereitung braucht man hier keine R ck sicht auf Zeilenl ngen zu nehmen Die redundanten Markierungen s o werden durch eine einmalige Beschreibung am Anfang der Datei in einer Pr ambel ersetzt In dieser Pr ambel kann das externe Werkzeug die Bedeutung und die Reihenfolgen der abge speicherten Daten erkennen Dadurch ist eine redundanzarme Darstellung m glich die auch bei gro en Datenmengen eine kompakte Speicherung erm glicht Das fol gende Beispiel zeigt einen maschinennahen Datenexport Die erw hnte Pr ambel ist durch ein Kommentarsymbol gekennzeichnet ETH_ANALYSER MODUS Messdaten erfassen Gewaehlte Protokolle IP UDP TCP ICMP IP Sender Empfaenger Laenge Protokoll Optionenlaenge Datenlaenge UDP Quell Port Senken Port Laenge Datenlaenge TCP Quell Port Senken Port Laenge Optionenlaenge Datenlaenge Code Bits ICMP Type Code Laenge ZEIT 472 IP 134 100 15 82 134 100 9 61 40 TCP 0 20 TCP 1713 43049 20 0 O PSH ACK ZEIT 649 IP 134 100 15 82 134 100 9 61 41 TCP W 21 TCP 1713 43049 21 0 1 SYN RST PSH ACK 30Diese Textverarbeitungen laufen im batch Betrieb also ohne Benutzerinteraktion ab Sie funk tionieren nach dem einfachen Prinzip vom Benutzer definierte Anweisungsfolgen auszul sen wenn be
236. rnet Adresse der Schnittstelle eingestellt und der Empfangsmodus so eingestellt da alle Dateneinheiten unabh ngig von ihrer Emp fangsadresse empfangen werden Nur durch diese Einstellung ist es m glich das an geschlossene Netz berhaupt beobachten und somit analysieren zu k nnen Weitere Aufgaben des Empfangs Clients sind e Ein und Ausschalten des Empfangs bei Start und Ende einer Messung e Empfangen der Dateneinheiten vom Server und Ablegen in eine Warteschlange e Anfordern und Empfangen von netznahen Statistiken und Weiterleiten an den Benutzer e Reagieren auf Fehlermeldungen des Servers Die Realisierung der Funktionen f r den Empfangs Client bestand in einer Anpas sung der Funktionsbibliothek aus SGS91 an die verwendete Entwicklungsumgebungt 0Bs handelt sich hierbei um den sogenannten promiscuous mode Ee wurde ein C Compiler der Firma 3L Ltd eingesetzt Die Bibliotheken zur Ansteuerung KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 107 5 3 2 Realisierung der Analysefunktionen Im folgenden Abschnitt wird ein Template einer Analysefunktion vorgestellt Bei Erweiterungen um Analysefunktionen f r neue Protokolle sollte man sich an dieses Grundger st halten um mit den existierenden Analysefunktionen zusammenarbeiten zu k nnen In den darauffolgenden Abschnitten wird auf die speziellen Analysefunk tionen f r einige Protokolle der TCP IP Protokollfamilie eingegangen Es handelt s
237. rs 170 Anzahl Prozessoren f r Ethernet Analyse 2 22 20 172 Anzahl Prozessoren f r FDDI Analyse 2 2220 173 EDDELEAN u dus aai ra nr re par 179 Typisches ATM LAN 180 IPv6 Dateneinheit 2 Cm mn 181 Einleitung und Motivation An Me werkzeuge der Kommunikationsme technik werden immer wieder neue An forderungen gestellt Neben einer Klassifikation dieser Werkzeuge und einer Ein ordnung der Kommunikationsme technik als Analysemethode f r Kommunikations systeme wird in Kapitel 1 dargestellt welchen Anforderungen ein Me werkzeug heut zutage gen gen mu und welche Anforderungen in Zukunft durch die aufkommenden Hochgeschwindigkeitsnetze dazukommen vgl Kapitel 2 Es wird dargestellt da die Parallelverarbeitung eine M glichkeit ist um den steigenden Anforderungen an die Leistungsf higkeit zu gen gen In Kapitel 3 wird neben einer formalen Pr zisierung der Parallelverarbeitung mit der Auswahl eines Konzeptes der parallelen Protokollverarbeitung begonnen und be gr ndet warum sich dieses Konzept f r die Realisierung eines parallelen Me werkzeu ges verwenden l t Neben den Bewertungskriterien Leistungsf higkeit Skalierbarkeit und Erweiterbarkeit darf bei der Beurteilung eines Konzeptes die Hardware f r eine sp tere Realisierung nicht vernachl ssigt werden Die f r den Prototypen verf gbare Hardware und sich daraus ergebende Restriktionen werden ebenfalls in diesem Ab schnitt dargestellt Am An
238. rt werden sollten irrelevant erscheinen Da aufgrund des fehlenden Betriebssystems die Betriebsmittelverwaltung auf den Transputern jedoch von den Anwendungs Prozessen selbst bernommen werden mu bietet sich die Verwendung eines Prozesses mit mehreren Threads pro Trans puter an So k nnen sich verschiedene Threads beim Zugriff auf die Betriebsmittel aufwandsarm ber globale Variablen synchronisieren Au erdem entf llt die Realisie rung von Management Prozessen f r die oben genannten Betriebsmittel Im folgenden werden demnach Funktionen zu Threads zusammengestellt Alle Threads eines Transputers geh ren zum selben Proze Die gesamten Betriebsmittel eines Transputers werden von diesem Proze verwaltet 5 1 2 Darstellen der Prozesse mit Datenflu diagrammen In den folgenden Abschnitten wird dargestellt wie Funktionen zu Threads zusam mengestellt werden Die Nebenl ufigkeit innerhalb der einzelnen Prozesse und der Prozesse untereinander wird dadurch hinreichend dargestellt Allgemeine Definitionen von Thread und Proze werden in Tan95 S 205ff und CDK94 S 165ff gegeben Eine spezifische Darstellung am Beispiel des Betriebssystems Mach wird z B in ZK93 gegeben Die in Abschnitt 3 1 1 gemachte Definition der Prozesse als Realisierung nebenl ufiger Teilal gorithmen eines Programms ist dadurch nicht aufgehoben Vielmehr wird die Definition hier um einen operationalen Aspekt erweitert J
239. s Messung Men 6 1 1 4 Andere Men s Die Eintr ge des Hilfe Men s l sen keine Kommandos aus da bisher keine Hilfsfunk tionen realisiert wurden vgl Abschnitt 5 7 2 Die Eintr ge im Test Men werden nicht zur Durchf hrung von Messungen ben tigt Es k nnen Kommandos zur Lei stungsbewertung einzelner Komponenten ausgel st werden vgl Kapitel 7 KAPITEL 6 ARBEITEN MIT DEM PROTOTYPEN 151 6 1 2 Das Fenster Standardeingabe In dem Fenster Standardeingabe wird die Kommandozeile vgl Abschnitt 5 3 4 1 dargestellt Bei sehr langen Eingaben kann der Benutzer den Text mit dem Roll balken verschieben Am Zeilenende rechter Fensterrand wird das aktuelle Wort automatisch in die folgende Zeile verschoben Abbildung 6 6 zeigt das Fenster mit einer unvollst ndigen Benutzereingabe in der Kommandozeile EINGABE filter eth_type arp or eth_type rarp and eth_sa 0x080015470011 or eth_ra 0x080015470011 Abbildung 6 6 Standardeingabe Fenster 6 1 3 Das Fenster MBits s In diesem Fenster wird die Auslastung des Ethernet Segmentes in Megabit pro Sekunde angezeigt Auf der X Achse sind 30 Sekunden abgetragen Die Y Achse l t sich von ein bis 11 Megabit skalieren Die Auslastung durch Dateneinheiten der verschiedenen Protokolle wird als Histogramm dargestellt Die Kurven der Protokolle werden mit verschiedenen Farben dargestellt Optional kann eine Legende eingeblende
240. s f higkeit ist der Hauptgrund f r die Entscheidung ein solches Me werkzeug auf einer parallelen Rechnerarchitektur zu realisieren Ein weiterer Grund f r die Wahl einer parallelen Rechnerarchitektur ist die Einsch t zung da das Wachstum in den bertragungsgeschwindigkeiten von HSN in Zukunft Zur Zeit betrachten wir Netze mit einer Brutto bertragungsgeschwindigkeit von mindestens 100 Mbit pro Sekunde als Hochgeschwindigkeitsnetze Zur Zeit sind Prototypen von Netzen mit KAPITEL 2 ANFORDERUNGEN AN EIN MESSWERKZEUG 35 deutlich gr er sein wird als der Zuwachs der Rechenleistung neuer Prozessoren Da es schon heute kaum noch m glich ist mit einem Einprozessorsystem den Durchsatz der Netze dem Benutzer in einem Endsystem verf gbar zu machen vgl Zit91a S D I ist es h chst unwahrscheinlich da Me werkzeuge basierend auf Einprozessor Architekturen mit den bertragungsgeschwindigkeiten in Zukunft mithalten k nnen 2 7 3 Anforderungen an die Skalierbarkeit Die Einsch tzung der enormen bertragungsgeschwindigkeiten zuk nftiger Netze er fordert eine skalierbare Architektur die an die steigenden bertragungsgeschwindig keiten der Netze angepa t werden kann Die Forderung nach Skalierbarkeit schl gt sich vor allem in der Wahl eines geeigneten Paradigmas zur parallelen Protokollver arbeitung nieder Daher wird dieser Aspekt erst in den Abschnitten 3 3 3 bis 4 2 diskutiert Unmittelbar einsichtig ist da ni
241. scherweise e Eintragen und L schen von Symbolen e Auffinden von Symbolen und deren Attributen und e ndern der Attribute eines Symbols Die Ausf hrungsgeschwindigkeit der Standardfunktionen f r die dynamische Speicherverwaltung in C malloc und free vgl KR92 S 177ff ist von mehreren Faktoren abh ngig Die Lei stungsf higkeit des Prozessors die Implementation der Funktionen und der Grad der Fragmentierung der Halde von dem der Speicher genommen wird sind Beispiele f r diese Faktoren Durch eigene Messungen konnte gezeigt werden da diese Funktionen in der benutzten Entwicklungsumgebung zu langsam sind KAPITEL A ENTWURF DES MESSWERKZEUGES 91 4 6 3 Funktionen zum Umwandeln von Daten Es m ssen diverse Umwandlungsfunktionen realisiert werden Die Umwandlung von IP Adressen in Zeichenketten und vice versa ist ein Beispiel Ein anderes Beispiel ist die Umwandlung von Adress W rtern aus der Network Byte Order NBO in das Fromat das von Transputern und Hostrechner Prozessor verlangt wird Da Transputer und der Prozessor des Hostrechners die Daten in der gleichen Rei henfolge im Speicher ablegen k nnen Daten zwischen Transputer und Hostrechner ohne Umwandlung ausgetauscht werden Leider entspricht diese Reihenfolge nicht der NBO der TCP IP Protokollfamilie Es werden Umwandlungsfunktionen f r 16 Bit W rter und 32 Bit W rter ben tigt Derartige Umwandlungsfunkti
242. schriebene Empfangsfunktion vgl auch Abbildung 5 24 legt empfangene Nachrichten in den Ringpuffer Um anderen Funktionen einen ein fachen Zugriff auf die Daten im Ringpuffer zu erm glichen werden die Nachrichten jeweils zusammenh ngend abgelegt Dadurch ist sichergestellt da Nachrichten der Transputer nicht am Ringpufferende zerteilt werden Funktionen die auf diese Nach richten zugreifen wollen brauchen keine berpr fungen der Lage der Nachrichten im Ringpuffer vorzunehmen Da das Empfangen von Nachrichten m glicherweise durch einen anderen Proze realisiert wird mu der Zugriff auf den Ringpuffer durch eine Semaphore gesch tzt werden Durch diese Semaphore wird sichergestellt da Nachrichten erst vollst ndig empfangen werden bevor sie von anderen Funktionen verarbeitet werden Der gesamte Zugriff auf den Ringpuffer wird durch folgende Funktionen realisiert e Ringpuffer initialisieren Diese Funktion reserviert den Speicher f r den Ring KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 138 puffer initialisiert die Semaphore f r die Zugriffssynchronisation und initialisiert globale Variablen e Test auf vorhandene Nachrichten Diese Funktion zeigt an ob es unverarbeitete Nachrichten im Ringpuffer gibt Test auf freien Speicherplatz Diese Funktion berechnet den freien Speicherplatz im Ringpuffer gibt also die maximale Gr e einer zu speichernden Nachricht zur ck Position der n chsten Nachricht bestimmen Diese
243. se Ist ein bekanntes Protokoll eingebettet J N berechne den Zeiger auf die Rohdaten berechne die Parameter f r die aufzurufende Analysefunktion anderer Spei rufe die Analysefunktion f r das eingebettete Protokoll auf cherbedarf 0 R ckgabewert anderer Speicherbedarf berechne den Gesamtspeicherbedarf eigener anderer Speicherbedarf Abbildung 5 9 Template einer Analysefunktion Der folgende Pseudo C Code zeigt die Struktur des Templates include prototypen h include analyse_strukturen h extern int analysiere int analysiere_protokoll void rohdaten void ergebnisspeicher int meine_datenlaenge andere_datenlaenge eingebettetes_protokoll void eingebettete_rohdaten anderer_ergebnisspeicher MEINE_ANALYSE_STRUKTUR meine_rohdaten MEINE_ANALYSE_STRUKTUR rohdaten MEINE_SPEICHER_STRUKTUR meine_ergebnisse MEINE_SPEICHER_STRUKTUR ergebnisspeicher Eigene Ergebnisse berechnen if analysiere Ja dieses Protokoll soll analysiert werden meine_datenlaenge sizeof MEINE_SPEICHER_STRUKTUR meine_ergebnisse gt werti fi meine_rohdaten meine_ergebnisse gt wert2 f2 meine_rohdaten weitere Berechnungen meine_ergebnisse gt wert_n f_n meine_rohdaten else Nein dieses Protokoll soll nicht analysiert werden meine_datenlaenge 0 109 KAPITEL 5 REALISIERUNG DES MESSWERKZEUGE
244. sem Zeitpunkt kann es bereits etablierte Verbindungen geben Verbindungen k nnen gerade aufgebaut oder auch beendet werden Treffen Dateneinheiten von verbindungsorientierten Protokollen ein m ssen die Verbindungen und deren aktueller Zustand erkannt werden Dies ist die Grund lage f r alle weiteren Funktionen dieser Kategorie s u Das Erkennen einer Ver bindung ist meist durch Auswerten mehrerer Informationen der entsprechenden Dateneinheit m glich Beispielsweise identifiziert das Tupel T Senderadresse Empf ngeradresse Quellport und Senkenport eine Verbindung bei dem verbin dungsorientierten Protokoll TCP 7 Dar ber hinaus kann ber andere Informa tionen aus der Dateneinheit der Zustand der Verbindung rekonstruiert werden Verbindungen verwalten Hierunter fallen Funktionen zum Aktualisieren von Ver bindungskontexten und Funktionen zum Zugriff auf Verbindungskontexte z B Streufunktionen ber obiges Tupel T Dateneinheiten weiterleiten Diese Funktionen sind notwendig um Dateneinhei ten einer Verbindung die nicht durch den lokalen Pakettr gerproze verwaltet werden an einen anderen Pakettr gerproze weiterzuleiten Dies ist notwen dig da Dateneinheiten einer Verbindung nicht automatisch zum richtigen Pa kettr gerproze gelangen sondern erst ein Pakettr ger durch eine entsprechende 16 Beispiele f r einen solchen Zustand sind Empfangsbereit Sendebereit Verbindung etabliert o
245. sor des Hostrechners ergibt Ausschlaggebend f r diese Festlegung ist da der Prototyp nicht zu komplex wer den darf um die Realisierung innerhalb der f r eine Diplomarbeit vorgesehenen Zeit zu erm glichen Durch ein weiteres Transputerboard w rden jedoch weitere vier Transputer zur Verf gung stehen die das Konfigurieren des Prototypen deutlich ver komplizieren w rden Das ergibt sich aus der Tatsache da die Zuordnung manuell erfolgen mu wie in Abschnitt 3 1 4 dargestellt 4 3 2 Die wesentlichen Prozesse des Me werkzeuges Die wesentlichen Prozesse ergeben sich aus e den Benutzeranforderungen und e dem Paradigma der Paketparallelit t Die Prozesse und ihre Aufgaben werden in den folgenden Abschnitten dargestellt 4 3 2 1 Prozesse zur Datenerfassung Grunds tzlich mu ein Monitor Rohdaten erfassen k nnen vgl Abschnitte 1 3 2 und 2 7 4 Die zu erfassenden Rohdaten sind in diesem Fall Ethernet Frames Die Ethernet Frames m ssen berpr ft werden um netz spezifische Fehler erkennen zu k nnen Um dem Benutzer einen berblick ber derartige Fehler geben zu k nnen sollte der Proze zur Rohdatenerfassung rudiment re Statistiken ber die erkennbaren Fehler f hren Bei Ethernet k nnen beispielsweise bertragungsfehler durch eine Pr fsumme erkannt werden KAPITEL A ENTWURF DES MESSWERKZEUGES 70 Ein weiterer Grund die Rohdatenerfassung als eigenst ndigen Proze zu realisie
246. st programmiert werden s u e Programmieren der Topologie Verbindungen zwischen Transputerlinks werden durch Programmieren des Kreuzschienenverteilers Abbildung 3 7 hergestellt Eine Verbindung wird dabei durch Einschreiben eines Tupels K k k2 in ein Register des Kreuzschienenverteilers hergestellt k und ka identifizieren Trans puterlinks oder externe Verbindungsbuchsen mit eindeutigen numerischen Wer ten vgl Abschnitt 3 2 1 5 Eine Funktion zur Programmierung der Topologie sollte in jedem Fall verhindern da unzul ssige Verbindungen hergestellt werden Eine Bezeichnung der Transputerlinks mit Namen symbolische Bezeichner an stelle der numerischen Werte w rde au erdem die Benutzung erleichtern e Laden der Transputerprozesse Prozesse die in ein Transputernetz geladen wer den sollen werden von der Entwicklungs Software automatisch mit Ladefunktio nen erg nzt die f r die Verteilung der Prozesse auf die einzelnen Prozessoren zust ndig sind Die Verteilung mu vom Benutzer in einer Datei Konfigurati onsskript spezifiziert werden Zum Laden der Transputerprozesse wird auf dem KAPITEL A ENTWURF DES MESSWERKZEUGES 82 Host nur eine Funktion ben tigt die das parallele Programm Transputerpro zesse mit Ladefunktionen an den Transputer sendet der an die Schnittstelle zum Host angeschlossen ist Zuvor m ssen die Transputer wie oben dargestellt initialisiert werden 4 4 5 Entwurf essentieller Funkt
247. stimmte Suchmuster im Text hier die Exportdatei gefunden werden Diese Suchmuster k nnen wiederum mit Hilfe von regul ren Ausdr cken spezifiziert werden KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 126 ZEIT 3566 IP 134 100 15 1 134 100 9 61 136 UDP 0 116 UDP 1020 2049 116 108 5 3 4 5 Realisierung der Konfigurierungsfunktionen F r die Konfigurierung der Transputer vgl Abschnitt 4 4 4 3 wurde ein eigenst ndi ges Programm entwickelt Das Programm realisiert die folgenden Funktionen e alle Transputer eines TB in einen definierten Anfangszustand setzen Reset an alle Transputer e Programmieren der physikalischen Verbindungstopologie in den Kreuzschienen verteiler auf dem TB vgl Abbildung 3 9 Dar ber hinaus gestattet das Programm das e Anzeigen der zuvor programmierten Verbindungen und e das Benennen der Transputerlinks mit symbolischen Konstanten f r eine leichtere Bedienung Die Benennung der Transputerlinks und Buchsen des TB ist der Tabelle 5 2 zu entnehmen Diese Namen kann der Benutzer zu einem Konfigurationsstring zusam menstellen der die gew nschten Verbindungen bezeichnet s u Der Algorithmus bei der Programmierung einer Verbindungstopologie ist in Abbildung 5 17 dargestellt Symbollscher Name Transputer 1 fest verdrahtet mit Hostrechner Transputer 1 fest verdrahtet mit Kreuzschienenverteiler Transputer 1 A2 Transputer 1 A3 Transputer 2 Link 0 Link 3 BO B3 Transputer 3
248. struktur des Me werkzeuges Die folgende Konfiguration ber cksichtigt die oben dargestellten Restriktionen Da vier Transputer auf einem TB vorhanden sind werden diese zusammen mit dem PC Prozessor und dem Transputer auf dem TB mit der Ethernet Schnittstelle benutzt Damit stehen insgesamt sechs Prozessoren f r das Me werkzeug zur Verf gung Aus den Restriktionen geht hervor da es zum PC und zum TB mit der Ethernet Schnittstelle jeweils genau eine Verbindung gibt Daraus ergeben sich die Verbindun gen der Prozessoren Pl zu P2 und P5 zu P6 vgl Abbildung 4 1 Die verbleibenden Prozessoren P3 und P4 k nnen nun jeweils untereinander und mit P2 und P5 verbun den werden Daraus ergibt sich die Topologie aus Abbildung 4 1 Die Zuordnung der Prozesse ist weitgehend restriktiv Es gibt mehrere qualitative Restriktionen Offensichtlich k nnen die Prozesse des Hostrechners ausschlie lich P1 zugeordnet werden da P1 der einzige Hostrechner Prozessor ist Die Prozesse zur Rohdatenerfassung lassen sich ebenfalls leicht zuordnen Sie sollten auf Prozessoren in unmittelbarer N he zur Ethernet Schnittstelle plaziert werden Die unmittelbare Ansteuerung der Ethernet Schnittstelle mu ohnehin von P6 aus erfolgen da dieser Prozessor an die Ethernet Schnittstelle gekoppelt ist vgl Abbildung 3 8 Das Zwi schenspeichern der Rohdaten k nnte auf P5 erfolgen da dieser Prozessor ber mehr Speicher verf gt als P6 4MByte vs 64KByte Auf P5
249. stung des Me werkzeuges Tabellen mit Verbindungsdaten austauschen Dadurch l t sich f r viele Ver bindungen der jeweils zust ndige Pakettr ger auch direkt adressieren falls eine Dateneinheit weitergereicht werden mu s o Es wurden keine Verbindungsmanagement Funktionen f r den Prototypen realisiert 5 3 3 Realisierung der globale Statistikfunktionen Der Algorithmus f r die Berechnung der globalen Statistik ist in Abbildung 5 16 dar gestellt Berechnet werden beim gegenw rtigen Prototyp nur Daten zum Durchsatz auf den verschiedenen Protokollebenen in Megabit pro Sekunde Denkbar sind weitere Statistiken wie in Abschnitt 2 1 angedeutet Die beim Entwurf vgl Abschnitt 4 4 3 genannte Periode von einer Sekunde ist optimal f r die Berechnung der Auslastung in MBit s Die lokalen Statistiken werden in Byte s gef hrt so da f r die Vorbereitung der Statistik f r den Hostrechner nur eine Umrechnung in Bit erforderlich ist wiederhole empfange lokale Statistik von Pakettr ger aktualisiere globale Statistik alle lokalen Statistiken empfangen Ja SEEN sende globale Statistik an den Benutzer Abbildung 5 16 Berechnung der globalen Statistiken 5 3 4 Realisierung der Funktionen f r den Hostrechner Im folgenden werden die Realisierungen der essentiellen Funktionen des Hostrechners dargestellt Die Darstellung orientiert sich am Entwurf aus Abschnitt 4 4 4 5
250. t filter gt FILTER simple_filter simple_filter gt simple_filter LOG_AND simple_filter simple_filter gt simple_filter LOG_OR simple_filter simple_filter gt simple_filter simple_filter gt OFFSET val rel_opr val simple_filter gt SYMBOL rel_opr SYMBOL rel_opr gt lt lt l gt gt val gt HEXNUM DEZNUM Die terminalen Symbole LOG_AND und LOG_OR sollen die entsprechenden logi schen Verkn pfungen darstellen Die unter rel_opr aufgez hlten terminalen Symbole stellen die aus der Sprache C bekannten relationalen Operatoren dar HEZNUM und DEZNUAM stehen f r skalare Werte die entweder hexadezimal oder dezimal dargestellt werden k nnen SYMBOL repr sentiert einen Wert aus einer Symboltabelle Der Benutzer tippt die Filterdefinitionen ber die Kommandozeile ein Die Kom mandozeile bernimmt die lexikalische und syntaktische berpr fung der Eingabe vgl Abschnitte 4 4 5 2 und 5 3 4 1 Die Sematik der Regeln soll folgenderma en sein Ein skalarer Wert rechts vom rel opt wird mit den Rohdaten verglichen Der Vergleich gibt an ob die durch rel_opr repr sentierte Relation erf llt ist Der Vergleich wird bei den Rohdaten ab der Position durchgef hrt die von dem Wert links des rel_opr angegeben wird Werden mehrere Vergleiche durchgef hrt so m ssen sie durch einen logischen Ope rator AND OR verkn pft werden Das Ergebnis der Auswertung der Filter soll ein boo
251. t der Monitor das Verhalten einer Protokollin stanz um die Partnerinstanz im Kommunikationssystem zu testen 1 3 2 7 Eine alternative Benennung von Me werkzeugen Aufgrund der vielf ltigen Verwendung des Begriffs Monitor f r Me werkzeuge mit erheblich unterschiedlichem Funktionsumfang wird in Wo193 S 16 eine andere Ter minologie vorgeschlagen Ausgegangen wird von der Grundfunktionalit t eines Mo nitors zur Datenerhebung um ein Me instrument zu definieren Durch sukzessive Erweiterung der Funktionalit t durch Komponenten zur e Datenreduktion e Datenanzeige e Analyse e Diagnose e Netzadministration erh lt man letztendlich ber mehrere wohldefinierte Zwischenstufen ein Performance Managementsystem da alle bisher beschriebenen Funktionen umfa t vgl Abschnitt 1 4 In diesem Zusammenhang wird in Echtzeit als parallel zur Datenerfassung verstanden KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 19 1 4 Klassifikation von Monitoren Eine Klassifikation von Monitoren ist unter verschiedenen Aspekten m glich Die verschiedenen Beziehungen und Wechselwirkungen der Klassifikationen untereinander werden in diesem Abschnitt aufgezeigt Grunds tzlich lassen sich Monitore klassifizieren nach der Me aufgabe ihrer Architektur ihrem Funktionsumfang dem eingesetzten Me verfahren und der Ergebnispr sentation 1 4 1 Klassifikation nach der Me aufgabe Setzt man als Analysemethode die
252. t werden die die Zuordnung von Protokollen zu Farben angibt Ein m glicher Kurvenverlauf wird in Abbildung 6 11 dargestellt Auch dieses Fenster ist frei skalierbar Da f r die Darstellung des Koordinaten systems der Legende und der Kurven eine Mindestgr e erforderlich ist wird bei Unterschreiten dieser Mindestgr e eine Fehlermeldung anstelle des Histogramms im Fenster angezeigt vgl Abbildung 6 7 x Mbit s e Skalieren Legende Fenster zu klein Abbildung 6 7 Ein zu kleines Fenster KAPITEL 6 ARBEITEN MIT DEM PROTOTYPEN 152 6 1 4 Das Fenster ARP RARP Tabelle Ein weiteres Textfenster wird benutzt um die Zuordnung von Ethernet Adressen zu IP Adressen darzustellen Diese Informationen ergeben sich aus der Analyse der Pro tokolle ARP und RARP vgl Abschnitt 5 3 2 3 F r jedes Adre paar wird notiert wie oft es Anfragen und Antworten bez glich einer Adresse gab Bei der Ausgabe im Fenster werden die Adressen die zuletzt in einer ARP RARP Dateneinheit emp fangen wurden zuerst ausgegeben lifo Prinzip Abbildung 6 10 zeigt Beispiele f r Adre paare 6 1 5 Fehler beim Programmstart Tritt w hrend des Konfigurierens der Transputer ein Fehler auf wird das vom Host rechner Proze bemerkt und in einem Dialog Fenster angezeigt Au erdem wird angegeben bei welchem der beiden Transputerboards das Problem auftritt Es gibt vier wahrscheinliche Fehlerursachen 1 Ein
253. teiler e Busschnittstelle f r IBM PC kompatible Rechner Durch den programmierbaren Kreuzschienenverteiler sind diese TBs besonders flexibel konfigurierbar Die Links der Transputer lassen sich so beliebig untereinander verbin den Au erdem kann man die Links durch eine entsprechende Programmierung des Kreuzschienenverteilers auch mit Buchsen auf dem TB verbinden so da eine TB bergreifende Verbindung zwischen Transputern hergestellt werden kann Damit hat man die M glichkeit beliebig viele Transputer miteinander zu vernetzen Der Hauptvorteil der programmierbaren Kreuzschienenverteiler ist jedoch da sich die Verbindungen der Transputer zur Programmlaufzeit dynamisch ver ndern lassen Man kann so sehr flexibel auf neue Anforderungen reagieren In Abbildung 3 7 ist der Aufbau eines MTM PC Boards schematisch dargestellt Der mit einem Stern mar kierte Transputer unterscheidet sich von den anderen dadurch da zwei seiner Links fest verbunden sind Ein Link ist mit der PC Schnittstelle verbunden Hier ber mu die gesamte Transputer PC Kommunikation ablaufen Ein weiterer Link ist mit dem Kreuzschienenverteiler fest verbunden ber diesen Link wird der Kreuzschienenver teiler programmiert 4Mbyte 4Mbyte 4Mbyte 4Mbyte u gt PC T800 T800 T800 T800 Schnitt PC Bus El stelle K
254. tel soll eine m glichst umfassende Darstellung von Anforderungen an ein universelles Me ger t f r Kommunikationssysteme gegeben werden Die hier dar gestellten Anforderungen gehen weit ber die Leistungsmerkmale hinaus die einzelne verf gbare Me werkzeuge heute bieten Dennoch kann man keine vollst ndige de taillierte Auflistung aller denkbarer Anforderungen aufstellen da sich st ndig neue Anforderungen an Me werkzeuge ergeben Die Anforderungen an ein universelles Me ger t f r Kommunikationssysteme lassen sich nach den zu erbringenden Funktionen einteilen Es gibt Anforderungen bez glich der Datenerfassung Messung dem Filtern Analysieren Bewerten Anzeigen Ver walten der Daten und dem aktiven Testen vgl Abschnitt 1 3 2 Au erdem gibt es Anforderungen des Anwenders an ein Werkzeug 2 1 Anforderungen seitens der Me aufgabe Datenerfas sung und Analyse Die Anforderungen seitens der Me aufgabe lassen sich in die f r Kommunikationssy steme typische Protokollhierarchie einordnen Die einzelnen Me aufgaben erfordern Messungen die auf mindestens einer dieser Protokollschichten stattfindet Die zu unterst tzenden Messungen und darauf aufbauenden Analysen werden anhand der Aufgaben der jeweiligen Protokollschicht motiviert 2 1 1 Schicht 1 physikalische Schicht Auf dieser Ebene findet die physikalische bertragung statt bei der entweder analoge oder digitale Signale bertragen werden Folgende Messungen zur Qualit
255. ter auf einem TB ber die PC Schnittstelle vgl Abbildung 3 7 und bergibt diesem die Ladeprogramme f r die anderen Transputer die ber das sogenannte Bootstrap Verfahren sukzessive gestartet werden KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE HARDWARE 55 3 3 Konzepte zur parallelen Protokollverarbeitung Viele Me aufgaben vgl Abschnitt 2 beziehen sich direkt oder indirekt auf die verwendeten Protokolle bei der Daten bertragung Offensichtlich m ssen die Da teneinheiten identifiziert und danach ihre genaue Zusammensetzung Protocol Data Unit Format kurz PDU Format analysiert werden um beispielsweise Statistiken zur L ngenverteilung der PDUs zu erzeugen Es liegt daher nahe ein geeignetes Konzept f r die Analyse der Dateneinheiten aus dem Bereich der parallelen Protokollverarbeitung auszuw hlen und es direkt oder nach noch zu diskutierenden Modifikationen f r die Realisierung des Me werkzeuges zu verwenden Bewertungskriterien die eine Auswahl nachvollziehbar machen werden in Abschnitt 3 3 1 vorgestellt Modifikationen die durch die Adaption eines Konzeptes f r die parallele Proto kollverarbeitung an die parallele Protokollanalyse notwendig werden ergeben sich aus den verschiedenen Sichtweisen auf das Kommunikationssystem die man bei der Pro tokollverarbeitung in Endsystemen im Gegensatz zu der Protokollanalyse mit einem Werkzeug hat Eine Gegen berstellung dieser Sichtweisen wird in Abschnitt 3 3 2
256. tionen und eine Ablaufkoordinierung ben tigt Die weiteren Schritte sind in der folgenden Liste zusammengefa t 38Diese Hash Funktion sichert auch bei einer gro en Anzahl von Symbolen einen schnellen Zugriff auf die Attribute KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 139 Festlegen der Proze klasse f r die Gruppenadressierung Hierbei kann es sich um eine neue Klasse handeln um eine Kombination von bereits vorhandenen Klassen oder um eine neue Klasse die zus tzlich mit vorhandenen kombiniert wird Erstellen einer oder mehrerer Eintr ge in die Vermittlungstabelle f r Prozesse dieser neuen Klasse Einerseits m ssen alle Nachrichten an die eigene Klasse empfangen werden k nnen andererseits m ssen alle Nachrichten an andere Pro ze klassen die m glicherweise empfangen werden k nnen transparent weiterver mittelt werden Festlegen der zu verarbeitenden Nachrichten Die zu verarbeitenden Nachrich ten bestimmen wesentlich die Komplexit t der Ablaufkoordinierung dieser neuen Proze klasse In jedem Fall sollte auf die Anforderung von Statusinformationen reagiert werden k nnen e Implementieren des neuen Prozesses F r jede zu verarbeitende Nachricht ist eine entsprechende Funktion zu realisieren e Anpassen der Konfiguration ber ein entsprechendes Skript Diese Arbeitsschritte fallen immer an wenn eine neue Klasse von Prozessen realisiert wird Zus tzlich m ssen noch nderungen an bestehenden Proze klassen v
257. tions Research Report RC 19973 88451 IBM Research Division 1995 V Penner Parallelit t und Transputer Von den Grundlagen zur Anwendung Vieweg Braunschweig Wiesbaden 1992 M J Rochkind Fortgeschrittene Bildschirmprogrammierung in C unter UNIX und DOS Hanser Prentice Hall Wien London 1990 A T Schreiner and G Friedman Compiler bauen mit Unix Eine Einf hrung Hanser M nchen Wien 1985 SGS91 SGS THOMSON Microelectronics Group IMS B431 Ethernet TRAM 1991 LITERATURVERZEICHNIS 185 Sta93 Tan95 Thu93 Tic85 WF93 WK90 Wo193 You89 Zit91a Zit91b ZK93 W Stallings Local and Metropolitan Area Networks Macmillan Publishing Comp 4 edition 1993 A S Tanenbaum Verteilte Betriebssysteme Prentice Hall 1995 E M Thurner Performance Measurement Using System Monitors In L Do natiello and R Nelson editors Performance Evaluation of Computer and Communication Systems Lecture Notes in Computer Science 729 Springer Verlag 1993 W F Tichy RCS A System for Version Control Software Practice D Expe rience 7 15 637 654 jul 1985 C M Woodside and G Franks Alternative Software Architectures for Paral lel Protocol Execution with Synchronous IPC IEEE ACM Transactions on Networking 1 2 178 186 apr 1993 B E Wolfinger and J J Kim Load Measurements as a Basis for Modeling the Load of Innovative Communication Systems with Service Integration In Sec
258. tstelle des Prototypen 8 2 2 Probleme bei der Programmierung Probleme bei der Programmierung ergaben sich aus mangelhafter oder veralteter Do kumentation der Entwicklungsumgebung und des Betriebssystems Viel Zeit mu te darauf verwendet werden die programmierten Funktionen zu berpr fen Ein st ndi ges Mi trauen gegen ber dem Parallel C Compiler begleitete die Implementierung Ein Zitat aus der Dokumentation mag f r sich selbst sprechen this release is closer to Ansi O Au erdem war kein Debugger f r den Parallel C Compiler vorhanden Es mu te besonders viel Zeit investiert werden um jede Funktion mit eigenen Debug Infor mationen auszustatten die zumindest eine rudiment re Einsicht in den Ablauf der Prozesse erm glichten Da diese Informationen an den Hostrechner gesendet wer den mu ten war die Implementierung der Nachrichtenvermittlung besonders schwer Entweder funktionierte das Senden und Empfangen von Nachrichten oder es gab ir gendwo einen oder mehrere Fehler Bei der Programmierung mu te dar ber hinaus zwischen Systemprogrammierung der Transputer und Anwendungsprogrammierung unter OS 2 gewechselt werden Die Systemprogrammierung der Transputer machte den besonderen Reiz dieser Di plomarbeit aus Die Anwendungsprogrammierung unter OS 2 war eher notwendig als reizvoll Die Forderung nach einer graphischen Benutzerschnittstelle ist heutzutage blich Der da
259. tstellen ob die Prozesse noch erreichbar sind Dazu wird das Kommando status process in Zeile 2 eingegeben W hrend sich die Pakettr ger und die globale Statistik nur mit einem OK melden Zeile 4 6 gibt der Proze PDEV etwas mehr Auskunft Zeile 7 Er meldet da der Netz Server bisher nicht gebootet wurde Die beiden anderen Informationen besagen da der Netz Server noch nicht terminiert wurde und der Paketempfang des Servers nicht eingeschaltet wurde Zur Zeit mu der Prototyp noch vom Benutzer aufgefordert werden den Netz Server zu laden Dazu gibt der Benutzer init_tr ein Zeile 9 Ein weiteres Kom mando status process w rde dann den Zustand PDEV OK gebootet melden Beim Prototypen werden dar ber hinaus Debug Informationen von den Prozessen generiert falls der Benutzer das w nscht In diesem Fall generiert der Proze PDEV solche Informationen Er zeigt die Nachrichten und den Typ der Vermittlungsinfor mationen der Nachrichten an die er empf ngt 6 3 1 Name der Messung Jede Messung mu einen Namen bekommen In diesem Fall vergibt der Benutzer in Zeile 12 den Namen _arp mit dem Kommando mess _arp Der Name erf llt zwei Aufgaben Einerseits kann der Benutzer sich auch nach Tagen anhand des Namens daran erinnern was er gemessen hat bzw was er messen wollte Andererseits werden Namen f r Protokollierungs Dateien und Me ergebnisse
260. tung Symbole blockiert ein solcher Dialog alle Eingaben bis der Benutzer den Dialog best tigt KAPITEL 6 ARBEITEN MIT DEM PROTOTYPEN 153 e Benennen der Messung e Definieren eines Filters e Ausw hlen der zu protokollierenden Informationen e Durchf hren der Messung e Beenden einer Messung 6 2 1 Benennen der Messung Jeder Messung mu ein Name gegeben werden Dieser Name wird benutzt um Be triebsmittel f r die Messung zu verwalten Au erdem k nnen ber den Namen In formationen ber die Messung abgerufen werden beispielsweise ob gerade Me daten erhoben werden 6 2 2 Definieren eines Filters Man ben tigt keinen Filter f r die Durchf hrung einer Messung Ohne Filter werden alle Rohdaten analysiert Man sollte jedoch immer versuchen einen adequaten Filter zu definieren Wichtig ist das Filtern bei langen Messungen die protokolliert werden um m glichst nur Me werte zu protokollieren die tats chlich ben tigt werden Bei sehr aufwendigen Analysen kann es u U notwendig sein Filter zu definieren um die Last an die Pakettr ger zu verringern 6 2 3 Ausw hlen der zu protokollierenden Informationen Hier k nnen protokollspezifische Angaben gemacht werden welche Parameter zu pro tokollieren sind falls eine Dateneinheit den Filter passiert Es handelt sich hierbei um einen zweiten Filter Beispielsweise kann der Benutzer angeben da bei der Analyse von IP Dateneinheiten die L nge der Dateneinheit ausgegebe
261. tzer wird dar ber informiert da der Proto typ im Rahmen einer Diplomarbeit erstellt wurde und den vorl ufigen Namen Der Benutzer kann beim Konfigurieren der graphischen Benutzerschnittstelle von OS 2 festle gen wie sich Fenster beim Dr cken des Schalters zum Minimieren verhalten sollen Eine m gliche Reaktion ist da das Fenster zu einem Symbol Icon verkleinert wird das nur sehr wenig Platz auf der graphischen Oberfl che beansprucht Alternativ kann das Fenster bis zu einer manuellen Reaktivierung vollst ndig von der Oberfl che gel scht werden KAPITEL 6 ARBEITEN MIT DEM PROTOTYPEN 149 Eth_Analyser tr gt Fenster speichern und Fenster laden Die Fenster werden beim Programmstart von OS 2 willk rlich auf der graphischen Oberfl che plaziert Damit der Be nutzer nicht nach jedem Programmstart das Layout der Fenster mit der Maus modifizieren mu k nnen individuelle Pr ferenzen des Benutzers zur Lage und Gr e der Fenster gespeichert und geladen werden Exit Das Beenden des Programms ist nur erlaubt falls keine Messung aktiviert ist vgl Abschnitt 6 2 File Show Messung Test Help Transputer booten About Eth_Analyser Fenster speichern Fenster laden Exit Abbildung 6 3 Das le Menn 6 1 1 2 Das Show Men ber dieses Men kann der Benutzer Informationen abrufen Aktuelle Messung Zeigt den Namen und den Zustand der Messung an aktiviert vs unterbrochen
262. uf den Pakettr gern ausgeglichen Bei dem sekund ren Engpa bedeutet auch nicht jeder Burst zwingend Datenverlust 7 2 Bewertung weiterer Komponenten Ein Teil der Leistungsbewertung wurde bereits im letzten Abschnitt behandelt Es wurden der prim re und sekund re Engpa identifiziert und Anregungen gegeben was ein Benutzer tun kann falls ein Engpa eine Messung gef hrdet Zwei weitere Komponenten m ssen bewertet werden Einerseits ist der Grenz durchsatz beim Filtern zu bestimmen Andererseits mu die Leistungsf higkeit eines Pakettr gers bewertet werden Unmittelbar einsichtig ist da beide Komponenten zum Engpa werden k nnen Dazu ist es beim Filtern nur n tig eine sehr gro e Anzahl an Vergleichen durchzuf hren hnlich verh lt es sich mit den Pakettr gern Durch Erweitern der Funktionalit t kann man so viel Komplexit t in den Analysevor gang hineinbringen da ein einzelner Pakettr ger zum Engpa des Systems werden kann In den beiden folgenden Abschnitten wird deshalb der Grenzdurchsatz an diesen Komponenten f r verschiedene Auftr ge angegeben um die Leistungsf higkeit nach oben abzusch tzen 7 2 1 Grenzdurchsatz beim Filtern Der k rzeste Auftrag beim Filtern ist ein einzelner Vergleich mit einer L nge von einem Byte Realistischer sind jedoch mehrere und auch l ngere Vergleiche Viele Vergleiche die sich auf Protokolle der TCP IP Familie beziehen sind beispielsweise zwei Byte lang In Abbildung
263. ugen der Kommunikationsme technik 4 3 5 WR Ae eeneg e 6 Arbeiten mit dem Prototypen 6 1 Die Benutzerschnittstelle des Prototypen e 6 1 1 Das Fenster Standardausgabe 2 2 2 222m 6 1 2 Das Fenster Standardeingabe 2222 6 1 3 Das Fenster MBits 9 un won a wa en AEN E 6 14 Das Fenster ARP RARP Tabelle 222222 02 INHALTSVERZEICHNIS 6 2 6 3 6 4 6 1 5 Fehler beim Programmstart e Vorgehensweise zur Durchf hrung eines Me experiments 6 2 1 Benennen der Messung 2 2 non 6 2 2 Definieren eines Filters CC oo mn 6 2 3 Ausw hlen der zu protokollierenden Informationen 6 2 4 Durchf hren der Messung 6 2 5 Beenden einer Messung Fallbeispiel I Analysieren von ARP RARP Dateneinheiten 6 3 1 Name der Messung e 6 3 2 Definieren eines Filters 2 2 Co nn nen 6 3 3 Ausw hlen der zu protokollierenden Informationen 6 3 4 Starten einer Messung 6 3 5 Unterbrechen einer Messung e 6 3 6 Beenden einer Messung Fallbeispiel II Durchf hren einer Lastmessung 6 4 1 Ausw hlen der anzuzeigenden Protokolle 2 6 4 2 Das Fenster MBil 242 nr en a 7 Leistungsbewertung des Prototypen 7 1 7 2 7 3 Engp sse des Prototypen 2 CC nn on 7 1 1 Der prim re Engpa des Prototypen 7 1 2 Analyse des prim ren Engpasses 7 1 3 Vorbeugende Ma nahmen 7 1 4 Der sekund re Engpa H 2 Cum n
264. uktur eines Transputer Prozesses ist in Abbildung 5 3 als Datenflu diagramm dargestellt Nachrichten zu anderen Prozessen Ergebnisse Sender f r andere Prozesse proze spezifische Vermitteln Berechnungen T 2 T 3 Nachrichten nur f r Nachrichten f r diesen Proze andere Prozesse Ringpuffer alle Nachrichten Nachrichten 7 von anderen gt Empf nger Prozessen T 1 Abbildung 5 3 Datenflu diagramm des Proze Templates Die Kooperation dieser Threads wird weiter unten am Beispiel des Prozesses PDEV exemplarisch dargestellt Aus der Darstellung ist ersichtlich da alle Pro zesse die auf einem Transputer plaziert werden in ihrer Struktur hnlich sind Es gibt immer einen Thread der den Ablauf koordiniert Er startet die anderen Threads des Prozesses Dies sind in jedem Fall die Threads f r die Nachrichtenvermittlung KAPITEL 5 REALISIERUNG DES MESSWERKZEUGES 98 Weitere Threads werden beispielsweise bei PDEV vgl Abschnitt 5 2 3 gestartet Alle Aktionen nach der Initialisierung durch die Ablaufkoordinierung werden durch Nachrichten ausgel st 5 2 2 Der Proze zur Rohdatenerfassung Hier sind die Funktionen des Ger tetreibers f r die Ethernet Schnittstelle zusammen gefa t worden vgl Abschnitt 4 4 1 Eine Besonderheit dieses Prozesses ist da er bei der Konfigurierung nicht auf dem Transputer P6 vgl
265. um Transportsystem gemessen Analog bezieht sich der Interface Durchsatz auf die Schnittstelle einer Station zum Netz 2 1 7 Schichtunabh ngige Anforderungen an die Datenerfassung und Analyse Unabh ngig von der jeweiligen Protokollschicht mu ein universelles Me werkzeug e eine gen gend hohe Aufl sung Anzahl der Samples pro Sekunde bzw Anzahl verarbeitbarer Ereignisse pro Sekunde f r die zu erbringende Me aufgabe haben e umfangreiche statistische Auswertungen der erhobenen Daten bieten e bei verteilter Datenerfassung die Ereignisse in eine globale Ordnung Reihenfolge bringen k nnen 2 2 Anforderungen an das Filtern der Daten Die erfa ten Daten m ssen in der Regel gefiltert werden bevor sie weiterverarbei tet werden k nnen Unter Filtern wird hier die Selektion bestimmter Informationen aus den erfa ten Daten verstanden Ziel des Filterns ist eine Reduktion des Daten volumens Die Reduktion der Daten soll nach Vorgaben des Benutzers erfolgen Es ergeben sich mindestens folgende Anforderungen an das Filtern der Daten e Standardfilter f r h ufige Anwendungsf lle bzw f r h ufig benutzte Protokolle Protokolltyp Portnummern Sender und Empf ngeradressen e Benutzerdefinierbare Filter Angabe einer Startposition an der ein bestimmtes Bitmuster gefunden werden soll e Kombinationsm glichkeiten der Filter ber boolesche Funktionen AND OR NOT e Verwalten von benutzerdefinierten nicht
266. ungen zu erf l len wie man ein vorhandenes Kommunikationssystem an neue andere Anforderungen anpassen kann wie man Kommunikationssysteme m glichst optimal konfiguriert ob ein Kommunikationssystem sich im laufenden Betrieb seiner Spezifikation ent sprechend verh lt ob in das Kommunikationssystem von au en eingebrochen wird ob es zu Verklemmungen bei der Betriebsmittelverwaltung kommt wer welche Betriebsmittel wie lange benutzt In der Regel sind ausfallanf llige Systeme bei Wartungen oder Reparaturen nicht oder nur teilweise verf gbar Beim Konfigurieren legt man Systemparameter fest Hierbei kann es sich beispielsweise um die zu verwendenden Protokolle handeln oder um die Erstellung statischer Wegwahltabellen f r Vermittlungsrechner Ein Beispiel ist das Testen von neuen Protokollen Bei der Spezifikation k nnen in der Regel formale Validierungstechniken eingesetzt werden Bei einer anschlie enden manuellen Implementation kann es dennoch zu Fehlern kommen die dann im laufenden Test Betrieb gesucht werden KAPITEL 1 ANALYSE VON KOMMUNIKATIONSSYSTEMEN 12 1 2 Analysemethoden Grunds tzlich kann man zwischen direkten Analysen am Kommunikationssystem und indirekten Analysen an Modellen unterscheiden Die direkte Analyse setzt voraus da das zu untersuchende Kommunikationssystem bereits existiert In diesem Fall kann man mit Hilfe von Me instrumenten Informationen direkt aus dem Kommuni kationssystem gew
267. urde Die fehlende Kenntnis ber das PDU Format der Dateneinheiten des unbekannten Protokolls verhindert die Selektion der f r die weitere Identifizierung notwendigen Informationen aus der Dateneinheit Das Ergebnis der Erkennung ist eine teilweise oder vollst ndige Angabe der ver wendeten Protokollhierarchie Beispielsweise k nnte eine Dateneinheit folgende Ty pisierung haben Ethernet Frame IP TCP TELNET Hierbei handelt es sich um eine vollst ndige Typisierung da kein weiteres Protokoll in TELNET eingebettet wird Im ersten Iterationsschritt mu te der Ethernet Frame aus den beiden M glichkeiten Ethernet Frame IEEE 802 3 Frame identifiziert werden Im zweiten Iterations schritt mu te das Internetprotokoll IP aus einer Vielzahl m glicher Protokolle iden tifiziert werden Ergebnis der dritten und vierten Iteration war die Identifizierung des Transmission Control Protocol TCP und die Identifizierung von TELNET In Abbildung 4 3 ist dargestellt welche Informationen f r das Erkennen einer Dateneinheit notwendig sind Der dargestellte Baum ist bei weitem nicht vollst ndig Es soll nur verdeutlicht werden welche Informationen einer Dateneinheit das iterative Erkennen der verwendeten Protokollhierarchie erm glichen Gerade diese Unterschiede in den auszuwertenden Informationen auf den verschiedenen Protokollebenen zwingen zu einem iterativen Erkennen der Protokollhierarchie Hier wird noch einmal die N he
268. von Verbindungen oder das verbindungslose bertragen von Daten Die hierunter subklas sifizierten Formen der Parallelverarbeitung gehen von den versendeten Dateneinheiten Paketen aus Sie unterscheiden sich in der Dekomposition der Daten einheiten die in einem Endsystem eintreffen bzw von dort versendet werden In Abbildung 3 10 werden die weiter unten vorgestellten Parallelisierungsformen vorab kurz dargestellt Strukturelle Parallelit t nach OSIRM statische Struktur zeitliche Parallelit tt Schichtenpipeline r umliche Parallelit t Protokollfunktionen L Sende Empfangspipeline dynamische Struktur Verbindungsparallelit t Paketparallelit t Abbildung 3 10 Strukturelle Parallelit t nach OSIRM 3 3 3 1 Vertikale Parallelit t Protokollpipeline Die vertikale Parallelit t ergibt sich aus der hierarchischen Struktur der Protokolle Die Protokolle bilden eine Protokollpipeline Auf den verschiedenen Schichten arbei ten die Protokolle parallel zueinander Wenn eine Protokollinstanz eine Dateneinheit verarbeitet hat wird diese der folgenden Schicht bergeben Dort beginnt die Proto kollinstanz mit der weiteren Verarbeitung w hrend die Protokollinstanz der darun terliegenden Schicht eine weitere Dateneinheit bearbeiten kann vgl Abbildung 3 11 15 Bildlich gesprochen sind die Schichten vertikal bereinander angeordnet KAPITEL 3 ABBILDEN DER PROZESSE AUF DIE H
269. w hrend des An zeigens auswertbar sind Insbesondere bei der Datenanalyse s u von Protokollen in Hochgeschwindigkeitsnetzen ist dies nicht mehr m glich In F llen wie diesen wo die Anzeige der Daten parallel zu ihrer Erfassung den menschlichen Betrachter berfordert mu man Batch Monitore verwenden Sie spei chern die Rohdaten oder bereits gefilterte und analysierte Daten auf Massenspeicher f r eine sp tere off line Weiterverarbeitung und Anzeige 1 4 6 Zusammenfassung der Klassifikation Die oben dargestellten Klassifikationen nach Me aufgabe Architektur Funktionsum fang Me verfahren und Ergebnispr sentation k nnen kombiniert werden um einen Monitor zu beschreiben Dies ist erforderlich da die Einordnung in eine der Klassifikationen meist nicht ausreicht um ein Werkzeug zu charakterisieren Au erdem schlie en sich die einzelnen Merkmale nicht unbedingt gegenseitig aus Vielmehr mu man die Merkmale einer Klassifikation als m gliche Freiheitsgrade bei der Wahl eines Werkzeuges verstehen So schlie t die M glichkeit eines Monitors Daten off line zu erfassen nicht aus da Teile oder alle Daten bei einer anderen Einstellung auch w hrend der Erfassung angezeigt werden Ebenso kann ein Monitor die M glichkeit bieten sowohl periodisch Daten zu erfassen als auch auf bestimmte Ereignisse zu reagieren Kapitel 2 Anforderungen an ein Me werkzeusg f r Kommunikationssysteme In diesem Kapi
270. wann von wo und wie lange auf sensible Daten zugegriffen wird 1 3 1 6 Verst e gegen Sicherheitsma nahmen Verst e gegen Sicherheitsma nahmen k nnen ebenfalls durch Messungen erkannt wer den Kann man beispielsweise durch die Vergabe oder den Entzug von Zugriffsrechten nicht sicherstellen da bestimmte Personen gruppen einige Dienste oder Betriebs mittel nicht benutzen da so neue Sicherheitsl cken s o entstehen ist es notwendig derartige Verst e zu registrieren So kann schnellstm glich nach einem Versto eine geeignete Ma nahme veranla t werden Beispielsweise k nnte der Verantwortliche f r ein Verteiltes System darauf bestehen da alle Systemverwalter mit bestimmten Zu griffsrechten das bekannte TELNET Protokoll nicht benutzen d rfen um sich ber das Kommunikationssystem auf einem anderen Rechner einzutragen Durch einfaches Abh ren der jeweiligen Verbindung k nnen Unbefugte so in Kenntnis von Password und Benutzernamen kommen Durch einfaches Abh ren der Verbindungen kann aber auch ein Me werkzeug dazu benutzt werden um derartige Verst e gegen das TELNET Verbot zu berwachen Eine geeignete Gegenma nahme w re das sofortige ndern des potentiell bekannten Password durch den Benutzer 1 3 2 Werkzeuge zum Erfassen von Me daten Im Bereich der Kommunikationsme technik gibt es eine Vielzahl von Werkzeugen zum Erfassen der verschiedenartigen Me daten im Kommunikationssystem
271. zte Informationen Ende zu Ende Informationen Abbildung 8 3 IPv6 Dateneinheit 181 Literaturverzeichnis ASU88 A V Aho R Seti and J D Ullman Compiler Bau Band 1 Addison Wesley Deutschland GmbH 1988 Ben94 C Benecke M glichkeiten der Beschleunigung der Kommunikation in Hoch geschwindigkeitsnetzen durch Parallelisierung Studienarbeit Universit t Hamburg Arbeitsbereich Rechnerorganisation 1994 BHK94 A Badach E Hoffmann and O Knauer High Speed Internetworking Addison Wesley 1994 Car88 A Carling Parallel Processing The Transputer and OCCAM SIGMA Press 1988 CDK94 G Coulouris J Dollimore and T Kindberg Distributed Systems Concepts and Design Addison Wesley 2 edition 1994 Com91 D E Comer Internetworking with TCP IP Principles Protocols and Ar chitecture volume 1 Prentice Hall Englewood Cliffs New Jersey 2 edition 1991 CS91 D E Comer and D L Stevens Internetworking with TCP IP Design Im plemtation and Internals volume 2 Prentice Hall Englewood Cliffs New Jersey 2 edition 1991 D 94 P Dauphin et al ZM4 Simple A General Approach to Performance Measure ment and Evaluation of Distributed Systems In T Casavant and M Singhal editors Readings in Distributed Computing Systems pages 286 309 IEEE Computer Society Press 1994 dM95 H de Meer Modelling and Management of responsive systems the quality of service for multi media appli
272. zten TBs voll auszulasten Die Restriktionen durch die Hardware lassen sich wie folgt zusammenfassen e Die gesamte Transputer PC Kommunikation mu ber einen dedizierten Trans puter erfolgen e Der Zugriff auf das Kommunikationssystem ber die Ethernet Schnittstelle mu ber einen dedizierten Transputer erfolgen e Es kann jeweils nur ein Proze auf einen bidirektionalen Link der Transputer zugreifen Alle Prozesse eines Transputers m ssen mit maximal vier Links aus kommen e Jedes TB Typ wie in Abbildung 3 7 stellt genau vier Transputer zur Verf gung 4 2 Wahl eines Konzeptes zur parallelen Protokollana lyse In Abschnitt 3 3 3 wurden die verschiedenen bekannten Konzepte zur parallelen Pro tokollverarbeitung vorgestellt und bewertet In dieser Arbeit soll das Konzept der Paketparallelit t f r die parallele Proto kollanalyse verwendet werden Ausschlaggebend f r diese Wahl ist die Leistungsf higkeit des Konzeptes bei hoher Last und die vergleichsweise leichte Realisierbarkeit Au erdem lassen sich Erweiterungen bei diesem Konzept besonders leicht durchf hren Durch diese Merkmale gen gt das Konzept auch den Anforderungen an Leistungsf hig keit und Skalierbarkeit vgl Abschnitt 2 7 2 und 2 7 3 Ein weiterer wichtiger Grund ist da durch kleine nderungen die Paketparalle lit t z B in eine Protokollpipeline umgewandelt werden kann Das k nnte f r einen Leistungsvergleich der beiden Ans tze interessant se

Download Pdf Manuals

Related Search

Related Contents

FJ-540, Manual del Usuario  Samsung WDF900C Combo พร้อมด้วย Huge Inside, 12 กก. คู่มือการใช้งาน  SKV-250AT-ACC 取扱説明書ダウンロード  I Installazione, uso e manutenzione pag. 2 UK Installation  TSX57 Ethernet  BOND + SEAL POWER (K+D)  Guia de referência rápida - Epson America, Inc.  HERMA File labels A4 192x59 mm white paper matt opaque 100 pcs.  Samsung SV-DVD1 Manuel de l'utilisateur  Des interfaces pour la mise en espace du son avec la bibliothèque  

Copyright © All rights reserved. Failed to retrieve file