Diplomarbeit D341 Entwicklung einer Client-/Server

Lehrstuhl für
Datenverarbeitung
Prof. Dr.-Ing. Dr. E.h. Wolfgang Weber
Diplomarbeit D341
Entwicklung einer Client-/Server-Applikation zum
Informationsaustausch von Systemdaten zwischen entfernten Systemen
Durch die zunehmende Vernetzung ist es möglich, die nicht genutzten Ressourcen andere
Rechner zu benutzen. Dazu müssen jedoch die Systemdaten bekannt sein.
Des weiteren wird ein Sicherheitsrisiko durch Kopplung von Rechnern über ein
Netzwerk erzeugt. Durch kontinuierliche Ermittlung der aktuellen Systemdaten und
Analyse der aufgenommenen Informationen kann somit ein Rückschluß auf eine
mögliche Sicherheitsverletzung bzw. einen Mißbrauch des Systems aufgedeckt werden.
Ziel dieser Arbeit ist es nunmehr, zwischen Rechnern einen Informationsaustausch ihrer
Systeminformationen zu ermöglichen. Dazu soll eine Client-/Server-Applikation implementiert werden, welche den Datenaustausch über die Protokollfamilie TCP/IP ermöglicht.
Die zu entwickelnde Software ist auf allen am Informationsaustausch beteiligten Systemen zu installieren. Es soll ein Algorithmus entwickelt werden, der einen entsprechenden Rechners nicht nur im eigenen, sondern auch in benachbarten und entfernten Netzwerksegmenten erkennt. Die erfaßten Daten sind in Listen zu führen, welche periodisch
aktualisiert werden. Um jederzeit ein Überblick der verfügbaren Systeme zu erhalten, soll
zwischen den erkannten Rechnern permanent eine automatisierte Synchronisation der
Systeminformationen stattfinden.
Zu Auswertungszwecken sind die erfaßten Daten in einem geeignete Datenbankformat
zusätzlich an jedem Rechner lokal zu sichern.
Die Client-/Server-Applikation ist unter MS Windows NT mittels MS Visual C++ zu
realisieren. Alle Entwicklungsschritte sind zudem projektbegleitend zu dokumentieren.
(Prof. Dr.-Ing. Wolfgang Weber)
Bearbeiter:
Matrikel-Nummer:
Betreuer:
Ausgabetag:
Abgabetag:
cand.-Ing. Volker Schüppel
108 093 216 367
Dipl.-Ing. Thomas Droste
31.03.1999
30.09.1999
Inhalt
Inhalt
1
2
Einführung .......................................................................................................... 3
Die Client-/Server-Architektur............................................................................. 4
2.1 Die Peer-to-Peer Architektur............................................................................ 5
2.2 Mischformen ................................................................................................... 6
3
Die TCP/IP Protokollfamilie................................................................................ 7
3.1 Das Internet Protocol ....................................................................................... 7
3.1.1 Die Internet-Protokoll-Adressen ............................................................... 8
3.1.2 Subnetze................................................................................................... 9
3.1.3 Reservierte Adresse................................................................................ 10
3.2 Das Transmission Control Protocol................................................................ 11
3.2.1 Der Protokoll-Kopf ................................................................................ 11
3.2.2 Die Phasen einer TCP-Verbindung......................................................... 14
3.2.3 TCP-Ports............................................................................................... 17
4
Das Domain Name System ................................................................................ 18
4.1 Die Datei hosts .............................................................................................. 18
4.2 Komplexe Netzwerke .................................................................................... 18
4.3 Server-Funktionalität ..................................................................................... 19
5
Pflichtenheft ...................................................................................................... 20
5.1 Zielbestimmung............................................................................................. 20
5.1.1 Mußkriterien .......................................................................................... 20
5.1.2 Wunschkriterien ..................................................................................... 20
5.1.3 Abgrenzungskriterien ............................................................................. 20
5.2 Produkteinsatz ............................................................................................... 20
5.2.1 Anwendungsbereiche ............................................................................. 20
5.2.2 Zielgruppen ............................................................................................ 21
5.2.3 Betriebsbedingungen .............................................................................. 21
5.3 Produktumgebung.......................................................................................... 21
5.3.1 Software................................................................................................. 21
5.3.2 Hardware................................................................................................ 21
5.3.3 Orgware ................................................................................................. 21
5.3.4 Produktschnittstellen .............................................................................. 21
5.4 Produktfunktionen ......................................................................................... 21
5.4.1 Zusammenstellen der eigenen Systemdaten ............................................ 21
5.4.2 Systemdatenaustausch ............................................................................ 22
5.4.3 Datenarchivierung .................................................................................. 22
5.5 Produktdaten.................................................................................................. 22
1
Inhalt
5.5.1 Systemdaten ........................................................................................... 22
5.6 Produkt-Leistungen........................................................................................ 23
5.7 Benutzungsschnittstelle.................................................................................. 23
5.8 Qualitäts-Bestimmung ................................................................................... 23
5.9 Globale Testfälle ........................................................................................... 23
5.10 Entwicklungsumgebung................................................................................. 24
6
Der Scanner....................................................................................................... 25
6.1 Die Host-Erkennung ...................................................................................... 25
6.2 Die Applikations-Erkennung ......................................................................... 26
6.3 Zweistufiges Verfahren.................................................................................. 27
6.4 Parallele Verarbeitung ................................................................................... 28
7
Die Kommunikation mit anderen Rechnern ....................................................... 29
7.1 Das Übertragungsprotokoll ............................................................................ 29
7.2 Der Kommunikationsablauf ........................................................................... 31
8
Das Programm Systemdetector .......................................................................... 33
8.1 Der Programmablauf ..................................................................................... 33
8.1.1 Der Programmstart ................................................................................. 33
8.1.2 Der Ablauf der Ausführungspfade .......................................................... 37
8.2 Die Dialogfelder ............................................................................................ 43
8.2.1 Der Hauptdialog ..................................................................................... 43
8.2.2 Der Details-Dialog ................................................................................. 45
8.2.3 Der Optionen-Dialog.............................................................................. 46
8.2.4 Der About-Dialog ................................................................................... 47
8.3 Die Ausgabedatei........................................................................................... 48
8.4 Die Konfigurationsdatei................................................................................. 49
8.5 Die Objekte der Applikation .......................................................................... 50
8.5.1 Die Strukturen der Applikation............................................................... 51
8.5.2 Die Klassenbeschreibung ....................................................................... 52
9
Tests.................................................................................................................. 55
9.1 Applikationsstabilität prüfen.......................................................................... 55
9.2 Erkennen aller Rechner im Netzwerk............................................................. 57
9.3 Zusammenschluß mehrerer Rechner .............................................................. 59
9.4 Ordentliches Beenden des Programmes ......................................................... 61
9.5 Programmabsturz simulieren ......................................................................... 63
9.6 Netzwerkstörung simulieren .......................................................................... 65
10 Probleme und Ausblick...................................................................................... 67
11 Literatur............................................................................................................. 68
Anhang...................................................................................................................... 70
2
Kapitel 1
Einführung
1 Einführung
Die Systemdaten eines Rechners können für den Benutzer eines Systems von großem
Interesse sein. Diese Daten geben Aufschluß über verwendete Hard- und Software,
Konfiguration und die Leistungsfähigkeit des Systems. Außerdem können nicht genutzte Ressourcen angezeigt werden. Manchmal kann es sinnvoll sein, nicht nur die
eigenen Systemdaten zu kennen, sondern auch diejenigen benachbarter Systeme.
Beispielsweise könnte durch die Aufnahme der aktuellen Systemdaten ein Rückschluß
auf eine mögliche Sicherheitsverletzung des Systems aufgedeckt werden. Um dies zu
realisieren ist eine Applikation notwendig, die auf der einen Seite die eigenen Daten
ermitteln und auf der anderen Seite mit anderen Systemen kommuniziert, um diese
Informationen auszutauschen. Die Applikation muß auf jedem Rechner laufen, der an
diesem Informationsaustausch teilnimmt. Die Kommunikation wird mit Hilfe eines
bestehenden Netzwerks unter Verwendung der Protokollfamilie TCP/IP realisiert. Der
Datenaustausch findet nach dem Prinzip der Client-/Server-Archiktektur statt. Dabei
fungiert jeder Rechner auf dem die Anwendung läuft als Server, der die Anfragen der
Clients beantwortet. Gleichzeitig besitzt jeder Rechner mehrere Clients, die Serveranfragen an andere Rechner stellen. Bevor ein Datenaustausch zwischen zwei Systemen stattfinden kann, muß den beiden Systemen die gegenseitige Erreichbarkeit bekannt sein. Um ein System im Netzwerk zu finden, auf dem die gleiche Applikation
läuft, bedarf es eines Algorithmus, der einen entsprechenden Rechner im Netzwerk erkennen kann. Um die erfaßten Daten ständig zu aktualisieren, muß die sich Kommunikation zwischen den Systemen periodisch wiederholen. Die Daten werden dann
auf jedem System in einer Rechnerliste geführt, welche zu Auswertungszwecken in
eine Datei exportiert werden.
3
Kapitel 2
Die Client-/Server-Architektur
2 Die Client-/Server-Architektur
Es gibt viele Möglichkeiten eine Netzwerk-Applikationen zu implementieren. Trotz
dieser vielen Unterschiede zwischen den unterschiedlichen Diensten und Protokollen,
lassen sich alle Netzwerk-Programme auf ein einfaches Modell, die Client/ServerArchitektur reduzieren.
Jede Netzwerk-Applikation besitzt einen Kommunikations-Endpunkt. Dabei existieren
zwei Typen von Endpunkten: Clients und Server. Der Server stellt seine Dienste im
Netzwerk bereit. Dies sind im allgemeinen spezielle Anwendungen, die auf eine
Verbindungsanforderung warten, um auf diese entsprechend zu antworten. Ein Client
nimmt einen Dienst eines Servers in Anspruch, indem er zu diesem Server eine Verbindung initiiert. Dabei geht der erste Kontakt geht immer von einem Client aus (vgl.
Abbildung 2-1).
Versucht, Verbindung zu öffnen
1.
Nimmt Verbindungsgesuch an
2.
Client
Server
Nachrichtenaustausch in beiden Richtungen
3.
Abbildung 2-1: Kommunikationsablauf zwischen Client und Server
Da die Client-/Server-Architektur auf einem verbindungsorientierten Dienst basiert,
bedarf es für die praktische Durchführung die Verwendung eines verbindungsorientierten Protokolls. In TCP/IP-Netzwerken werden Verbindungen mit Hilfe des TCP1
realisiert (vgl. Kapitel 3.2). Durch die Verwendung von Ports werden einem Kommunikations-Endpunkt Anschlüsse zur Verfügung gestellt. Diese werden dazu verwendet, die Netzwerkverbindung zur richtigen Anwendung weiterzuleiten (vgl.
Abbildung 2-2).
Ein Client bzw. Server verwendet bei seiner Kommunikation mindestens einen Port.
Der Server überprüft diese Ports auf eingehende Anfragen und nimmt darauf Verbindungen zu einem Client an. Der Client sendet seine Verbindungsanforderungen
über den verwendeten Port.
Da ein TCP/IP-Knoten im allgemeinen über 216=65536 verschiedene Ports verfügt, ist
es möglich, daß auf einem System mehrere Server, mehrere Clients, oder Mischformen
gleichzeitig als Applikation laufen. Dabei ist lediglich zu beachten, daß Ports exklusiv
von jeder Applikation verwendet werden müssen (vgl. Kapitel 3.2.3).
1
TCP – Transmission Control Protocol
4
Kapitel 2
Die Client-/Server-Architektur
Netzwerkschnittstelle
Port 50
Anwendung 1
Port 100
Anwendung 2
Port 1100
Anwendung 3
Abbildung 2-2: Ports
Ein typischer Einsatz für einen Server, ist die Verwendung als Fileserver in einem
lokalen Netzwerk. Dabei greifen viele Clients auf diesen Dienst des Servers zu (vgl.
Abbildung 2-3).
Client
Client
Fileserver
Client
Client
Abbildung 2-3: Fileserver
Der Server ist in diesem Fall unter Umständen die herausragende Maschine, welche im
allgemeinen aufwendiger und teurer ist. Er stellt den Clients seinen Massenspeicher
zur Verfügung, der den einzelnen Clients z.B. fehlt. Hier werden die Vorteile dieser
Architektur deutlich. Nur beim Server handelt es sich um eine eventuell aufwendige
und teure Maschine. Es können jedoch alle Clients von den Diensten des Servers
profitieren.
2.1 Die Peer-to-Peer Architektur
Die Peer-to-Peer-Architektur geht einen anderen Weg. Hierbei stellt jeder Knoten des
Netzwerks gleichzeitig einen Client und einen Server dar (vgl. Abbildung 2-4).
Alle Knoten sind als gleichwertig zu betrachten. Dadurch ist auch der Aufwand, der an
jedem Knoten betrieben werden muß gleich groß. Ob dies ein Vorteil oder ein Nachteil
gegenüber der eigentlichen Client-/Server-Architektur bedeutet, muß im Einzelfall
geprüft werden.
5
Kapitel 2
Die Client-/Server-Architektur
Client
+
Server
Client
+
Server
Client
+
Server
Abbildung 2-4: Peer-to-Peer
2.2 Mischformen
In den vorangegangenen Strukturen fungierte ein Rechner als Client oder als Server,
oder als Client und Server (Peer-to-Peer). Es sind jedoch auch Mischformen möglich,
in denen mehrere Client- bzw. mehrere Server-Applikationen auf einem Rechner
laufen (vgl. Abbildung 2-5).
Client B
Client C
Server A
Client A
Client C
Server B
Client A
Client B
Server C
Abbildung 2-5: 2 Clients / 1 Server
In dem Beispiel besitzt jeder Rechner einen Server und zwei Clients. Aus der Sicht
eines Rechners besitzt er genau einen Client für jeden anderen Server, um Anfragen zu
stellen. Ein Rechner hat aber nur einen Server um Anfragen zu beantworten.
Der umgekehrte Fall ist auch denkbar. Dabei besitzt jeder Rechner einen Client, um
seine Anfragen zu stellen und mehrere Server, um Anfragen anderer Clients zu beantworten (vgl. Abbildung 2-6).
Server B
Server A
Server C
Client A
Server C
Client B
Server A
Server B
Client C
Abbildung 2-6: 2 Server / 1 Client
6
Kapitel 3
Die TCP/IP Protokollfamilie
3 Die TCP/IP Protokollfamilie
Im 7 Schichten ISO1-OSI2-Modell (vgl. Tabelle 3-1) ist das Internet Protokoll (IP) auf
Ebene 3 und das Transmission Control Protocol (TCP) auf Ebene 4 angeordnet
[WAS94].
Schicht Funktion
7
6
5
4
3
2
1
Anwendung
Darstellung
Kommunikationssteuerung
Transport
Vermittlung
Sicherung
Physikalisch
Tabelle 3-1: ISO-OSI-Schichtenmodell
3.1 Das Internet Protocol
Beim Internet Protocol (IP) handelt es sich um ein verbindungsloses Vermittlungsprotokoll. Es ist für die Übertragung zum richtigen Rechner im richtigen Netzwerk
verantwortlich, d.h. die Routenwahl zwischen unterschiedlichen Netzwerken wird
durch das IP mitbestimmt. Dabei ist zu beachten, daß das Internet Protokoll ein verbindungsloser Datagramm-Dienst ist. Es muß zwischen dem Sender und dem
Empfänger keine Verbindung aufgebaut werden, um Daten zu übermitteln. Der Sender
sendet die Daten direkt an den Empfänger, ohne vorher die Erreichbarkeit geprüft zu
haben. Der Empfänger sendet keine Empfangsbestätigung für erhaltene IP-Datagramme, wodurch die Übertragung von IP-Datagrammen unsicher und Datenverluste
keinesfalls ausgeschlossen werden können. Ein Protokoll der höheren Schichten (z.B.
ein Transportprotokoll) muß dann für eine sichere Übertragung sorgen.
Bei einer Übertragung auf IP-Ebene ist zwischen zwei Kommunikationsknoten keine
spezielle Route definiert, welche die IP-Datagramme durchlaufen müssen. Deshalb ist
es möglich, daß die IP-Datagramme zwischen einem Start- und Zielsystem unterschiedliche Routen nehmen und möglicherweise in falscher Reihenfolge beim Em-
1
ISO - International Standard Organization
2
OSI - Open System Interconnection
7
Kapitel 3
Die TCP/IP Protokollfamilie
pfänger ankommen. Das Internet Protokoll stellt keine Funktionen bereit, welche die
richtige Reihenfolge der Datagramme wieder herstellt. Diese Aufgabe kann ebenfalls
nur von einem Protokoll einer höheren Schicht übernommen werden.
Das Adressieren und Fragmentieren von Datagrammen und die Ermittlung des passenden TOS (type of service) oder Diensttyps gehören zu den elementaren Funktionen
des Internet Protokolls. Die anderen Funktionen bzw. Optionen spielen meist eine
untergeordnete Rolle und sind in [STE94] aufgeschlüsselt.
3.1.1 Die Internet-Protokoll-Adressen
Die Internet-Protokoll-Adresse hat eine Länge von 32 Bit und ist Teil des InternetProtokoll-Kopfes. Sie beschreibt die Bindung (Schnittstelle) von genau einem Host
(Rechner) zu einem Netzwerk. Ein Host mit mehr als einer Schnittstelle zu einem oder
verschiedenen Netzwerken besitzt auch mehrere IP-Adressen. Für jede Bindung muß
genau eine IP-Adresse vergeben sein. Nur in Ausnahmefällen können zwei Schnittstellen die gleiche IP-Adresse besitzen. Ist ein Host mit mehreren Bindungen ferner in
der Lage zwischen diesen Bindungen IP-Datagramme weiterzuleiten, so wird er als IPRouter, Bridge oder Gateway bezeichnet.
Die IP-Adressen erfüllen zwei wichtige Aufgaben. Erstens identifizieren sie genau
eine Schnittstelle, da sie exklusiv vergeben werden müssen, zweitens identifizieren die
IP-Adressen das Netzwerk, in dem diese Bindung vorhanden ist.
Die IP-Adresse besteht aus 4 Bytes bzw. 32 Bit, die in 4er Tupel angegeben werden.
Jede Zahl kann einen Wert zwischen 0 und 255 annehmen, woraus sich folgende
Darstellung ergibt:
134.147.1.1 = 10000110100100110000000100000001 |2
Eine IP-Adresse ist in zwei logische Teile unterteilt. Sie besteht aus der Netzwerknummer und der Hostnummer. Im ersten Teil steht die Netzwerknummer, die Hostnummer befindet sich im zweiten Teil der IP-Adresse. Die Grenzen dieser Adressteile
sind abhängig von der Adressklasse (vgl. Abbildung 3-1).
Abbildung 3-1: Netz- und Hostteil der Adressklassen
8
Kapitel 3
Die TCP/IP Protokollfamilie
Die Klassen A, B und C sind die drei wichtigsten Adressklassen. Die Klassen D und E
stehen nicht zur allgemeinen Verfügung und sind nur aufgrund der Vollständigkeit
hier erwähnt. Der mögliche Adressbereich ist in Tabelle 3-2 angegeben.
Klasse
A
B
C
D
E
Erste Adresse
1.0.0.0
128.1.0.0
192.0.1.0
224.0.0.0
240.0.0.0
Letzte Adresse
127.255.255.255
191.255.255.255
223.255.255.255
239.255.255.255
247.255.255.255
Tabelle 3-2: Adressbereiche der Adressklassen
Die IP-Adresse und damit auch die Adressklasse müssen vom jeweiligen Administrator für einen Host eingestellt werden. Es muß beachtet werden, daß alle Adressen
exklusiv vergeben werden müssen. Falls das Internet mit neuen Netzen bereichert
werden soll, so muß auf Adressen zurückgegriffen werden, die sonst noch niemand
verwendet. Die Adressen bzw. die Adressklassen für das Internet werden vom NIC1
eindeutig vergeben.
3.1.2 Subnetze
Jedes Klasse A-Netz kann theoretisch bis zu 16 Millionen Hosts beinhalten. Eine
Anzahl von 16 Millionen Hosts können aber in der Praxis nicht über ein einziges
Übertragungsmedium miteinander kommunizieren. Die Performance, die unter allen
Hosts aufgeteilt wird, tendiert praktisch gegen Null. Eine zusätzliche Unterteilung
eines Netzwerkes in Subnetze ist erforderlich, was durch die Angabe der Subnetzmaske erreicht wird. Durch die Subnetzmaske kann ein Host feststellen, ob eine
Übertragung an einen anderen Host direkt im eigenen Subnetz gesendet werden kann,
oder ob die Nachricht über einen Router, welcher die Schnittstelle zu einem benachbarten Netzwerk oder Subnetz darstellt, geleitet werden muß. Mit Hilfe der Subnetzmaske kann ein Host ermitteln, ob sich der andere Host im gleichen Subnetz befindet,
oder nicht. Eine Subnetzmaske hat die gleiche Form wie eine IP-Adresse und wird
genauso als 4er Tupel gelesen. Die 32 Bit einer Subnetzmaske sind in 3 Teile unterteilt
(vgl. Abbildung 3-2). Der Netzwerk- und der Subnetzteil bestehen immer aus „1“en,
der Hostteil immer aus „0“en. Entscheidend sind die Grenzen der einzelnen Teile.
1
NIC - Network Information Center
9
Kapitel 3
Die TCP/IP Protokollfamilie
Netzwerkteil
Subnetzteil
Hostteil
Abbildung 3-2: Aufbau der Subnetzmaske
Bevor ein Sender einem Empfänger ein IP-Paket zusendet, prüft er, ob sich der
Empfänger im selben Subnetz befindet, oder nicht. Dies ermöglicht die Subnetzmaske
mit Hilfe eines Bitvergleiches. Dazu werden die Bits der Sender- und Empfängeradresse verglichen, die in der Subnetzmaske den Wert „1“ haben. Sender und Empfänger liegen im gleichen Subnetz, wenn die Bits übereinstimmen. Für den Fall, daß die
beiden Hosts nicht in einem Subnetz liegen, muß der Sender seine Nachricht an einen
IP-Router senden, der diese dann weiterleitet [STE94].
Host A
Host B
Subnetzmaske
Netzwerkteil
Subnetzteil
Hostteil
IP-Adresse
192.168.20.2
192.168.20.254
255.255.255.192
255.255.255.xxx
IP-Adresse bitweise ausgeschrieben
11000000101010000001010000000010
11000000101010000001010011111100
11111111111111111111111111000000
111111111111111111111111xxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxx11xxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxx000000
Tabelle 3-3: Beispiel
In dem Beispiel aus Tabelle 3-3 liegen die beiden Hosts im gleichen Netzwerk, da alle
Bits der beiden IP-Adressen übereinstimmen, die im Netzwerkteil der Subnetzmaske
den Wert „1“ besitzen. Da die Bits im Subnetzteil der beiden Hosts sich unterscheiden,
befinden sich die beiden Hosts nicht im gleichen Subnetz. Der Sender muß sein IPPaket zu einem IP-Router senden, der dieses weiterleitet.
3.1.3 Reservierte Adresse
Die Adresse 127.0.0.1 ist für die Rückkopplungsschleife (loopback) reserviert. Falls
eine Nachricht an die Adresse 127.0.0.1 gesendet wird, ist immer der eigene Host der
Empfänger. Der gesamte Adressbereich 127.xxx.xxx.xxx kann keinem Host zugeordnet werden.
Die erste und die letzte IP-Adresse in einem Subnetz sind für die Netzwerk- und die
Broadcast-Adresse reserviert. Sie dürfen ebenfalls keinem Host zugeordnet werden.
10
Kapitel 3
Die TCP/IP Protokollfamilie
3.2 Das Transmission Control Protocol
Beim Transmission Control Protocol (TCP) handelt es sich um ein TransportProtokoll, welches im 7 Schichten-Modell auf Ebene 4 einzuordnen ist (vgl. Tabelle
3-1). Durch das TCP wird die Zuverlässigkeit einer Übertragung auf der IP-Ebene
erhöht. Außerdem wird durch den Gebrauch von Port-Nummern die Adressierung von
Diensten der Anwendungsschicht ermöglicht. Das TCP ist ein verbindungsorientiertes
Protokoll. Es ist erforderlich, daß eine Verbindung zwischen zwei Rechnern eingerichtet wird, bevor Daten übertragen werden können. Nach der Datenübertragung wird
die Verbindung wieder getrennt. Die gesteigerte Zuverlässigkeit wird durch folgende
Mechanismen erreicht:
• Fehler-Erkennung und Fehler-Korrektur
• Fluß-Kontrolle
• Neuordnung der Übertragung-Sequenzen
• Entfernung doppelter Segmente1
Durch die Fehler-Erkennung und Fehler-Korrektur werden die Segmente behandelt,
die durch Übertragungsfehler verfälscht übertragen worden sind. Die Flußkontrolle
reguliert die Aussenderate des Senders, um einen Datenüberlauf beim Empfänger zu
verhindern. Die erhaltenen Sequenzen müssen am Empfänger neu angeordnet werden,
da von der IP-Schicht, die TCP-Segmente in beliebiger Reihenfolge übertragen
werden können. Dieser Fall tritt häufig auf, wenn die IP-Datagramme unterschiedliche
Routen verwendet haben. Durch erneutes Senden (vgl. Kapitel 3.2.2.2) des Senders
können doppelte Segmente am Empfänger entstehen. Diese müssen durch die FehlerKorrektur-Mechanismen vom TCP entfernt werden. Es wird folgendermaßen vorgegangen, um diese Funktion in das TCP zu implementieren:
• Verwendung von Sequenz-Nummern zur Kennzeichnung der Daten
• positive Rückmeldung, wenn Daten in der richtigen Reihenfolge empfangen
worden sind
• Erneute Sendung von Segmenten, für die innerhalb eines bestimmten Zeitraums
keine Empfangsbestätigung eingegangen ist.
3.2.1 Der Protokoll-Kopf
Das TCP besitzt einen komplexen Protokoll-Kopf (vgl. Abbildung 3-3). Der Kopf beinhaltet ein Absender- und ein Empfänger-Feld. Die anderen Felder dienen der
Steuerung der Kommunikation und der Erhöhung der Zuverlässigkeit.
1
Segmente – Datenblöcke, die vom TCP an das IP übergeben werden
11
Kapitel 3
Die TCP/IP Protokollfamilie
Absender-Port
Empfänger-Port
Sequenznummer
Bestätigungsnummer
Daten-Offset
Reserviert
Code
Fenster
Prüfsumme
Dringlichkeitszeiger
Optionen
Füllzeichen
Daten
Abbildung 3-3: TCP-Protokollkopf
3.2.1.1 Die Sequenznummer
Die Sequenznummer im Steuerkopf eines Segments gibt an, an welcher Position sich
das erste Oktett dieses Segments im Datenstrom befindet. Wird eine neue TCPVerbindung initialisiert, so tauschen Sender und Empfänger zunächst die zu
verwendenden Sequenznummern aus. Nach dem Beenden einer Verbindung werden
die Sequenznummern nicht auf Null zurückgesetzt, sondern werden bei der nächsten
Verbindung weiter um Eins erhöht, solange, bis sie den Höchstwert von 2³²-1 (≈4
Milliarden) erreicht haben. Danach beginnt der Zähler wieder bei Null. Dieser Mechanismus ist vorgesehen worden, damit auch in einem schnellen Netzwerk keine
gleichen Sequenznummern kurz hintereinander auftreten können [WAS94].
Angenommen, die IP-Implementierung gibt die Datagramme in der richtigen Reihenfolge an das TCP weiter, so wird die Sequenznummer stetig um Eins erhöht. Durch die
Übertragung auf der IP-Ebene ist jedoch nicht sichergestellt, daß die IP-Datagramme
in der Richtung Reihenfolge beim Empfänger eintreffen. Treffen die Datagramme in
der falschen Reihenfolge ein, so lassen sich die korrekten Positionen der TCPSequenzen mit Hilfe der Sequenznummern zurückgewinnen.
3.2.1.2 Die Bestätigungsnummer
Diese Nummer hat die Funktion, den korrekten Empfang einer Sequenz zu bestätigen.
Die Bestätigungsnummer ist nur gültig, falls das ACK-Flag gesetzt ist (vgl. Tabelle
3-4). Ist am ursprünglichen Datensender eine Bestätigung vom Empfänger eingetroffen, so kann der Sender die ursprünglichen Daten verwerfen, die er für eine erneute
Sendung zurückgehalten hat. Ist innerhalb einer definierten Zeitspanne keine Bestätigung vom Empfänger gesendet worden, so wiederholt der Sender die Sendung. Diese
Zeitgrenze (Timeout) kann auf der Senderseite für jede Verbindung gesetzt werden.
Die Bestätigungsnummer, die der Empfänger mitsendet, ist die Sequenznummer des
Senders, die im nächsten sinnvollen Datensegments eingetragen wird.
12
Kapitel 3
Die TCP/IP Protokollfamilie
3.2.1.3 Der Daten-Offset
Dieser Wert gibt die Länge des TCP-Protokollkopfes in 32-Bit-Wörtern an. Falls
Optionen (vgl. Kapitel 3.2.1.8) leer ist, so hat der gesamte Protokollkopf ein Länge
von 160 Bit (= 5⋅32 Bit). In das Feld Daten-Offset wird in diesem Fall der Wert 5
eingetragen.
3.2.1.4 Die Flags
Die Flags zeigen an, welche der anderen Felder im TCP-Protokoll-Kopf gültige Werte
beinhalten (vgl. Tabelle 3-4).
Flag
URG
ACK
PSH
RST
SYN
FIN
Beschreibung
Zeigt die Gültigkeit des Dringlickeitszeigers an. Das Flag wird gesetzt,
wenn eine dringende Nachricht über das Netz an eine Anwendung übertragen werden muß.
Zeigt die Gültigkeit der Bestätigungsnummer an.
Weist die TCP-Implementierung an, dieses Segment sofort weiter zu
verarbeiten. Im Regelfall werden eine Anzahl von Segmenten im Empfangspuffer gesammelt, die gemeinsam verarbeitet werden.
Zeigt einen schwerwiegenden Fehler an, der eine Verbindungsauflösung erfordert. Es wird nur im äußersten Notfall verwendet.
Wird zur Initialisierung einer Verbindung verwendet. In diesem Stadium einigen sich Sender und Empfänger auf die zu verwendenden Bestätigungs- und Sequenznummern.
Wird zum Beenden einer Verbindung verwendet. Sobald ein Endknoten
alle Daten übertragen hat, sendet er ein Segment, welches das FIN-Flag
gesetzt hat. Sobald beide Endknoten eine solches Segment gesendet
haben, wird die Verbindung aufgelöst.
Tabelle 3-4: Flags des TCP
3.2.1.5 Fenster
Dieses Feld gibt die Größe des Puffers an, die der Sender für diese Verbindung reserviert hat. Es dürfen nicht mehr Daten als diese Puffergröße gesendet werden, bevor
eine Empfangsbestätigung eingegangen ist.
3.2.1.6 Prüfsumme
Die Prüfsumme überprüft den korrekten Empfang des TCP-Protokoll-Kopf und den
eigentlichen Daten. Sie berechnet sich aus dem 16 Bit großen Einerkomplement der
Summe der Einerkomplemente aller 16 Bit Worte in Protokoll-Kopf und Daten.
13
Kapitel 3
Die TCP/IP Protokollfamilie
3.2.1.7 Dringlichkeitszeiger
Dieses Feld beinhaltet einen Wert, der auf das Ende der Daten des Datenfeldes, das als
dringlich gilt, zeigt. Dieses Datenfeld soll sofort bearbeitet werden.
3.2.1.8 Optionen
Hiermit wird der TCP-Implementierung des Empfängers die Option MSS1 mitgeteilt.
Diese Option gibt die maximale Größe der Segmente an, die gesendet werden.
3.2.1.9 Füllzeichen
Falls das Feld Optionen gültig ist, werden in Füllzeichen so viele Bits eingefügt, daß
der gesamte TCP-Protokoll-Kopf ein Länge hat, die ein Vielfaches von 32 Bit ergibt
(vgl. Kapitel 3.2.1.3).
3.2.2 Die Phasen einer TCP-Verbindung
An einem Beispiel soll exemplarisch der Ablauf einer kompletten Datenübertragung
auf TCP-Ebene gezeigt werden. Dazu wird dieser Ablauf in drei Phasen, die Einrichtungsphase, die Datenaustauschphase und die Abschlußphase eingeteilt.
3.2.2.1 Die Einrichtungsphase
Auf dem Sendesystem fordert eine Anwendung der höheren Schichten eine Verbindung zu einem entfernten System an und initiiert damit eine Verbindung auf TCPEbene (vgl. Abbildung 3-4). Die TCP-Implementierung erzeugt ein Segment und gibt
es an die IP-Schicht weiter, die daraus ein IP-Datagramm erzeugt. Im TCP-Segment ist
das SYN-Flag gesetzt, um dem Empfänger-System zu signalisieren, daß sich die
beiden Systeme auf die gültigen Sequenz- und Bestätigungsnummern einigen müssen.
Das Sende-System trägt seine aktuelle Sequenznummer in das Segment ein. Die Bestätigungsnummer darf nicht eingetragen werden. Das ACK-Flag wird nicht gesetzt.
Das Empfänger-System antwortet mit einem TCP-Segment in dem das SYN- und das
ACK-Flag gesetzt sind. Als Sequenznummer wird der eigene aktuelle Wert eingetragen. Die Bestätigungsnummer erhält den um Eins erhöhten Wert der Sequenznummer des gerade empfangenen Segments. Das Sende-System bestätigt dieses
Segment, indem das ACK-Flag gesetzt wird. Die Bestätigungsnummer enthält die
erhöhte Sequenznummer des Empfänger-Systems.
Damit ist die TCP-Verbindung eingerichtet und die Sequenznummern ausgetauscht.
Beide Stationen sind jetzt bereit, die eigentlichen Daten auszutauschen.
1
MSS - Maximum Segment Size
14
Kapitel 3
Die TCP/IP Protokollfamilie
Netz
Empfänger
Sender
SYN=153
ACK=?
SYN
153
kein
ACK
SYN=321
ACK=154
54
CK 1
A
321
SYN
SYN=154
ACK=322
ACK
322
Zeit
Abbildung 3-4: Einrichtungsphase
3.2.2.2 Die Datenaustauschphase
Um die Zuverlässigkeit einer Datenübertragung zu erhöhen, wird bei einer TCPVerbindung jedes gesendete Segment vom Empfänger bestätigt. Das folgende Beispiel
zeigt des einfachste Szenario, daß bei Datenübertragung stattfinden kann (vgl.
Abbildung 3-5).
Die Daten
“xx” werden
gesendet
S EQ
=10
2 AC
K=1
19 D
ata=
xx
Empfang
wird bestätigt
AC
=119
SEQ
03
K =1
Abbildung 3-5: Datenaustausch
15
Kapitel 3
Die TCP/IP Protokollfamilie
Der Sender sendet seine Daten an den Empfänger und erwartet ein Bestätigungssegment. Dabei wird am Sender ein Timer gestartet. Sollte die vorher festgelegte
Zeitgrenze für die Bestätigung überschritten werden, so werden die Daten vom Sender
erneut gesendet. Nach dem Empfang des Datensegmentes bestätigt dies der Empfänger
mit einem Segment welches ein leeres Datenfeld besitzt. Nachdem der Sender dieses
Bestätigungssegment empfangen hat, ist die Datenübertragung abgeschlossen.
3.2.2.3 Die Abschlußphase
Möchte eines der beteiligten Systeme die bestehende Verbindung beenden, so initiiert
es die Abschlußphase. Dabei sendet dieses System ein TCP-Segment in dem das FINFlag (vgl. Tabelle 3-4) gesetzt ist. Das andere System bestätigt zuerst den Empfang
mit einem Segment und antwortet dann mit einem zusätzlichen Segment in dem
ebenfalls das FIN-Flag gesetzt ist. Auch dieses Segment muß vom Sender noch einmal
bestätigt werden (vgl. Abbildung 3-6).
Sender
Netz
Empfänger
SEQ
=30
6 AC
K=5
17 F
IN
=307
ACK
IN
307 F
CK=
A
7
=51
SEQ
ACK
=518
Zeit
Abbildung 3-6: Trennen einer Verbindung
Die Verbindung wird nicht als geschlossen betrachtet, solange nicht beide Systeme
Segmente, in denen das FIN-Flag gesetzt ist, gesendet und den Empfang der FINSegmente bestätigt haben. Falls in dieser Phase Segmente verlorengehen, wird die
Verbindung nach Ablauf eines Timeout als getrennt betrachtet.
16
Kapitel 3
Die TCP/IP Protokollfamilie
3.2.3 TCP-Ports
Das TCP verwendet Port-Adressen, um Daten an die entsprechenden Dienste der
Anwendungsschicht zu senden. Ein Port ist eine Adresse mit der Länge von 16 Bit.
Der Bereich von 0 bis 255 ist für bekannte Dienste vordefiniert (vgl. Tabelle 3-5).
Dezimal
0
7
17
20
21
23
25
80
110
247-255
Schlüsselwort
Reserviert
ECHO
Quote
FTP-Data
FTP
Telnet
SMTP
HTTP
POP3
Reserviert
Beschreibung
Echo
Losung des Tages
Dateiübertragung (Daten)
Dateiübertragung (Steuerzeichen)
Telnet
SMTP-Dienst, E-Mail
WWW
POP3-Dienst, E-Mail
Tabelle 3-5: Einige reservierte TCP-Ports
Bei der Entwicklung eines Programms, welches mit dem TCP arbeitet, muß der zu
benutzende Port definiert werden. Port-Adressen müssen exklusiv vergeben werden,
da nicht zwei unterschiedliche Dienste der Anwendungsschicht auf den selben Port
zugreifen dürfen. Deshalb sollte bei der Entwicklung einer Software darauf geachtet
werden eine Port-Adresse oberhalb von 255 zu wählen.
Anstelle eines festen Ports können Anwendungen auch ein dynamisches Adressierungsverfahren verwenden. Das NFS1 verwendet die Funktion Portmapper, mit der
Port-Adressen dynamisch vergeben werden können bzw. mit der der Port, der von
einer bestimmten Anwendung benutzt wird, bei Anfrage ermittelt wird.
1
NFS – Network File System
17
Kapitel 4
Das Domain Name System
4 Das Domain Name System
Die numerische Adressierungsweise des IP-Protokolls erschwert den Umgang für den
Menschen. Für die Arbeit mit großen Systemen ist es deshalb erstrebenswert, ein
Namenssystem einzuführen, welches die Adressierung erleichtern soll. In TCP/IPSystemen läßt sich dies in zwei Variationen realisieren. Mit Hilfe einer individuellen
Datei, die an jedem Knoten des Netzwerks zur Verfügung steht, oder mit Hilfe eines
zentralen Dienstes.
In TCP/IP-Systemen werden eine Reihe von Mechanismen verwendet, um Namen in
IP-Adressen zu konvertieren. Der grundlegendste ist die Datei hosts, ein anderer das
Domain Name System (DNS).
4.1 Die Datei hosts
Die auf den Netzwerkknoten laufenden Betriebssysteme verwenden normalerweise die
Datei hosts. Über diese Datei ist es den Anwendungsprogrammen möglich, aus einem
Namen die dazugehörige IP-Adresse aufzuschlüsseln bzw. umgekehrt aus einer IPAdresse den Namen zu erhalten. Jede IP-Adresse, die in hosts geführt wird besitzt
mindestens einen Namenseintrag. Es können jedoch auch mehrere Namen für ein und
dieselbe IP-Adresse vergeben werden. Diese zusätzlichen Namen werden als Alias
bezeichnet.
4.2 Komplexe Netzwerke
Für die Verwendung in komplexen Netzwerken erweist sich die Datei hosts als unpraktikabel, da der Verwaltungsaufwand proportional zur Anzahl der Knoten steigt.
Mit einem Domainnamen kann ein Knoten, der im Internet registriert ist, eindeutig
identifiziert werden. Eine weitere Hauptfunktion des DNS besteht in der Übersetzung
dieser Namen in die zugehörigen eindeutigen IP-Adressen, da alle TCP/IP-Kommunikation auf Grundlage dieser IP-Adressen stattfindet. Die umgekehrte Übersetzung ist
ebenfalls möglich.
Das DNS stellt zusätzlich zu diesen Hauptfunktionen noch andere Funktionen zur
Verfügung. Die Definitionen sehen vor, daß auch die Anwendungstypen, die auf den
Knoten verfügbar sind, über das DNS bestimmt werden können.
Um mit Namen zu arbeiten, muß eine allgemeine Struktur definiert werden. Das DNS
ist hierarchisch und verwendet einzelne Komponenten in einem vollständigen Namen,
um die unterschiedlichen Verwaltungsebenen zu bezeichnen. Dies kann als umgekehrter Baum illustriert werden (vgl. Abbildung 4-1):
18
Kapitel 4
Das Domain Name System
de
ruhr-uni-bochum
etdv
et
thrall
theme
thunder
uni-essen
pc1
pc2
thread
Host-Domain-Namen:
1. thrall.etdv.ruhr-uni-bochum.de
2. theme.etdv.ruhr-uni-bochum.de
3. thunder.etdv.ruhr-uni-bochum.de
4. pc1.uni-essen.de
5. pc2.uni-essen.de
Abbildung 4-1: Beispiel DNS-Struktur
Die oberste Verwaltungsebene läßt sich als Wurzel bezeichnen. Sie kann in Äste (SubDomain) und Blätter (Host) aufgeteilt werden. Der Zusammenschluß gibt die weltweit
eindeutigen Rechnernamen wieder.
4.3 Server-Funktionalität
Für ein funktionierendes DNS-System bedarf es zwei Komponenten, den DNS-Client
und den DNS-Server. Der DNS-Client ist Bestandteil der Netzwerk-Implementierung,
die auf einem Host installiert ist. Er stellt Namensauflösungs-Anfragen an den DNSServer, um die zu einem Namen zugehörige IP-Adresse zu erlangen. Der DNS-Server
ist ein Dienst, welcher eine Datenbank führt, die eine ähnliche Struktur besitzt wie
eine hosts-Datei (vgl. Kapitel 4.1). Mit Hilfe dieser Datenbank lassen sich die
Anfragen der DNS-Clients beantworten. Dem DNS-Server müssen mindestens alle
Hosts bekannt sein, die sich innerhalb der Domäne befinden, welche er kontrolliert.
Wird von einem Client eine Namensauflösung einer anderen Domäne angefordert, so
gibt der DNS-Server diese Anfrage an den zuständigen übergeordneten DNS-Server
weiter.
19
Kapitel 5
Pflichtenheft
5 Pflichtenheft
5.1 Zielbestimmung
Die zu implementierende Software soll es einen Rechnersystem, auf dem die Software
installiert wird ermöglichen, sich in einen Rechnerverbund zu integrieren. Die Teilnehmer dieses Verbundes tauschen Systemdaten aus, die an jedem Rechner abrufbar
sind.
5.1.1 Mußkriterien
•
•
•
•
•
•
•
Die Suche nach einem bereits bestehenden Verbund im Netzwerk
Initialisierung eines neuen Verbundes
Senden der eigenen Systemdaten
Empfangen anderer Systemdaten
Speichern einer Rechnerliste auf einem lokalen Datenträger im CSV-Format
Löschen eines nicht mehr verfügbaren Rechners aus dem Rechnerverbund
Lauffähig unter MS Windows NT ohne Administrator-Rechte
5.1.2 Wunschkriterien
• Möglichst kurze Aktualisierungs-Intervalle, ohne das Netzwerk zu stark zu
belasten
• Minimale Prozessor-Belastung
• Hohe Stabilität bei langer Laufzeit
5.1.3 Abgrenzungskriterien
Die Software setzt ausschließlich auf das TCP/IP-Protokoll auf und ist mit anderen
Netzwerkprotokollen nicht lauffähig. Der Betrieb beschränkt sich auf das Betriebssystem MS Windows NT 4.0.
5.2 Produkteinsatz
Das Produkt dient zur Erkennung von Systemresourcen in einem Rechnerverbund.
Dabei sind aktuell verfügbare Ressourcen an jedem Rechner in einer Liste zu führen.
5.2.1 Anwendungsbereiche
• Systemmanagement
20
Kapitel 5
Pflichtenheft
5.2.2 Zielgruppen
• Keine besondere Spezifikation einer Zielgruppe
5.2.3 Betriebsbedingungen
• LAN1-Umgebung
• WAN2-Umgebung
5.3 Produktumgebung
5.3.1 Software
• Betriebssystem MS Windows NT
5.3.2 Hardware
• Die Hardwareanforderungen entsprechen dem des Betriebssystems
5.3.3 Orgware
• Applikation für jeden Kommunikationsteilnehmer erforderlich
• Netzwerkanbindung
5.3.4 Produktschnittstellen
Die aktuelle Rechnerliste wird in einer Datei auf einem lokalen Datenträger (primär
Festplatte) gespeichert. Eine Auswertung durch das Programm MS Excel soll möglich
sein.
5.4 Produktfunktionen
5.4.1 Zusammenstellen der eigenen Systemdaten
•
•
•
•
•
•
•
/F10/
/F20/
/F30/
/F40/
/F50/
/F60/
/F70/
Abfrage des Rechnernamens
Abfrage des Benutzernamens
Abfrage der IP-Adresse
Abfrage der MAC-Adresse
Abfrage der Subnetzmaske
Errechnen der Netzadresse
Ermittlung der Domäne aus dem kompletten DNS-Rechnernamen
1
LAN – Local Area Network
2
WAN – Wide Area Network
21
Kapitel 5
•
•
•
•
•
•
•
•
•
•
•
•
•
/F80/
/F90/
/F100/
/F110/
/F120/
/F130/
/F140/
/F150/
/F160/
/F170/
/F180/
/F190/
/F200/
Pflichtenheft
Abfrage des Betriebssystems und der Versionsnummer
Abfrage des Prozessorherstellers
Abfrage des Prozessortyps
Abfrage der Taktfrequenz des Prozessors
Abfrage der Anzahl der Prozessoren
Abfrage der momentanen Prozessorauslastung
Abfrage des Festplattenplatzes
Abfrage des frei verfügbaren Festplattenplatzes
Abfrage des physikalischen Speichers
Abfrage des frei verfügbaren physikalischen Speichers
Abfrage des virtuellen Speichers
Abfrage des frei verfügbaren virtuellen Speichers
Abfrage des Status des Bildschirmschoners
5.4.2 Systemdatenaustausch
•
•
•
•
•
•
/F210/
/F220/
/F230/
/F240/
/F250/
/F260/
Erkennung eines existierenden Rechners im gleichen Netzwerk
Erkennung einer existierenden Applikation im gleichen Netzwerk
Systemdaten von anderen Rechner anfragen und empfangen
Systemdatenanfragen von anderen Rechnern beantworten
Sortieren und Darstellen der Rechner-Liste auf dem Bildschirm
Periodische Aktualisierung der Rechner-Liste
5.4.3 Datenarchivierung
•
•
•
•
•
/F270/
/F280/
/F290/
/F300/
/F310/
Neuerstellung einer Archivdatei
Datenübernahme aus einer bestehenden Archivdatei
Aktualisierung einer bestehenden Archivdatei
Speichern der Rechnerliste und aller Systemdaten in der Archivdatei
Die Datei hat das CSV-Datenformat
5.5 Produktdaten
5.5.1 Systemdaten
• /D10/ Für jeden Rechner sind folgende Daten zu speichern:
Rechnername, Benutzername, Name der Domäne, IP-Adresse, Netzwerkadresse, Subnetzmaske, CPU-Typ, CPU-Geschwindigkeit, Festplattenplatz, freier Festplattenplatz, Hauptspeicher, freier Hauptspeicher,
virtueller Speicher, Status des Bildschirmschoners, Verbindungsbandbreite, Zeitpunkt des letzten Lebenszeichens
22
Kapitel 5
Pflichtenheft
5.6 Produkt-Leistungen
• /L10/ Die Aktualisierung (/F260/ und /F290/) sollte in Intervallen von variabler
Länge erfolgen. Anzustreben sind periodische Aktualisierungen im Bereich von wenigen Sekunden.
• /L20/ Die Rechnerliste besitzt keine Obergrenze für die Anzahl der beinhalteten Rechner.
5.7 Benutzungsschnittstelle
• /B10/ Die Rechnerliste ist über ein Listenfeld in einem Dialogfeld einsichtbar.
• /B20/ Es können Parameter zu Programmeinstellungen gesetzt werden
5.8 Qualitäts-Bestimmung
Produktqualität
Funktionalität
Zuverlässigkeit
Benutzbarkeit
Geschwindigkeit
Änderbarkeit
Stabilität
Verträglichkeit
Übertragbarkeit
sehr gut
gut
normal
nicht
relevant
X
X
X
X
X
X
X
X
Tabelle 5-1: Qualitätsbestimmung
5.9 Globale Testfälle
•
•
•
•
•
•
•
/T10/
/T20/
/T30/
/T40/
/T50/
/T60/
/T70/
Initialisierung eines Rechnerverbundes
Zusammenschluß mehrerer Rechner im gleichen Netzwerksegment
Auswertung der Archivdatei mittels MS Excel
Ordentliches Beenden des Programmes
Programmabsturz simulieren
Netzwerkstörung simulieren
Applikationsstabilität prüfen
23
Kapitel 5
Pflichtenheft
5.10 Entwicklungsumgebung
• MS Visual Studio C++
• MS Windows NT Workstation
24
Kapitel 6
Der Scanner
6 Der Scanner
Um den Austausch von Systemdaten zwischen Systemen zu ermöglichen, ist es notwendig, daß die entfernten Systeme die Existenz anderer Systeme erkennen. Weiterhin
muß erkannt werden, ob die Applikation, die den Datenaustausch ermöglicht, auf
einem existierenden System vorhanden ist. Dazu ist es notwendig, daß Netzwerk systematisch zu durchsuchen (Scannen). Der in die Applikation implementierte Scanner
geht dabei in zwei Schritten vor. Im ersten Schritt wird versucht einen Host zu
erreichen. Im zweiten Schritt wird versucht die Applikation zu erkennen.
6.1 Die Host-Erkennung
IP-Implementationen unterstützen im allgemeinen das Internet Control Message
Protocol (ICMP). Das ICMP ermöglicht den Versand von Nachrichten in einem IPNetzwerk zu Diagnose- bzw. Informations-Zwecken. Dazu transportiert das ICMP
seine Meldungen in IP-Datagrammen. Ein Teil des ICMP sind die Echo-Nachrichten.
Die Echo-Nachrichten werden am häufigsten zur Diagnose eines Netzwerkes herangezogen. Sendet der Absender ein Paket vom Typ Echo-Request an einen Empfänger,
so antwortet dieser mit einem Paket vom Typ Echo-Reply (vgl. Abbildung 6-1).
Echo request
Empfänger
Sender
Echo reply
Abbildung 6-1: Erkennen eines Hosts
Der Absender kann dabei eine Zeitschranke (Timeout) festlegen, in der eine Antwort
des anderen Systems erfolgen muß. Trifft keine Antwort innerhalb dieses Zeitraums
ein, so gilt das andere System als nicht erreichbar. Der Absender kann damit entscheiden, ob ein Hosts konnektierbar ist, oder nicht (vgl. Abbildung 6-2).
25
Kapitel 6
Der Scanner
Echo-Request
senden
Antwort
innerhalb
Zeitschranke ?
Nein
Host existiert
nicht
Ja
Host existiert
Abbildung 6-2: Host-Erkennung
Dies ist die gleiche Vorgehensweise, die das Programm Ping verwendet.
6.2 Die Applikations-Erkennung
Damit eine Kommunikation zwischen den Applikationen stattfinden kann, verwendet
die Applikation auf jedem System einen fest eingestellten TCP-Port (vgl. Kapitel
3.2.3). Dieser Port wird exklusiv von der Applikation benutzt. Beim Scan wird versucht auf diesem Port eine Verbindung einzurichten. Falls eine Verbindung erfolgreich
zustande kommt, so wird damit angezeigt, daß die Applikation auf einem entfernten
System vorhanden ist (vgl. Abbildung 6-3).
Verbindung
initieren
Kommt
Verbindung
zustande ?
Nein
Applikation
läuft nicht
Ja
Applikation
läuft
Abbildung 6-3: Applikations-Erkennung
26
Kapitel 6
Der Scanner
Wie bei der Host-Erkennung (vgl. Kapitel 6.1) verwendet auch die TCP-Implementation eine Zeitschranke für den Verbindungsaufbau. Kommt in dieser Zeit keine
Verbindung zustande, so wird der Versuch nach Ablauf der Zeit abgebrochen.
6.3 Zweistufiges Verfahren
Aus Performance-Gründen wird bei dem Erkennen der Applikation ein zweistufiges
Verfahren verwendet. Falls die Applikation auf einem entfernten Host vorhanden ist,
muß dieser Host natürlich konnektierbar sein. Deshalb lassen sich die Verfahren aus
Kapitel 6.1 und Kapitel 6.2 nacheinander ausführen (vgl. Abbildung 6-4).
Echo-Request
senden
Antwort
innerhalb
Zeitschranke ?
Nein
Host existiert
nicht
Nein
Applikation
läuft nicht
Ja
Host existiert
Verbindung
initieren
Kommt
Verbindung
zustande ?
Ja
Applikation
läuft
Abbildung 6-4: Zweistufiges Verfahren
Diese Vorgehensweise ist für eine Zeitoptimierung notwendig. Tritt der Fall ein, daß
eine TCP-Verbindung zu einem Host initiiert wird, der nicht existiert, so dauert es ca.
60 Sekunden, bis das Timeout greift. Für den Fall, daß der Host erreichbar ist, die
Applikation jedoch nicht läuft, so wird der TCP-Verbindungsversuch sofort abge27
Kapitel 6
Der Scanner
brochen, weil der entfernte Host die TCP-Verbindung direkt abweisen kann. Es muß in
diesem Fall nicht auf das Timeout gewartet werden. Es ist somit ratsam zuerst die Erreichbarkeit des jeweiligen Hosts sicherzustellen, da der Timeout-Wert für das ICMP
sehr klein ist und daher eine untergeordnete Rolle spielt.
6.4 Parallele Verarbeitung
Da der Scanner die meiste Zeit damit beschäftigt ist, auf einen Timeout zu warten,
wird die CPU des Systems dadurch kaum belastet. Diese Wartezeiten lassen sich sinnvoll nutzen, indem mehrere Hosts gleichzeitig überprüft werden (vgl. Abbildung 6-5).
Da die meisten Subnetze höchstens einige hundert Hosts beinhalten, lassen sich in der
Praxis sogar alle Hosts gleichzeitig überprüfen, ohne die CPU großartig zu belasten.
Zweistufiges
Verfahren
Host 1
Zweistufiges
Verfahren
Host 2
…
Zweistufiges
Verfahren
Host n
Ergebnis
Ergebnis
…
Ergebnis
Abbildung 6-5: Scanner
Ein zusätzlicher Vorteil besteht darin, daß die einzelnen Ergebnisse schneller
vorliegen. Der gesamte Scan hat folglich ungefähr die Dauer eines einzigen zweistufigen Verfahrens. Ohne parallele Ausführungspfade liegt die Zeit bei n Einzeldurchläufen bei der n-fachen Zeit.
28
Kapitel 7
Die Kommunikation mit anderen Rechnern
7 Die Kommunikation mit anderen Rechnern
Die implementierte Applikation muß mit anderen gleichen Applikationen auf entfernten Systemen kommunizieren können. Die Kommunikation zwischen den Rechnern gehorcht dabei einem bestimmten Ablauf. Ferner sind Regeln festgelegt worden,
in welcher Art und Weise die eigentlichen Informationen übermittelt werden.
7.1 Das Übertragungsprotokoll
Die Applikation verwendet ein eigenes Protokoll, welches zum Senden bzw.
Empfangen von Nachrichten benutzt wird. Dieses Protokoll verwendet die Netzwerkprotokolle TCP/IP, um die Nachrichten über das Netzwerk zu transportieren (vgl.
Abbildung 7-1)
Applikation
Applikation
Nachrichten
Nachrichten
Applikationsprotokoll
Applikationsprotokoll
TCP/IPSocket
TCP/IPSocket
Netzwerk
Abbildung 7-1: Kommunikationsweg
Eine Nachricht besteht aus zwei logischen Teilen, dem Protokollkopf und den Nutzdaten. Der Protokollkopf hat eine feste Länge von 24 Byte, die Länge des Nutzdatenfeldes ist variable (vgl. Abbildung 7-2).
Protokollkopf
0
Nutzdaten
24 Bytes
variable
Abbildung 7-2: Protokollkopf und Nutzdaten
Der Protokollkopf hat die Funktion, die Applikation (Applikationsname), die diese
Nachricht gesendet hat, eindeutig zu kennzeichnen. Dabei wird auch die Versionsnummer der Applikation und der Typ mitgesendet (vgl. Abbildung 7-3).
29
Kapitel 7
Die Kommunikation mit anderen Rechnern
Applikationsname
0
Typ
Versionsnummer
15
19
24 Bytes
Abbildung 7-3: Protokollkopf
Es sind zwei verschiedene Nachrichtentypen definiert. Der erste Typ hat die Aufgabe
die eigenen Systemdaten zu versenden. Die Systemdaten werden dazu in das Nutzdatenfeld eingetragen (vgl. Abbildung 7-4).
Protokollkopf
0
Systemdaten
24 Bytes
Variable
Abbildung 7-4: Paket-Typ 1
Die Systemdaten, die allesamt in Strings gespeichert sind, werden im Klartext
nacheinander in das Nutzdatenfeld geschrieben. Vor jedem String wird die Länge des
nachfolgenden Strings eingetragen (vgl. Abbildung 7-5).
Länge String 1
String 1
Länge String 2
String 2
…
Abbildung 7-5: Aufbau der Nutzdaten
Die Daten werden in der Reihenfolge Rechnername, IP-Adresse, Subnetzmaske, Netzwerknummer, Domain Name, MAC-Adresse, Betriebssystem, Prozessor-Hersteller,
Prozessor-Typ, Prozessor-Last, Prozessor-Geschwindigkeit, Anzahl Prozessoren,
Festplattenplatz, freier Festplattenplatz, physikalischer Speicher, freier physikalischer
Speicher, virtueller Speicher, freier virtueller Speicher und Bildschirmschoner im Feld
Systemdaten gespeichert.
Der zweite Typ wird bei der Performance-Messung eingesetzt. Dazu wird in das
Nutzdatenfeld eine zufällige Zeichenfolge eingetragen. Der Inhalt des Datenfeldes
wird beim Empfänger verworfen, wichtig ist die fest eingestellte Länge von 100
KByte für das Nutzdatenfeld (vgl. Abbildung 7-6).
Protokollkopf
0
zufällige Zeichenfolge
24 Bytes
100 KByte
Abbildung 7-6: Paket-Typ 2
30
Kapitel 7
Die Kommunikation mit anderen Rechnern
7.2 Der Kommunikationsablauf
Der erste Schritt zu einem Kommunikationaufbau ist die Bestimmung des Kommunikationspartners. Die Applikation muß als erstes in Erfahrung bringen, mit welchen
anderen Rechnern ein Nachrichtenaustausch möglich ist, bzw. auf welchen Rechnern
die Applikation läuft. Dazu wird das Netzwerk nach solchen Systemen gescannt (vgl.
Kapitel 6). Als nächstes werden die Übertragungs-Bandbreiten zu den anderen Systemen gemessen. Dazu wird an jeden erkannten Rechner mit laufender Applikation
eine Nachricht vom Typ 2 gesendet. Danach können die Systemdaten ausgetauscht
werden. Dazu wird periodisch an jedes System des Rechnerverbundes eine Nachricht
vom Typ 1 gesendet, worin die eigenen Systemdaten enthalten sind.
Netz
System B
System A
Scanner
System B
erkannt
twort
Scanneran
Typ 2
Typ 1
System A
erkannt
Typ 2
Typ 1
Typ 1
Zeit
Abbildung 7-7: Kommunikationsablauf
In dem Beispiel nach Abbildung 7-7 existieren die Systeme A und B, auf denen die
Applikation läuft. Sobald das System B die erste Nachricht von System A empfangen
hat, kann Rechner B daraus schließen, daß auf Rechner A ebenfalls die Applikation
vorhanden ist. Der Scanner wird dabei nicht als Applikations-Nachricht betrachtet, da
er auf TCP-Ebene beantwortet wird (Scannerantwort). Die Applikation erhält keine
Meldung, wenn sie von einem fremden Scanner erfaßt wird. Der Host B kann die
Existenz von Host A erst erkennen, wenn das Paket vom Typ 2 eintrifft. Das System B
kann System A direkt in seine Rechnerliste aufnehmen, ohne System A vorher mit
31
Kapitel 7
Die Kommunikation mit anderen Rechnern
dem Scanner erfaßt zu haben. Der Rechner A sendet ab jetzt periodisch Pakete vom
Typ 1, um seine Systemdaten mitzuteilen. Rechner B sendet zunächst ein Paket vom
Typ 2 zur Performance-Messung, danach ebenfalls periodisch Pakete vom Typ 1 mit
den eigenen Systemdaten.
32
Kapitel 8
Das Programm Systemdetector
8 Das Programm Systemdetector
Das Programm Systemdetector realisiert die gewünschten Funktionen aus Kapitel 5.
Sinn und Zweck des Programmes ist es, zunächst die eigenen Systemdaten festzustellen. Danach versucht das Programm gleiche Applikationen im Netzwerk zu finden
(vgl. Kapitel 6), um dann die Systemdaten mit ihnen auszutauschen. Da spezielle
Funktionen des MS Windows NT 4.0 Betriebssystems verwendet werden, ist das
Programm lediglich auf dieser Plattform einsetzbar.
8.1 Der Programmablauf
Der Programmablauf kann in zwei Abschnitte unterteilt werden. In der ersten Phase
stellt die Applikation die eigenen Systemdaten zusammen, in der zweiten Phase
werden diese Daten mit anderen Systemen ausgetauscht.
8.1.1 Der Programmstart
Bevor der normale Programmablauf gestartet werden kann, müssen diverse Vorarbeiten beim Programmstart geleistet werden. Dazu gehört im wesentlichen das
Initialisieren von verschiedenen Programmfunktionen, um einen sicheren Betrieb im
Netzwerk vorauszusetzen.
8.1.1.1 Überprüfungen
Aufgrund der Datenkonsistenz ist es zwingend notwendig, daß das Programm Systemdetector auf jedem System nicht mehrmals gleichzeitig ausgeführt werden darf.
Start
Läuft
Applikation
schon auf diesem Ja
System ?
Programmende
Nein
Existiert ein
Netzwerk?
Nein
Scanner
deaktivieren
Ja
Abbildung 8-1: Überprüfungen
33
Kapitel 8
Das Programm Systemdetector
Deshalb wird zunächst überprüft, ob eine gleiche Applikation bereits gestartet ist. Ist
dies der Fall, so wird das Programm sofort mit einer entsprechenden Meldung beendet.
Die zweite Überprüfung, die beim Programmstart stattfindet, ist die Bestimmung eines
Netzwerks. Ist kein Netzwerk vorhanden, weil es in dem System beispielsweise kein
Netzwerkinterface existiert, so läuft das Programm zwar weiter, der Betrieb ist aber
nur eingeschränkt möglich, da alle Funktionen zum Datenaustausch mit anderen Systemen deaktiviert sind. Falls ein Netzwerk existiert, so erfolgt ein regulärer Programmstart (vgl. Abbildung 8-1).
8.1.1.2 Programmeinstellungen laden und Timer starten
Der Benutzer verfügt über die Möglichkeit diverse Einstellung des Programms
manuell vorzunehmen. Dadurch kann die Ausführung der Applikation an das System
und die Netzwerkumgebung angepaßt werden. Diese Einstellungen werden in der
Konfigurationsdatei sd.ini gespeichert, die sich im MS Windows-NT-Verzeichnis
befindet. Fehlt diese Datei, oder Werte in dieser, werden Standardwerte für die
jeweiligen Optionen angenommen. Mit Hilfe dieser Einstellungen werden diverse
Timer, die das Programm benötigt, initialisiert und gestartet (vgl. Abbildung 8-2).
Existiert
die Datei
sd.ini ?
Ja
sd.ini
laden
Ja
Standardwerte
an den Fehlstellen eintragen
Nein
Gibt es
Fehlstellen ?
Nein
Timer
starten
Abbildung 8-2: Konfiguration laden
34
Kapitel 8
Das Programm Systemdetector
8.1.1.3 Bestimmung der eigenen Systemdaten
Nachdem die Konfiguration geladen worden ist, werden jetzt Informationen über das
eigene System eingeholt. Die Systemdaten lassen sich dabei in zwei Arten unterteilen,
statische und dynamische Daten. Bei den statischen Systemdaten wird angenommen,
daß sie sich während der Laufzeit des Programmes nicht verändern. Sie werden einmal
bestimmt und müssen danach nicht mehr aktualisiert werden. Zu diesen Datentypen
gehört z.B. der Prozessortyp. Die dynamischen Systemdaten können sich während der
Laufzeit des Programms ändern. Sie werden sofort bestimmt (vgl. Abbildung 8-3) und
im späteren Programmablauf periodisch aktualisiert.
Statische
Daten
bestimmen
Dynamische
Daten
bestimmen
Abbildung 8-3: Statische und dynamische Daten
Eine Aufstellung aller Systemdaten, die vom Programm Systemdetector erfaßt werden,
ist in Anhang A zu finden.
8.1.1.4 Ausgabedatei einlesen
Die vorhandenen Systeme im Netzwerk werden in einer Ausgabedatei gespeichert.
Beim Programmstart wird diese Datei automatisch geladen, falls sie noch von einem
früheren Programmablauf existiert. Unter der Voraussetzung, daß die Datei nicht
gelöscht wird, bleibt ein einmal erkanntes System auch nach unendlich vielen Neustarts der Applikation in der Ausgabedatei erhalten (vgl. Abbildung 8-4).
Existiert
eine
Ausgabedatei?
Ja
Ausgabedatei
laden
Nein
Abbildung 8-4: Ausgabedatei laden
35
Kapitel 8
Das Programm Systemdetector
8.1.1.5 Nebenläufige Threads starten
Neben dem Hauptprogramm werden drei zusätzliche Ausführungspfade (Threads)
gestartet (vgl. Kapitel Anhang B). Dadurch entsteht eine Multitasking-Applikation, bei
der insgesamt vier Threads gleichzeitig ausgeführt werden (vgl. Abbildung 8-5). Zwei
der Threads haben die Aufgabe die momentane CPU-Auslastung abzufragen und die
dynamischen Systemdaten periodisch zu aktualisieren. Der dritte Thread startet einen
Server, der für den Empfang eingehender Datenpakete durch das Netzwerk zuständig
ist (vgl. Kapitel 2).
CPU-Thread
starten
Thread für
dynamische
Daten starten
Server-Thread
starten
Haupt-Thread
Daten-Thread
Server-Thread
CPU-Thread
Abbildung 8-5: Threads starten
8.1.1.6 Scanner und Hauptdialog starten
Um gleiche Anwendungen auf anderen Systemen zu erkennen, wird der Scanner
benutzt (vgl. Kapitel 6). Da der Scanner intern mit paralleler Verarbeitung arbeitet,
bietet sich auch hier die Verwendung von mehreren Threads an (vgl. Abbildung 8-6).
Haupt-Thread
Scanner
starten
Hauptdialog
starten
…
Thread
Host 1
Thread
Host n
Haupt-Thread
Abbildung 8-6: Scanner und Hauptdialog starten
36
Kapitel 8
Das Programm Systemdetector
Um die Suchzeiten zu minimieren wird deshalb für jeden existierenden Host im
Netzwerk ein eigener Thread gestartet. Die Anzahl der parallelen Ausführungspfade
sind also abhängig von der Anzahl der möglichen Hosts im Netzwerk.
Als letzter Schritt während des Programmstarts wird der Hauptdialog, die visuelle
Benutzerschnittstelle gestartet.
8.1.2 Der Ablauf der Ausführungspfade
In diesem Unterkapitel sind die vier Ausführungspfade beschrieben, die beim Programmstart erzeugt werden.
8.1.2.1 Der Haupt-Thread
Die Hauptaufgabe dieses Ausführungspfades ist die Darstellung der Dialogfelder,
welche die Benutzungsschnittstelle darstellen. Zusätzlich wird der gesamte Versand
von System-Daten-Paketen hier abgewickelt. Funktionen, wie die Organisation der
Rechnerdaten, werden mit Hilfe von Timern (vgl. Kapitel 8.1.1.2) zeitgesteuert
abgewickelt (vgl. Abbildung 8-7).
Dialogfelder
aktualisieren
Gibt es ein
Timer-Ereignis ?
Ja
Ereignis
auswerten
Nein
Abbildung 8-7: Haupt-Thread
Hat ein Timer-Ereignis stattgefunden, so muß ausgewertet werden, welcher Timer
dieses Ereignis ausgelöst hat. Abhängig von der ID1 des auslösenden Timers werden
Anweisungen abgearbeitet. Das Programm verwendet drei verschiedene Timer, die in
unterschiedlichen Abständen ausgelöst werden (vgl. Abbildung 8-8).
1
ID – Identifier, gibt die Nummer des auslösenden Timers an
37
Kapitel 8
Das Programm Systemdetector
Gibt es ein
Timer-Ereignis ?
Ja
1
Ereignis ID
2
3
Nein
Systemdaten
senden
Scanner
starten
Dialogfelddaten
aktualisieren
Darstellung des
eigenen Systems
überprüfen
Rechnerfeld
überprüfen
Abbildung 8-8: Timer
8.1.2.2 Der CPU-Thread
Die CPU-Auslastung gehört zu den dynamischen Systemdaten. Die CPU wird
gesondert betrachtet, da die Prossorauslastung sich sprungartig in einem System von
einem Moment auf den anderen ändern kann. Das Abfrage-Intervall muß deshalb sehr
kurz sein, um eine sinnvolle Aussage über die momentane Auslastung zu machen. Aus
diesem Grund beträgt der Standard-Wert für dieses Intervall 1 Sekunde. Damit die
Intervall-Länge unabhängig variiert werden kann, wird ein eigener Thread gestartet, in
dem die CPU-Auslastung periodisch abgefragt wird (vgl. Abbildung 8-9).
CPU-Thread
Zähler
initialisieren
Zähler
abfragen
Warten
(Intervall-Länge)
Abbildung 8-9: CPU-Thread
38
Kapitel 8
Das Programm Systemdetector
Zur Abfrage der CPU-Auslastung wird auf eine spezielle Schnittstelle von MS Windows NT zurückgegriffen, indem auf Funktionen des internen Systemmonitors des
Betriebssystems zugegriffen wird. Diese Funktionen werden von der Programmbibliothek pdh.dll bereitgestellt. Für eine Systemdatenquelle, die auf diese Weise erfaßt
werden soll, muß ein Zähler bereitgestellt werden. Nach der Initialisierung des Zählers
kann er dann periodisch abgefragt werden. Der Zähler liefert bei jeder Abfrage einen
Mittelwert zurück, der aus den Werten zwischen den letzten beiden Abfragepunkten
berechnet worden ist.
8.1.2.3 Der System-Daten-Thread
Die anderen dynamischen Systemdaten besitzen gegenüber der CPU-Auslastung einen
Unterschied. Sie ändern sich nicht so sprunghaft und sind deshalb annähernd als stetig
zu betrachten. Der prinzipielle Ablauf dieses Threads ist der gleiche wie der des CPUThreads (vgl. Abbildung 8-10). Die Intervall-Länge ist im allgemeinen jedoch größer
und beträgt standardmäßig 10 Sekunden.
Daten-Thread
Dynamische
Systemdaten
abfragen
Warten
(Intervall-Länge)
Abbildung 8-10: Daten-Thread
Die dynamischen Systemdaten werden teilweise auch über die Programmbibliothek
pdh.dll abgefragt. Für diese Daten müssen ebenfalls Zähler zur Verfügung gestellt
werden (vgl. Kapitel 8.1.1.2). Es gibt jedoch auch Systeminformationen, die über eine
einfache Anweisung ermittelt werden können. Die lokale Rechnername kann z.B. mit
der Funktion gethostname() abgefragt werden.
8.1.2.4 Der Server-Thread
Der Server-Thread hat die Aufgabe die Systemdaten der anderen Systeme zu
empfangen. Dazu überwacht er den voreingestellten TCP-Port 9001. Zur Kommunikation wird ein Socket verwendet. Unter einem Socket wird ein Kommunikationsendpunkt verstanden, durch den eine MS Windows-Socket-Anwendung Datenpakete über
das Netzwerk sendet oder empfängt. Sockets können gleichzeitig in beide Richtungen
übertragen (Vollduplex). Ein Socket hat einen bestimmten Typ und kann außerdem
39
Kapitel 8
Das Programm Systemdetector
einen Namen besitzen. Es sind im wesentlichen zwei Socket-Typen definiert, Streamund Datagramm-Sockets. Stream-Sockets stellen einen Datenfluß ohne Satzgrenzen
her. Die Streams werden am Empfänger garantiert in der richtigen Reihenfolge abgeliefert, daß bedeutet in der Reihenfolge, in der sie vom Sender gesendet worden sind.
Datagramm-Sockets unterstützen einen satzorientierten Datenfluß, der nicht garantiert
abgeliefert wird. Deshalb ist es nicht sichergestellt, daß die Sendungen in der richtigen
Reihenfolge am Empfänger eintreffen. Der Empfang von Duplikaten (gleiche
Datenpakete) ist ebenfalls nicht ausgeschlossen.
Der Server-Thread benutzt einen Stream-Socket, um eine sichere Übertragung zu
garantieren. Die Übertragung zu einem entfernten System läuft verbindungsorientiert
ab. Es liegt deshalb nahe, daß für diese Verbindung das TCP verwendet wird (vgl.
Kapitel 3.2). Bei der Anwendung von Sockets ist es jedoch nicht notwendig sich um
die unteren Netzwerkschicht zu kümmern, auf die der Socket aufsetzt. Durch die Verwendung eines Sockets entsteht eine neue abstrakte universelle Programmierschnittstelle (vgl. Abbildung 8-11).
Anwendung
Funktionen
Socket
TCP
IP
Abbildung 8-11: Socket als neue Schnittstelle
Die Funktionen innerhalb einer Anwendung greifen über den Socket auf die unteren
Schichten des Netzwerkmodells zu. Das TCP und das IP erscheinen für die Anwendung transparent, wodurch eine einfachere und abstraktere Programmierung möglich
ist.
Sockets besitzen drei unterschiedliche Funktionsarten, den blockierenden, nicht
blockierenden und asynchronen Modus. Versucht ein blockierender Socket Daten über
das Netzwerk zu senden oder zu empfangen, so wird der Ausführungspfad solange
angehalten, bis diese Anweisung ein Ergebnis zurückliefert. Der Thread ist also für
diese Zeit blockiert. Ein nicht blockierender Socket fragt beim Senden bzw. beim Empfangen periodisch den Sende- bzw. den Empfangs-Puffer ab, was auch als Polling
40
Kapitel 8
Das Programm Systemdetector
bezeichnet wird. Der Ausführungspfad ist zwar für diese Funktionsart nicht blockiert,
es muß aber ein großer programmiertechnischer Aufwand betrieben werden, um einen
solchen Socket zu realisieren. Ein asynchroner Socket arbeitet nach dem NachrichtenPrinzip. Er überprüft ständig den Sende- und Empfangs-Puffer, wie der blockierende
Socket. Falls ein Ereignis stattfinden, so sendet er eine Nachricht an die Anwendung
(vgl. Abbildung 8-12).
Winsock
Funktionsaufruf
Blockierender Modus
Nicht blockierender Modus
Asynchroner Modus
Warten
Polling
Ausführung von
anderen Funktionen
Initialisieren...verarbeiten...abgeschlossen
Initialisieren...verarbeiten...abgeschlossen
Anwendung
Funktionsergebnis
Initialisieren...verarbeiten...abgeschlossen
Winsock
DLL
Abbildung 8-12: Socket-Modi
Ein asynchroner Socket kann für eine Anwendung Vorteile haben, denn die Applikation wird durch den Netzwerkverkehr im Gegensatz zu den anderen Modi kaum belastet. Ein asynchroner Socket läßt sich jedoch nur realisieren, wenn für den Socket ein
zusätzlicher Thread gestartet wird. Dieser Ausführungspfad wird im Programm
Systemdetector als Server-Thread bezeichnet. Der Thread muß programmiertechnisch
nicht explizit gestartet werden. Durch die Konstruktion eines asynchronen Sockets
wird der Pfad automatisch gestartet und der Netzwerkverkehr überprüft (vgl.
Abbildung 8-13).
Haupt-Thread
Asynchronen
Socket
erstellen
Server-Thread
Netzwerkverkehr
überprüfen
Haupt-Thread
Nachricht
Nachricht
Nachricht
Abbildung 8-13: Server-Thread
41
Kapitel 8
Das Programm Systemdetector
Nach dem Start des Server-Threads kommuniziert er mit dem Haupt-Thread über
Nachrichten. Da diese Kommunikation nur im Bedarfsfall stattfindet sind die Warteund Ausführungszeiten für die Applikation minimal. Die Nachrichten, die der HauptThread an den Server-Thread sendet sind Funktionsaufrufe oder Befehle, die auf einen
Socket angewandt werden können. Dadurch wird die Kommunikation mit anderen
Systemen gesteuert. Die wichtigsten Socket-Befehle sind in Tabelle 8-1 dargestellt.
Befehl
Accept
Close
Connect
Beschreibung
Akzeptiert eine Verbindungs-Anfrage von einem anderen System
Schließt eine bestehende Verbindung
Stellt eine Verbindungs-Anfrage zu einem anderen System. Der
Socket verhält sich wie ein Client
GetPeerName Gibt den Namen des Verbindungspartners und den Port der bestehenden Verbindung an
Schaltet den Socket in den Hören-Modus. Der Socket arbeitet
Listen
daraufhin als Server
Receive
Empfängt Daten auf einem Socket
Send
Sendet Daten über einen Socket
Tabelle 8-1: Socket-Befehle
Falls ein Ereignis auf einem Socket stattfindet, so wird diese mit einer Nachricht an
den Haupt-Thread gemeldet. Die wichtigsten Socket-Ereignisse sind in Tabelle 8-2
dargestellt.
Ereignis
OnAccept
Beschreibung
Es wird signalisiert, daß auf einem Socket, der als Server arbeitet, eine
Verbindungsanforderung eingegangen ist
OnClose
Diese Nachricht signalisiert, daß der andere Verbindungspartner die
Verbindung geschlossen hat
OnConnect Es wird signalisiert, daß eine Verbindung erfolgreich zustande gekommen ist
OnReceive Diese Nachricht zeigt an, daß Daten empfangen worden sind und im
Empfangspuffer abholbereit vorliegen
OnSend
Zeigt an, daß sich Daten im Sendepuffer befinden und der Socket bereit
ist, über die bestehende Verbindung zu senden
Tabelle 8-2: Socket-Ereignisse
42
Kapitel 8
Das Programm Systemdetector
8.2 Die Dialogfelder
Die Dialogfelder bilden die Benutzungsschnittstelle. Ihre Aufgabe ist es die
Programmdaten visuell darzustellen. Der Benutzer kann über die Dialogfelder auch
Daten eingeben oder über Schaltflächen Anweisungen an das Programm geben. Die
Applikation besitzt drei Dialogfelder (vgl. Abbildung 8-14).
Start
Haupt-Dialog
Details-Dialog
Programmende
OptionenDialog
Abbildung 8-14: Dialogfelder
8.2.1 Der Hauptdialog
Der Hauptdialog ist das erste sichtbare Dialogfeld nach einem Programmstart (vgl.
Abbildung 8-15).
Abbildung 8-15: Hauptdialog
43
Kapitel 8
Das Programm Systemdetector
Dies ist das zentrale Fenster, in dem die wichtigsten Programmdaten dargestellt
werden. Die anderen Dialogfelder sind von hier aus erreichbar.
In dem Listenfeld wird die aktuelle Liste des Rechnerverbundes angezeigt. Zusätzlich
sind alle Rechner aufgeführt, die überhaupt in diesem Netzwerk konnektierbar sind. In
der ersten Spalte ist die IP-Adresse des jeweiligen Rechners eingetragen. In der
zweiten Spalte steht der vollständige Hostname, falls für die IP-Adresse ein Hostname
im DNS-Server (vgl. Kapitel 4.3) eingetragen ist.
Bei den Rechnern, auf denen die Applikation vorhanden ist, wird nur der Hostname
ohne die Domäne eingetragen. In der letzten Spalte wird der Name des angemeldeten
Benutzers auf dem jeweiligen Rechner eingetragen, falls die Applikation läuft. Das
dargestellte Symbol in der ersten Spalte gibt den Status des Rechners an (vgl. Tabelle
8-3).
Symbol
Bedeutung
Applikation läuft, Auslastung < 33%
grün
Applikation läuft, Auslastung 33% - 66%
gelb
Applikation läuft, Auslastung > 66%
rot
grün
Applikation läuft, Bildschirmschoner aktiv,
Auslastung < 33%
gelb
Applikation läuft, Bildschirmschoner aktiv,
Auslastung 33% - 66%
rot
Applikation läuft, Bildschirmschoner aktiv,
Auslastung > 66%
Applikation läuft nicht
grau
durchgestrichen
unbestimmt
Rechner nicht mehr erreichbar
Status noch nicht bestimmt
Tabelle 8-3: Symbole der Rechnerliste
Durch das Klicken mit der linken Maustaste auf die Spaltenköpfe wird die Liste nach
dieser Spalte aufwärts sortiert. Neue Rechner werden daraufhin automatisch an die
richtige Stelle in der Liste eingefügt. Standardmäßig ist die Sortierung nach der IPAdresse eingestellt.
44
Kapitel 8
Das Programm Systemdetector
Das Dialogfeld besitzt zwei Schaltflächen auf denen das graue Rechnersymbol und das
durchgestrichene Rechnersymbol abgebildet sind. Die Darstellung dieser Rechnertypen in der Rechnerliste läßt sich mit diesen Schaltflächen ein- bzw. ausschalten.
Die Schaltfläche Einstellungen blendet den Optionen-Dialog ein (vgl. Abbildung
8-15).
Die Schaltfläche Details öffnet das Details-Dialogfeld, in dem die gesamten Systemdaten des Rechners angezeigt werden, der im Listenfeld ausgewählt ist (vgl.
Abbildung 8-15). Falls kein Rechner markiert ist, wird kein Details-Fenster geöffnet.
Eine mehrfache Auswahl im Listenfeld ist nicht möglich. Zur Anzeige der Daten wird
der Details-Dialog als modales Fenster erzeugt. Anstatt auf die Schaltfläche zu
klicken, bietet ein Doppelklick auf den jeweiligen Rechner die gleiche Funktion.
Der Haupt-Dialog besitzt einen Fortschritts-Balken, der die momentane ProzessorAuslastung anzeigt. Die Anzeige wird periodisch aktualisiert. Der Intervall-Wert kann
vom Benutzer eingestellt werden (vgl. Kapitel 8.2.3).
Die Schaltfläche Beenden verläßt das Programm. Wird diese Schaltfläche betätigt, so
erscheint ein neues Fenster, in dem man den Vorgang bestätigt werden muß. Beim
Beenden des Programms werden alle Threads beendet, die Ausgabedatei wird
geschlossen und temporäre Dateien werden gelöscht.
8.2.2 Der Details-Dialog
Der Details-Dialog dient zur Darstellung des kompletten Datensatzes eines Rechners.
Dazu besitzt das Dialogfeld 22 Felder, in denen Werte eingetragen sind (vgl.
Abbildung 8-16).
Es befinden sich hier statische und dynamische Daten (vgl. Anhang A), die vom
jeweiligen Rechner selber bestimmt worden sind. Die Felder Verbindungsbandbreite
und Letztes Lebenszeichen bilden eine Ausnahme. Diese Daten werden immer vom
lokalen System bestimmt.
Die Verbindungsbandbreite gibt den Datendurchsatz auf Applikationsebene an, der
über das Netzwerk erreicht werden kann. Dieser Wert ist ein Maß für die Geschwindigkeit des Netzwerks und der beteiligten Rechnersysteme, welcher nur bestimmt
werden kann, wenn auf dem System die Applikation läuft. In dem Feld Letztes
Lebenszeichen wird der Zeitpunkt eingetragen, an dem das letzte Mal ein Ping (vgl.
Kapitel 6.1) erfolgreich war, oder ein Systemdatenpaket eingetroffen ist.
Die Schaltfläche Schließen beendet diesen Dialog und der Benutzer kehrt dadurch zum
Haupt-Dialog zurück.
45
Kapitel 8
Das Programm Systemdetector
Abbildung 8-16: Details-Dialog
8.2.3 Der Optionen-Dialog
Diese Dialogfeld dient zur Einstellung der Programmparameter (vgl. Kapitel 8.4).
Diese Programmparameter werden in der Konfigurationsdatei sd.ini im MS WindowsVerzeichnis gespeichert und zu Programmbeginn geladen (vgl. Kapitel 8.1.1.2). Die
Parameterwerte sind in Eingabefeldern dargestellt, die vom Benutzer verändert werden
können (vgl. Abbildung 8-17).
Zusätzlich zu den Parameter-Feldern sind in diesem Dialogfeld vier Schaltflächen
angeordnet. Durch die Betätigung der Schaltfläche Scanner starten, wird der Scanner
manuell gestartet. Falls der Scanner noch laufen sollte, ist die Schaltfläche deaktiviert
dargestellt und läßt sich somit nicht betätigen.
Die Schaltfläche History löschen löscht die komplette Rechner-Liste im Speicher,
danach wird die Ausgabedatei gelöscht. Diese Funktion wird benötigt, um eine
Rechner-Liste neu zu initialisieren. Damit die Funktion nicht versehentlich ausgeführt
wird, folgt auf den Klick auf die Schaltfläche eine Sicherheitsabfrage, die bestätigt
werden muß.
46
Kapitel 8
Das Programm Systemdetector
Abbildung 8-17: Optionen-Dialog
Die Schaltfläche Abbrechen schließt das Dialogfeld und verwirft alle Änderungen,
OK übernimmt alle geänderten Parameter aus den Eingabefeldern und schließt den
Dialog.
8.2.4 Der About-Dialog
Dieser Dialog informiert den Benutzer des Programmes über die Version und den
Autor des Programmes und die geltenden Copyright-Bestimmungen (vgl. Abbildung
8-18).
Abbildung 8-18: About-Dialog
47
Kapitel 8
Das Programm Systemdetector
8.3 Die Ausgabedatei
In der Ausgabedatei werden sämtliche Daten, die in der Rechner-Liste erfaßt sind,
gespeichert. Damit die Daten in der Datei möglichst den gleichen Stand besitzen, wie
die Daten im Hauptspeicher, wird die Ausgabedatei jedes mal aktualisiert, wenn sich
ein Wert in der Rechner-Liste ändert oder wenn ein Rechner neu hinzugefügt wird.
Um die Ausgabedatei später mit dem Programm MS Excel auswerten zu können, wird
das Dateiformat CSV verwendet. Beim CSV-Format handelt es sich um das einfachste
Format um Tabellen zu speichern. Dabei werden Spalten durch ein Semikolon getrennt. Für eine neue Zeile wird ein CR-Zeichen eingefügt (vgl. Abbildung 8-19).
Abbildung 8-19: CSV-Datei betrachtet im Editor
Diese Datei kann mit MS Excel ausgewertet werden (vgl. Abbildung 8-20):
Abbildung 8-20: CSV-Datei betrachtet in MS Excel
48
Kapitel 8
Das Programm Systemdetector
In der Ausgabedatei werden alle statischen und dynamischen Daten jedes bekannten
Rechners abgespeichert. Die Reihenfolge und die Bedeutung der Daten kann Tabelle
A-1 entnommen werden.
8.4 Die Konfigurationsdatei
Die Programmparameter die beim Start der Applikation geladen werden befinden sich
in der Konfigurationsdatei sd.ini im MS Windows-Verzeichnis. Bei diesem Dateityp
werden die einzelnen Einstellungen in Gruppen zusammengefaßt. Die Datei sd.ini
besitzt die beiden Gruppen Intervalle und Ausgabedatei (vgl. Abbildung 8-21), die
Reihenfolge der Parameter kann dabei beliebig sein.
Abbildung 8-21: Ansicht von sd.ini im Editor
Für jeden Eintrag in der Konfigurationsdatei existiert ein Eingabefeld im OptionenDialog. Die Parameternamen in der Datei werden zu den Feldern im Dialogfeld (vgl.
Abbildung 8-17) nach Tabelle 8-4 zugeordnet.
Gruppe in sd.ini
Intervalle
Intervalle
Intervalle
Intervalle
Intervalle
Intervalle
Intervalle
Intervalle
Ausgabedatei
Name in sd.ini
Lebenszeichen
Datenaustausch
Scanner
CPU
Info
Feldanzeige
Benchmark
Ping
Name
Bezeichnung im Dialogfeld
Host nicht erreichbar
Datenaustausch-Intervall
Scanner-Intervall
CPU-Monitor-Intervall
Systemdaten-Intervall
Feldanzeige-Intervall
Benchmark-Intervall
Ping-Timeout
Name der Ausgabedatei
Tabelle 8-4: Parameternamen
49
Kapitel 8
Das Programm Systemdetector
Für jeden Programmparameter, der im Optionen-Dialog eingestellt werden kann, ist
ein Wertebereich und einen Standardwert definiert (vgl. Tabelle 8-5). Der Wertebereich begrenzt die Einstellmöglichkeiten des Parameters, um die Anwendung vor
nicht sinnvollen Einstellungen, wie z.B. ein negativer Intervallwert, zu schützen. Die
Standardwerte werden eingesetzt, falls zu Programmbeginn ein oder mehrere Werte
nicht aus der Konfigurationsdatei geladen werden können.
Parameter
Host nicht erreichbar
Standard
-Wert
10 min
DatenaustauschIntervall
Scanner-Intervall
10 s
CPU-Monitor
Intervall
3s
5 min
Systemdaten-Intervall 60 s
Feldanzeige-Intervall
10 s
Benchmark-Intervall
60 min
Ping-Timeout
Name der
Ausgabedatei
500 ms
Cluster.csv
WerteBedeutung
Bereich
10-1000 min Ist das letzte Lebenszeichen älter
als diese Zeitschranke, gilt der
Host als nicht erreichbar
1-100 s
Abstand zwischen den Sendungen der eigenen Systemdaten
1–1000 min Abstand zwischen den Starts des
Scanners
1-1000 s
Länge der Warteschleife zwischen der Abfrage der momentanen CPU-Last
1-1000 s
Länge der Warteschleife zwischen der Abfrage der dynamischen Systemdaten
Zeitgrenze, nach der die Anzeige
1-100 s
der Rechnerliste spätestens aktualisiert wird
1-1000 min Abstand der BenchmarkMessungen
10-5000 ms Ping-Timeout
Name der CSV-Datei
Tabelle 8-5: Parameter-Einstellungen
8.5 Die Objekte der Applikation
Die Applikation Systemdetector ist mit dem MS Visual Studio Compiler implementiert
worden.
Die in der Klassenansicht dargestellten Klassen (vgl. Abbildung 8-22) zeigen lediglich
die neu entwickelten Klassen. Diese werden im allgemeinen von übergeordneten
50
Kapitel 8
Das Programm Systemdetector
Klassen der MFC1 abgeleitet und mit neuen Methoden ergänzt. Die verwendeten
Klassen der MFC sind dabei nicht mit abgebildet.
Abbildung 8-22: Klassenansicht Systemdetector
8.5.1 Die Strukturen der Applikation
8.5.1.1 _host_liste
Diese Datenstruktur wird verwendet, um die Daten aller Rechner im Netzwerk festzuhalten. Da jeder theoretisch mögliche Rechner im Netzwerk qualifiziert werden muß,
wird für jeden Host eine solche Datenstruktur angelegt (vgl. Abbildung 8-23).
Abbildung 8-23: Struktur _host_liste
Die Variable applikation gibt an, ob auf dem Rechner das Programm Systemdetector
läuft.
Ping zeigt an, ob der jeweilige Rechner über ein Ping konnektierbar ist. Falls die
Applikation auf einem Rechner läuft, so ist er natürlich auch über ein Ping erreichbar.
Die Variable benchmarked gibt an, ob für den jeweiligen Host schon eine Messung der
Verbindungs-Bandbreite durchgeführt worden ist und in ip ist die IP-Adresse des
Rechners eingetragen.
1
MFC – Microsoft Foundation Class
51
Kapitel 8
Das Programm Systemdetector
8.5.1.2 _rechner
In dieser Datenstruktur werden die statischen und dynamischen Systemdaten, die
Verbindungsbandbreite und das letzte Lebenszeichen erfaßt (vgl. Abbildung 8-24).
Diese Struktur wird für jeden erreichbaren Rechner im Netzwerk benutzt, unabhängig
davon, ob er zum Rechnerverbund gehört, oder nicht.
Abbildung 8-24: Struktur _rechner
8.5.2 Die Klassenbeschreibung
8.5.2.1 CAboutDlg
Diese Klasse hat die Funktion das About-Dialogfeld darzustellen (vgl. Kapitel 8.2.4).
Der Anwender erfährt durch das Dialogfeld Informationen über das Programm. Die
Klasse CAboutDialog wird von der MFC-Klasse CDialog abgeleitet und wird automatisch bei der Euzeugung eines neuen Projektes vom Compiler erstellt. CDialog ist
eine Standardklasse zur Darstellung von Dialogfeldern.
52
Kapitel 8
Das Programm Systemdetector
8.5.2.2 CDetailsDialog
Zur Darstellung des Details-Dialogs (vgl. Kapitel 8.2.2) wird diese Klasse verwendet,
die ebenfalls von der MFC-Klasse CDialog abgeleitet wird. Diese Klasse hat keine
eigenen Funktionen, außer der Möglichkeit, Daten von einer aufrufenden Klasse zu
empfangen. Falls das Details-Dialogfeld im Programmablauf aufgerufen wird, so
müssen die Daten, die im Dialogfeld eingetragen werden sollen, vorher übergeben
worden sein. Diese Funktion wird beim Erstellen der Klasse automatisch vom
Klassenassistent von MS Visual Studio eingefügt. Es muß lediglich angegeben
werden, welche Daten vom bzw. zum Dialogfeld ausgetauscht werden.
8.5.2.3 CDynamicDataThread
Diese Klasse implementiert den System-Daten-Thread (vgl. 8.1.2.3). Sie ist abgeleitet
von der MFC-Klasse CWinThread, welche eine Standardklasse für nebenläufige Ausführungspfade darstellt. CDynamicDataThread besitzt eine Funktion, in der zyklisch
die dynamischen Daten des lokalen Rechners erfaßt werden.
8.5.2.4 COptionsDialog
Diese Klasse hat die Funktion den Optionen-Dialog darzustellen (vgl. Kapitel 8.2.3).
Sie ist, wie die anderen Dialogfeldklassen auch, von der MFC-Klasse CDialog abgeleitet. COptionsDialog besitzt die Funktion OnHistory, um sämtliche Rechnerdaten
und die Ausgabedatei zu löschen. Diese Funktion wird verwendet, um die Rechnerliste
neu zu initialisieren. Die Klasse besitzt die Funktion OnScannerButton, um den
Scanner manuell zu starten. Außerdem werden Funktionen bereitgestellt, welche die
Änderung der Programmeinstellungen ermöglichen.
8.5.2.5 CScannerThread
CScannerThread ist von der MFC-Klasse CWinThread abgeleitet und implementiert
die Ausführungspfade des Scanners (vgl. Kapitel 6). Für jede IP-Adresse im lokalen
Netzwerk wird ein Thread vom Typ CScannerThread gestartet. Dieser Pfad soll für
eine IP-Adresse herausfinden, ob der Host konnektierbar ist, bzw. ob die Applikation
auf dem jeweiligen Host läuft. Danach wird der Thread wieder beendet.
8.5.2.6 CServerSocket
Diese Klasse ist von der MFC-Klasse CAsyncSocket abgeleitet und implementiert
einen asynchronen Socket (vgl. Kapitel 8.1.2.4). Die Funktionen der Klasse dienen nur
der Überwachung des Sockets. Hier können Socket-Fehlermeldungen abgefangen und
behandelt werden ohne sie an den Hauptdialog zu melden. Bei der Erzeugung einer
Variable vom Typ CServerSocket wird automatisch ein neuer Thread gestartet. Diese
Funktion ist bereits in der Klasse CAsyncSocket implementiert.
53
Kapitel 8
Das Programm Systemdetector
8.5.2.7 CSysInfoThread
Diese Klasse bildet den Ausführungspfad der als CPU-Thread bezeichnet wird (vgl.
Kapitel 8.1.2.2). Wie die anderen Thread-Klassen ist auch diese von der MFC-Klasse
CWinThread abgeleitet. Die Hauptfunktion dieses Threads ist die periodische Abfrage
der CPU-Auslastung, des Bildschirmschoner- und des Scanner-Status.
8.5.2.8 CSystemdetectorApp
Diese Klasse wird vom Compiler bei der Erzeugung eines neuen Projekts automatisch
erstellt. Sie ist nur für den Start der Applikation verantwortlich und besitzt keine
programmrelevanten Funktionen.
8.5.2.9 CSystemdetectorDlg
CSystemdetector stellt die wichtigste Klasse der Applikation dar. In ihr ist die Darstellung des Hauptdialogfeldes implementiert. Die Klasse besitzt die Funktionen, um alle
statischen und dynamischen Daten des eigenen Systems zu bestimmen. Die gesammelten Daten aller Rechner werden hier gesammelt. Die Kommunikation mit anderen
Rechnern wird ebenfalls von ihr gesteuert. Darüber hinaus sind die Funktionen für die
Erstellung der Ausgabedatei in dieser Klasse vorhanden. Die Klasse CSystemdetector
implementiert die meisten Funktionen des Haupt-Threads und stellt das zentrale
Steuerorgan der Applikation dar.
54
Kapitel 9
Tests
9 Tests
Um die einwandfreie Funktionalität des Programmes Systemdetector zu testen, sind
mehrere Tests durchgeführt worden (vgl. Kapitel 5.9).
9.1 Applikationsstabilität prüfen
Bei diesem Test ist das Verhalten des Programmes in Bezug auf die eigenen
Systemressourcen und vor allen Dingen die Stabilität getestet worden. Dazu ist das
Programm auf nur einem einzigen Rechner gestartet worden, der sich in einem
Netzwerk befindet.
Das Verhalten des Programms wird getestet, ohne das eine Kommunikation mit
anderen Systemen stattfindet. Der Test zeigt, daß die Applikation über einen längeren
Zeitraum stabil läuft. Es ist eine Testdauer von 3 Tagen, unter Verwendung des
Testsystems Thriller (vgl. Anhang C), angesetzt worden. Während dieses Zeitraums
sind mehrere Systemdaten mit dem Systemmonitor von Windows NT mitprotokolliert
worden (vgl. Abbildung 9-1).
Abbildung 9-1: Screenshot Systemmonitor
55
Kapitel 9
Tests
Aus dem Verlauf dieser Werte, kann ein Rückschluß auf die Stabilität und das Systemverhalten der Applikation gezogen werden. Der Systemmonitor erfaßt für den Prozeß
Systemdetector fünf verschiedene Systemdaten. Die Bedeutung dieser Daten kann
Tabelle 9-1 entnommen werden.
Protokollierter Wert Beschreibung
Thread-Anzahl
Anzahl der parallelen Ausführungspfade
Virtuelle Größe
Dies ist die aktuelle Größe des virtuellen Adressraums, den
dieser Prozeß belegt.
Private Seiten
Dies ist die aktuelle Anzahl an Speicherseiten, die der Prozeß
reserviert hat und die nicht mit anderen Prozessen geteilt
werden kann.
% Prozessorzeit
Dieser Wert ist der Prozentanteil der vergangenen Zeit,
während der alle Threads dieses Prozesses den Prozessor
verwendet haben, um Instruktionen auszuführen.
Tabelle 9-1: Protokollierte Prozeßdaten
Aus den Daten virtuelle Größe (oberste Kurve) und private Seiten (2. Kurve von oben)
können Rückschlüsse auf das Speicherverhalten des Prozesses gezogen werden. Da
diese Daten über den gesamten Testverlauf einen konstanten Wert aufweisen (vgl.
Abbildung 9-1), kann die Applikation als "stabil", bezogen auf den Speicherbedarf,
betrachtet werden. Ein Prozeß, der während der Laufzeit zunehmend Speicher für sich
beansprucht, gilt als "instabil", da das Betriebssystem nur einen endlichen Wert an
Speicherseiten bereitstellen kann. Eine Applikation, die so viel Speicher für sich
beansprucht, daß der maximale Wert für das jeweilige System überschritten wird,
erzwingt damit mindestens einen Absturz der Applikation, oder sogar einen Absturz
des Betriebsystems.
Durch den Wert Thread-Anzahl (unterste Kurve) läßt sich beobachten, ob die
dynamisch erzeugten Threads, die mit dem Scanner gestartet werden (vgl. Kapitel 6),
wieder beendet werden. Da dieser Wert einen konstanten Verlauf über den gesamten
Testlauf aufweist, werden offensichtlich die Threads immer ordnungsgemäß beendet.
Durch den Wert Prozessorzeit (2. Kurve von unten, leicht schwankend) kann die
Belastung der lokalen CPU durch diesen Prozeß beobachtet werden. Wie sich erkennen läßt, benötigt die Applikation Systemdetector sehr wenig Prozessorzeit. Die
Belastung liegt auf dem verwendeten Testsystem durchschnittlich bei unter 5%. Es ist
jedoch zu beobachten, daß zu Anfang und am Ende des Testlauf die Prozessorlast
ansteigt. Der Grund dafür liegt im jeweiligen Zustand des Netzwerks. Am Anfang
bzw. am Ende des Tests waren im gleichen Netzwerk zusätzliche andere Rechner
konnektierbar. Diese Rechner werden von der Applikation Systemdetector durch den
56
Kapitel 9
Tests
Scanner erfaßt und im Dialogfeld dargestellt. Dadurch wird der lokale Prozessor zusätzlich minimal belastet, wodurch sich der kleine Anstieg der Prozessorzeit erklären
läßt.
Nach Ablauf des Test sind die Funktionen und die Darstellung der Dialogfelder überprüft worden (vgl. Abbildung 9-2).
Abbildung 9-2: Screenshot Systemdetector
Die vier Dialogfelder, alle Schaltflächen und die Bestimmung der eigenen Systemdaten funktionierten nach Ablauf des Testzeitraums einwandfrei. Die konnektierbaren
Rechner sind fehlerfrei erfaßt und in das Listenfeld im Hauptdialog eingetragen
worden.
Aus diesen Ergebnissen läßt sich schlußfolgern, daß nach Ablauf des dreitägigen Test
die Applikation ohne funktionelle Einschränkung arbeitet.
9.2 Erkennen aller Rechner im Netzwerk
In diesem Test ist der Schwerpunkt auf die Scanner-Funktion (vgl. Kapitel 6) gelegt
worden, d.h. auf die Netzwerkfunktionen. Beim Start der Applikation Systemdetector
muß der Scanner alle anderen Rechner im Netzwerk, die konnektierbar sind, erkennen
57
Kapitel 9
Tests
und im Dialogfeld dementsprechend anzeigen (vgl. Kapitel 8.2.1). Um alle Hosts zu
bestimmen, die tatsächlich im Netzwerk erreichbar sind, wird das Referenzprogramm
WS_PingProPack von der Firma IP-Switch verwendet. Dieses Programm bestimmt
alle konnektierbaren Hosts und gibt den Namen für die jeweilige IP-Adresse an, die im
DNS-Server gespeichert ist (vgl. Abbildung 9-3).
Abbildung 9-3: Screenshot WS_PingProPack
Das Listenfeld im Hauptdialog des Programms Systemdetector kann nicht alle Hosts
gleichzeitig darstellen. Deshalb wird zur Auswertung die Ausgabedatei in MS Excel
verglichen (vgl. Abbildung 9-4). Die Daten in der Ausgabedatei laufen zu den Daten
des Dialogfeldes immer synchron.
Die beiden Rechnerlisten stimmen überein. Daraus kann gefolgert werden, das der
Scanner, sowie Namensauflösung der IP-Adressen einwandfrei funktionieren. Aus der
Tatsache, daß MS Excel die Ausgabedatei fehlerfrei auswerten konnte, ist zusätzlich
die Ausgabedatei auf Korrektheit geprüft worden.
58
Kapitel 9
Tests
Abbildung 9-4: Screenshot MS Excel
9.3 Zusammenschluß mehrerer Rechner
Bei diesem Test befanden sich insgesamt drei Rechner im Netzwerk, auf denen die
Applikation im Abstand von wenigen Sekunden gestartet worden ist. Das Programm
muß auf jedem dieser Rechner in der Lage sein, die anderen Rechner mit dem Scanner
zu finden und daraufhin die Systemdaten mit ihnen auszutauschen. Außerdem müssen
die Verbindungsbandbreiten zwischen den Rechnern bestimmt werden. Dazu sind die
Testsysteme Thriller, Thing und Theory verwendet worden, auf denen ca. 3 Tage die
Applikation lief. Wie beim Test in Kapitel 9.1 ist zur Stabilitätsüberprüfung ebenfalls
der Systemmonitor von Windows NT herangezogen worden, der einige Systemdaten
mitprotokolliert (vgl. Abbildung 9-5).
59
Kapitel 9
Tests
Abbildung 9-5: Screenshot Thriller
Das Verhalten der Applikation ist exemplarisch auf dem Testsystem Thriller genauer
ausgewertet worden. Auf den anderen beiden Testsystemen zeigte die Applikation das
gleiche Verhalten, da die protokollierten Daten im Systemmonitor qualitativ auf allen
drei Systemen den gleichen Verlauf hatten.
Die Daten Virtuelle Größe (oberste Kurve) und Private Seiten (2. Kurve von oben)
zeigen einen konstanten Verlauf (vgl. Abbildung 9-5). Dem Programm kann ein
stabiles Speichermanagement bescheinigt werden, da mit der Laufzeit kein zusätzlicher Speicher verwendet wird.
Die Thread-Anzahl (unterste Kurve) bleibt ebenfalls konstant im gesamten Testverlauf
(vgl. Abbildung 9-5). Daran läßt sich erkennen, daß die gestarteten Ausführungspfade
des Scanners (vgl. Kapitel 6) auch wieder beendet werden.
Der Verlauf der Prozessorzeit (2. Kurve von unten) zeigt einen schwankenden Verlauf
(vgl. Abbildung 9-5). Tagsüber liegt eine Erhöhung der Prozessorlast vor. Der Grund
besteht darin, daß während dieser Zeit mehr Rechner im lokalen Netzwerk konnektierbar sind (vgl. Kapitel 9.1).
Nach Ablauf des Testzeitraums ist auf allen drei Systemen die Funktionen der Dialogfelder, die Datenausgabe im Dialogfeld (vgl. Abbildung 9-6) und die Erstellung der
Ausgabedatei auf Korrektheit überprüft worden.
60
Kapitel 9
Tests
Abbildung 9-6: Screenshot Thriller
Aus den Testergebnissen läßt sich schlußfolgern, daß die Applikation nach dem
dreitätigen Test auf allen Systemen einwandfrei funktioniert.
9.4 Ordentliches Beenden des Programmes
In einem Netzwerk befinden sich für diesen Test zunächst fünf Rechner auf denen die
Applikation läuft. Alle Rechner tauschen untereinander erfolgreich periodisch die
Systemdaten aus. In der Rechnerliste werden die beteiligten Rechner mit farbigen
Symbolen gekennzeichnet (vgl. Tabelle 8-3). Am Test sind dazu die Systeme Theory,
Thing, Theorem, Theme und Thread beteiligt (vgl. Abbildung 9-7).
Auf dem Rechner Thing wird nun die Applikation beendet. Die Applikationen der
anderen Rechner müssen dies erkennen und Thing nur noch als konnektierbar
einstufen. Er muß in der Rechnerliste als grauer Rechner dargestellt werden und nicht
mehr mit farbigem Symbol.
Außerdem wird der Rechner-Name von Thing mit vollem Domain-Namen angegeben
und der Benutzername gelöscht (vgl. Abbildung 9-8).
61
Kapitel 9
Tests
Abbildung 9-7: Screenshot Theorem
Abbildung 9-8: Screenshot Theorem
62
Kapitel 9
Tests
Da die Systemdaten von Thing nicht mehr bestimmt werden können, müssen die alten
Daten aus der Rechnerliste gelöscht werden. Lediglich die Adresse, der Hostname und
das letze Lebenszeichen werden gespeichert (vgl. Abbildung 9-9).
Abbildung 9-9: Screenshot Details-Dialog
9.5 Programmabsturz simulieren
Ausgehend von einem bestehenden Rechnerverbund wird der Fall des Programmabsturzes simuliert. Dazu wird auf einem Rechner die laufende Applikation mittels des
Task-Managers von Windows NT „gewaltsam“ beendet. Die Applikationen auf den
anderen Rechnern erkennen jetzt, daß die abgestürzte Applikation nicht mehr erreichbar ist. Dies bedeutet, daß der betroffene Rechner aus dem Rechnerverbund gelöscht
werden muß. Der Programmabsturz darf auf anderen Rechnern keine Fehlfunktionen
hervorrufen. Am Test sind dazu die Systeme Thing und Theory beteiligt, die
erfolgreich einen Verbund gebildet haben (vgl. Abbildung 9-10).
Auf Thing wird nun mittels des Task-Managers der Prozeß Systemdetector beendet.
Der Rechner soll jedoch regulär weiterlaufen, damit er über das Netzwerk immernoch
erreichbar ist. Theory muß diesen Fall behandeln, wie ein reguläres Beenden der
Applikation und den Rechner Thing als graues Symbol darstellen, da der Host immernoch konnektierbar ist (vgl. Abbildung 9-11).
63
Kapitel 9
Tests
Abbildung 9-10: Screenshot Theory
Abbildung 9-11: Thing als graues Symbol
64
Kapitel 9
Tests
Die Applikation auf dem System Theory hat korrekt erkannt, daß auf dem Rechner
Thing die Applikation nicht mehr läuft. Der Host Thing wird als konnektierbar
eingestuft und mit grauem Symbol dargestellt. In der Rechnerliste wird der Benutzername gelöscht und der Rechnername mit dem Domain Namen ergänzt.
9.6 Netzwerkstörung simulieren
In diesem Test wird in einem existierenden Rechnerverbund die Kommunikation
gestört, indem die Netzwerkleitungen der Rechner getrennt werden. Dadurch ist eine
Kommunikation zwischen den Applikationen unmöglich. Die Programme müssen jetzt
erkennen, daß der Rechnerverbund aufgelöst worden ist. Von jedem Rechner aus
betrachtet ist kein anderer Rechner mehr konnektierbar. Nach Ablauf der Zeitgrenze
für Host nicht erreichbar (vgl. Kapitel 8.2.3) müssen die nicht erreichbaren Rechner
als durchgestrichene Rechnersymbole im Listenfeld dargestellt werden (vgl. Tabelle
8-3). An diesem Test sind die beiden Testsysteme Theory und Thread beteiligt, die
einen Rechnerverbund bilden. Zusätzlich befinden sich zahlreiche andere Hosts im
Netzwerk (vgl. Abbildung 9-12).
Abbildung 9-12: Screenshot Theory
65
Kapitel 9
Tests
An den beiden Systemen Theory und Thread werden nun die Netzwerkkabel
abgezogen, um die Störung zu simulieren. Der Rechnerverbund sollte nach kurzer Zeit
als aufgelöst dargestellt werden. Zusätzlich müssen nach Ablauf der Zeitgrenze für
Host nicht erreichbar alle Rechner im Netzwerk als durchgestrichener Rechner
dargestellt werden (vgl. Abbildung 9-13).
Abbildung 9-13: Screenshot Thread
Der Host Thread hat richtig erkannt, daß kein Rechner im Netzwerk erreichbar ist.
Deshalb werden alle Systeme korrekt mit dem durchgestrichenen Rechnersymbol
dargestellt. Auf dem Rechner Theory liegen gleiche Ergebnisse vor. Die Funktionen
der Applikation sind durch die Trennung vom Netzwerk nicht beeinträchtigt worden.
Die Anwendungen laufen auf beiden Testsystemen weiterhin stabil.
66
Kapitel 10
Probleme und Ausblick
10 Probleme und Ausblick
Bei den in Kapitel 9 beschriebenen Testläufen sind einige Probleme hinsichtlich der
Bestimmung der Verbindungs-Bandbreite deutlich geworden. Um zu einem relativ
genauen Meßergebnis zu gelangen, muß die Paketgröße, die über das Netzwerk
gesendet wird, sehr groß sein. Dabei wachsen die Übertragungszeiten proportional zur
Paketgröße an. Der Fehler durch die Meßungenauigkeit bei der Zeitmessung wird mit
zunehmender Paketgröße kleiner. Probleme treten jedoch auf, wenn zum gleichen
Zeitpunkt ein anderer Rechner das Netzwerk stark belastet, z.B. wenn eine andere
Applikation gerade eine Performance-Messsung durchführen. Dadurch werden die
Meßergebnisse verfälscht. Je länger die Messung andauert, desto größer ist die
Wahrscheinlichkeit, daß diese Messung gestört wird. Dies steht im Gegensatz zu dem
Wunsch einer langen Meßdauer, um die Zeit-Meßungenauigkeiten zu minimieren. Es
muß also ein gesundes Mittelmaß gefunden werden. Das Programm Systemdetctor
verwendet zur Performance-Messung eine Paketgröße von 100 KByte. In einem 10
Mbit Netzwerk dauert die Übertragung bei idealen Voraussetzungen ca. 80 ms. Der
verwendete Zeitmesser hat eine Auflösung von 1 ms, wodurch der Meßfehler kleiner
als 10% sein sollte. In der Praxis sind jedoch deutliche Schwankungen in der
Performance gemessen worden, wenn andere Rechner sehr aktiv waren. Die ermittelte
Verbindungs-Bandbreite muß deshalb mit großer Vorsicht betrachtet werden. Zur
Verbesserung der Ergebnisse müßte ein Verfahren entwickelt werden, daß
Störfaktoren, wie z.B. ein stark belastetes Netzwerk ausschließen kann.
Das entwickelte Programm ist derzeit nur auf einem MS Windows NT System
lauffähig, da zur Bestimmung von einigen Systemdaten auf spezielle MS Windows NT
Funktionen zurückgegriffen wird. Da die meisten Programmfunktionen generell auf
Win32 Systemen arbeiten, ist eine Portierung der Anwendung auf Win95/98 Systeme
möglich. Lediglich die NT-spezifischen Funktionen müssen dabei ersetzt werden.
Die Systemdaten, die für einen Rechner gesammelt werden, geben immer die aktuellen
Momentanwerte an. Ältere Werte werden nicht gespeichert, sondern periodisch durch
neue ersetzt. Deshalb ist es nicht möglich den zeitlichen Verlauf, oder den Mittelwert
eines Datums über einen gewissen Zeitraum darzustellen. Um dies zu ermöglichen,
müßten mehrere Werte für die jeweiligen Systemdaten gespeichert werden.
67
Kapitel 11
Literatur
11 Literatur
[CHA98]
Chapman, Davis
Visual C++ 6 in 21 Tagen
SAMS, Haar 1998
ISBN 3-8272-2035-1
[INS98]
Microsoft Press
Inside Visual C++ 6.0
Microsoft Press, Unterschleißheim 1998
ISBN 3-86063-461-5
[LIB98]
Microsoft Press
Microsoft Visual C++ 6.0 Reference Library
Microsoft Press, Redmond 1998
ISBN 1-57231-865-1
[MIC98]
Microsoft Press
Microsoft Visual C++ 6.0 Programmierhandbuch
Microsoft Press, Unterschleißheim 1998
ISBN 3-86063-054-7
[MIN98]
Minasi, Mark
Windows NT Server 4
Sybex, Düsseldorf 1998
ISBN 3-8155-5516-7
[QUI96]
Quinn, Bob / Shute, Dave
Windows Sockets Network Programming
Addison-Wesley, Reading 1996
ISBN 0-201-63372-8
[SCH99]
Schüppel, Volker
Erstellen einer Software zur Performance-Bestimmung einer Netzwerkverbindung
Studienarbeit S275, Lehrstuhl für Datenverarbeitung
Ruhr-Universität Bochum, Bochum 1999
68
Kapitel 11
Literatur
[STE94]
Stevens, W. Richard
TCP/IP Illustrated, Volume 1
Addison-Wesley, Reading 1994
ISBN 0-201-63346-9
[SWA91]
Swan, Tom
C++ Lernen
Systhema Verlag, München 1991
ISBN 3-89390-268-6
[WAS94]
Washburn, Kevin/ Evans, Jim
TCP/IP, Aufbau und Betrieb eines TCP/IP-Netzes
Addison-Wesley, Bonn 1994
ISBN 3-89319-658-7
69
Inhalt Anhang
Inhalt Anhang
Anhang A Systemdaten ............................................................................................. 71
Anhang B Multithread-Programmierung ................................................................... 73
Anhang C Testsysteme .............................................................................................. 75
Anhang D Funktionsbeschreibung............................................................................. 76
D-I Klasse CDynamicDataThread ......................................................................... 76
D-II Klasse CScannerThread................................................................................. 76
D-III Klasse CServerSocket ................................................................................... 77
D-IV Klasse CSysInfoThread ................................................................................ 79
D-V Klasse CSystemdetectorDlg ........................................................................... 79
Anhang E Member-Objekte und Objekt-IDs.............................................................. 92
Anhang F Schnittstellen der Klassen ......................................................................... 95
Anhang G Programmstrukturen................................................................................. 97
G-I Klasse CDynamicDataThread ......................................................................... 97
G-II Klasse COptionsDialog.................................................................................. 97
G-III Klasse CScannerThread ............................................................................... 98
G-IV Klasse CSysInfoThread ................................................................................ 99
G-V Klasse CSystemdetectorDlg ........................................................................... 99
70
Anhang A
Systemdaten
Anhang A Systemdaten
d / s1 Beschreibung
Kompletter Name, der im DNS für die jeweilige IP eins getragen ist. Bei Rechnern, auf denen die Applikation
läuft, wird der Name der Domäne weggelassen.
Benutzername
Name des Benutzers, der unter Windows NT derzeit
s
eingeloggt ist.
IP-Adresse
IP-Adresse. Sollte kein Netzwerk vorhanden ein, so
s
wird die Loopback-Adresse 127.0.0.1 eingetragen
MAC-Adresse
Die eindeutige physikalische Netzwerkkarten-Adresse.
s Falls sie nicht bestimmbar ist, wird 00:00:00:00:00:00
eingetragen.
Subnetzmaske
Subnetzmaske. Falls kein Netzwerk vorhanden ist, wird
s
255.0.0.0 eingetragen.
Netz-Adresse
Adresse des gesamten Subnetzes. Wird aus IP-Adresse
s
und Subnetzmaske gebildet.
Betriebssystem
s Betriebssystem
Prozessorhersteller
Herstellername, den das BIOS meldet. Abhängig von
s
BIOS und CPU.
Prozessortyp
Gibt die Generation des Prozessors an. Abhängig von
s
BIOS und CPU.
Anzahl der ProzesAnzahl der Prozessoren, die Windows NT erkannt hat.
soren
s In fehlerhaft konfigurierten Systemen, kann diese Zahl
von der tatsächlichen Prozessoranzahl abweichen.
Taktfrequenz
Gibt die Taktfrequenz des Prozessors an. Abhängig von
s
BIOS und CPU.
d Momentane Prozessorlast
Prozessorauslastung
s Größe des Applikations-Laufwerks2
Festplattengröße
Freier
Freier Speicher auf Applikations-Laufwerks
d
Festplattenplatz
Physikalischer
RAM, den Windows NT beim Booten erkannt hat.
s
Speicher
Freier physikalischer
RAM, der noch nicht vom Betriebssystem oder And
Speicher
wendungsprogrammen belegt ist.
Virtueller Speicher
Speicher, den Windows NT inklusive der Auslaged
rungsdatei verwenden kann.
System-Ressource
Rechnername
1
d / s – dynamisch / statisch
2
Applikations-Laufwerk – Das logische Laufwerk von dem die Applikation gestartet worden ist
71
Anhang A
System-Ressource
Freier
virtueller Speicher
Bildschirmschoner
VerbindungsBandbreite
Letztes
Lebenszeichen
Systemdaten
d / s Beschreibung
d
d
d
d
Freier Speicher, den Windows NT inklusive der Auslagerungsdatei verwenden kann.
Gibt den Status des Bildschirmschoners an.
Netzwerk-Performance, die auf Anwendungsebene gemessen wird.
Zeitpunkt der letzten erfolgreichen Ping-Antwort, oder
des letzten Systemdatenpakets.
Tabelle A-1: Systemdaten
72
Anhang B
Multithread-Programmierung
Anhang B Multithread-Programmierung
Der Pfad (Faden) der Ausführung durch ein Programm wird als Thread bezeichnet. Er
ist die kleinste Ausführungseinheit, die von einem Multitasking-Betriebssystem geplant wird. Ein Thread besteht aus einem Stack, dem Zustand der CPU-Register und
einem Eintrag in die Ausführungsliste des System-Schedulers. Jeder Thread teilt alle
Ressourcen eines Prozesses. Ein Prozeß besteht aus einem oder mehreren Threads,
sowie dem Code, den Daten und anderen Ressourcen eines im Speicher befindlichen
Programms (vgl. Abbildung B-1).
Prozeß 1
Prozeß 2
Daten
Daten
Thread 1
Thread 1
Thread 2
Prozeß n
...
Thread 3
Daten
Thread 1
Thread 2
Abbildung B-1: Threads in Prozessen
Typische Programm-Ressourcen sind geöffnete Dateien, Semaphore und dynamisch
reservierter Speicher. Ein Programm wird ausgeführt, wenn der System-Scheduler
einem seiner Threads die Kontrolle über die Ausführung gibt. Der Scheduler legt fest,
welche Threads zu welchem Zeitpunkt ausgeführt werden sollen. Dabei haben
Threads mit einer höheren Priorität Vorrang vor denen mit niedrigerer Priorität. Auf
Systemen mit mehreren Prozessoren kann zudem der Scheduler einzelne Threads auf
verschiedene Prozessoren verteilen, um die CPU-Auslastung auszugleichen.
In einem Prozeß laufen die Threads unabhängig voneinander, d.h. solange diese nicht
einander "sichtbar" werden, laufen sie einzeln und ohne Kenntnis der anderen ab.
Threads, die sich gemeinsame Ressourcen teilen, müssen ihre Arbeit mit Hilfe von
Synchronisations-Mechanismen und anderen Formen von Interprozeß-Kommunikation
koordinieren.
Threads können in zwei unterschiedliche Typen eingeteilt werden. Es gibt worker
Threads und user-interface Threads. Ein worker Thread wird hauptsächlich verwendet, um Hintergrundaktionen durchzuführen, die für den Benutzer des Programms
nicht sichtbar sind. So kann es sein, daß ein worker Thread auf bestimmte Ereignisse
wartet, die nur selten auftreten. In der restlichen Zeit befindet sich ein solcher Ausführungspfad im Wartezustand. Ein User-interface Thread wird hauptsächlich zur Einund Ausgabe von Daten, bzw. zur Darstellung der Benutzungsoberfläche eines
Programms verwendet. Er kontrolliert Benutzereingaben über Maus und Tastatur und
73
Anhang B
Multithread-Programmierung
reagiert individuell auf diese Aktionen. Dieser Thread-Typ befindet sich nie in einem
Wartezustand, da für den Benutzer keine Verzögerungen entstehen sollen.
Das Programm Systemdetector startet zu Programmbeginn vier Threads. Der HauptThread ist vom Typ user-interface Thread, da er unter anderem die Benutzungsschnittstelle bereitstellt. Bei den drei anderen Ausführungspfaden handelt es sich um
worker Threads. Sie bearbeiten lediglich Hintergrundaufgaben. Anhand der Ablaufdiagramme läßt sich erkennen, daß typische Wartezustände in den worker Threads zu
finden sind.
Während des Programmablaufs findet eine Kommunikation zwischen den einzelnen
Threads statt. Dies ist notwendig um den Zustand eines anderen Pfades zu ermitteln,
um sich gegenseitig zu synchronisieren oder um auf gemeinsame Daten zuzugreifen.
Vor allen Dingen der Zugriff auf gemeinsame Daten stellt ein großes Problem dar, da
die Konsistenz der Daten gewährleistet werden muß. Es muß der Fall betrachtet
werden, daß verschiedene Threads gleichzeitig den gleichen Code abarbeiten, bzw. die
gleichen Daten manipulieren. Dies erfordert eine sehr korrekte und genaue Programmierung. Die MFC bietet Synchronistionsmechanismen, die diese Aufgabe vereinfachen. Hierzu gehören Ereignisse, Semaphore und Mutexe.
Ein Ereignis ist eine Nachricht, die an einem bestimmten Thread gesendet werden
kann. Der Empfänger-Pfad kann diese Nachricht auswerten und daraufhin eine bestimmte Anweisungsfolge ausführen.
Semaphore begrenzen die Anzahl der Threads, die eine bestimmte Ressource verwenden. Ein Semaphor verhindert, daß mehr Pfade auf eine Ressource zugreifen, als
maximal erlaubt sind. Sollte ein Thread versuchen auf eine Ressource zuzugreifen, die
schon durch die maximal zulässige Anzahl belegt ist, so wird dieser Thread solange
blockiert, bis ein Zugriff auf die Ressource wieder möglich ist.
Ein Mutex ist ein Synchronisations-Objekt, welches den exklusive Zugriff von einem
Pfad auf eine Ressource erlaubt. Mutexe sind sinnvoll, wenn nur einem Thread die
Modifikation von Daten erlaubt sein soll.
74
Anhang C
Testsysteme
Anhang C Testsysteme
Name
THING
THREAD
THEME
THEOREM
THEORY
THRILLER
CPU
Celeron-333 MHz
Pentium II-350 Mhz
Pentium II-400 Mhz
Pentium-133 MHz
Pentium II-266 MHz
Intel 486-133 MHz
Festplatte
911 MB
1,0 GB
1,0 GB
1,2 GB
3,3 GB
811 MB
RAM
64 MB
128 MB
64 MB
64 MB
192 MB
48 MB
Netzwerkkarte
10 Mbit BNC
10 Mbit BNC
10 Mbit BNC
10 Mbit BNC
10 Mbit BNC
10 Mbit BNC
Tabelle C-1: Testsysteme
75
Anhang D
Funktionsbeschreibung
Anhang D Funktionsbeschreibung
D-I Klasse CDynamicDataThread
GetData()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Dies ist die Hauptfunktion des Daten-Threads. In einer Endlosschleife wird
periodisch der freie Festplattenplatz, der freie Hauptspeicher und der virtuelle
Speicher abgefragt. Außerdem wird ein Lebenszeichen für den lokalen Rechner
eingetragen. Am Ende der Schleife wird bei jedem Durchlauf gewartet. Die
Länge dieser Warteschleife kann in den Programmeinstellungen mit dem Wert
Systemdaten-Intervall angegeben werden.
SetOwner()
Eingabeparameter:
CSystemdetecterDlg* pOwner
Rückgabeparameter:
void
Beschreibung:
Es wird ein Zeiger auf das aufrufende Dialogfeld gesetzt. Dadurch ist ein
Zugriff von diesem Thread auf die Daten des Haupt-Dialogfeldes möglich.
D-II Klasse CScannerThread
Rechner_abfragen()
Eingabeparameter:
unsigned int ip
int zaehler
Rückgabeparameter:
void
Beschreibung:
Diese Funktion überprüft im zweistufigen Verfahren, ob ein entferntes System
konnektierbar ist, bzw. ob die Applikation auf dem System läuft. Der erste
76
Anhang D
Funktionsbeschreibung
Eingabeparameter gibt die IP-Adresse des Hosts an, der zweite Parameter gibt
den Index im Rechnerdatenfeld an, in dem die Ergebnisse eingetragen werden.
Scanner()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Dies ist die Hauptfunktion des Threads und wird vom Haupt-Thread aus
gestartet. Die Funktion ermittelt die nächste IP-Adresse, die vom Scanner
überprüft werden muß. Mit dieser Adresse wird dann Rechner_abfragen
aufgerufen.
SetOwner()
Eingabeparameter:
CSystemdetecterDlg* pOwner
Rückgabeparameter:
void
Beschreibung:
Es wird ein Zeiger auf das aufrufende Dialogfeld gesetzt. Dadurch ist ein
Zugriff von diesem Thread auf die Daten des Haupt-Dialogfeldes möglich.
D-III Klasse CServerSocket
OnAccept()
Eingabeparameter:
int ErrorCode
Rückgabeparameter:
void
Beschreibung:
Diese Funktion akzeptiert eine Verbindungsanfrage auf dem Server-Socket. Der
Eingabeparameter übergibt eine Socket-Fehlermeldungen, die hier behandelt
wird. Ein Fehlercode von „0“ zeigt an, daß kein Fehler vorliegt.
OnClose()
Eingabeparameter:
int ErrorCode
77
Anhang D
Funktionsbeschreibung
Rückgabeparameter:
void
Beschreibung:
Eine bestehende Verbindung auf dem Server-Socket wird geschlossen. Die
Socket-Fehlermeldung, die über den Eingabeparameter übergeben wird, wird
hier ausgewertet.
OnConnect()
Eingabeparameter:
int ErrorCode
Rückgabeparameter:
void
Beschreibung:
Diese Funktion wird aufgerufen, wenn eine Verbindung zu einem anderen
Rechner auf dem Server-Socket initiiert wird. Der Eingabeparameter übergibt
eine Socket-Fehlermeldungen, die hier behandelt wird. Ein Fehlercode von „0“
zeigt an, daß kein Fehler vorliegt.
OnReceive()
Eingabeparameter:
int ErrorCode
Rückgabeparameter:
void
Beschreibung:
Hiermit werden Daten aus dem Empfangspuffer des Server-Sockets gelesen.
Die Socket-Fehlermeldung, die über den Eingabeparameter übergeben wird,
werden ebenfalls in dieser Funktion ausgewertet.
OnSend()
Eingabeparameter:
int ErrorCode
Rückgabeparameter:
void
Beschreibung:
Diese Funktion wird aufgerufen, wenn Daten zu einem verbunden Rechner über
den Server-Socket gesendet werden. Der Eingabeparameter übergibt eine
Socket-Fehlermeldungen, die hier behandelt wird. Ein Fehlercode von „0“ zeigt
an, daß kein Fehler vorliegt.
78
Anhang D
Funktionsbeschreibung
SetParent()
Eingabeparameter:
CDialog *pWnd
Rückgabeparameter:
void
Beschreibung:
Es wird ein Zeiger auf das aufrufende Dialogfeld gesetzt. Dadurch ist ein
Zugriff auf die Daten des Haupt-Dialogfeldes möglich.
D-IV Klasse CSysInfoThread
GetSysInfo()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Dies ist die Hauptfunktion des CPU-Threads. In einer Schleife wird periodisch
die CPU-Auslastung, der Status des Bildschirmschoners und der Status des
Scanners abgefragt. Am Ende der Schleife wird bei jedem Durchlauf gewartet.
Die Länge dieser Warteschleife wird in den Programmeinstellungen als CPUMonitor-Intervall bezeichnet wird.
SetOwner()
Eingabeparameter:
CSystemdetecterDlg* pOwner
Rückgabeparameter:
void
Beschreibung:
Es wird ein Zeiger auf das aufrufende Dialogfeld gesetzt. Dadurch ist ein
Zugriff von diesem Thread auf die Daten des Haupt-Dialogfeldes möglich.
D-V Klasse CSystemdetectorDlg
Cluster_ueberpruefen()
Eingabeparameter:
void
Rückgabeparameter:
void
79
Anhang D
Funktionsbeschreibung
Beschreibung:
Diese Funktion überprüfung die Rechner, die durch ein erfolgreiches Ping im
Netzwerk gefunden worden und als konnektierbar eingestuft worden sind. Dazu
wird die aktuelle Systemzeit mit dem Zeitpunkt des letzten Lebenszeichens
verglichen. Falls zwischen diesen beiden Zeitpunkten eine Zeitspanne
vergangen ist, die größer ist als die Programmoption Host nicht erreichbar, so
gilt dieser Rechner nicht mehr als konnektierbar und wird mit dem
durchgestrichenen Rechner-Symbol gekennzeichnet.
Connect_to_hosts()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Es werden die eigenen Rechnerdaten an alle anderen Systeme gesendet, auf
denen die Applikation läuft. Dazu werden die Rechner im Netzwerk
nacheinander konnektiert. Um zu erkennen, ob die Applikation auf den anderen
Rechnern läuft, werden die Daten verwendet, die der Scanner liefert. Falls ein
System zum ersten mal konnektiert wird, so wird kein Systemdatenpaket
gesendet, sondern ein Benchmark durchgeführt. Falls zu einem Rechner an
dieser Stelle keine Verbindung zustande kommt, so wird dieser Rechner als nur
noch erreichbar eingestuft und im der Rechnerliste mit einem grauen Symbol
geführt.
CSV_Datei()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Speichert die aktuelle Rechnerliste mit allen Systemdaten in der Ausgabedatei
im CSV-Format. Der Name der Ausgabedatei kann in den Programmoptionen
angegeben werden, der standardmäßig cluster.csv lautet.
80
Anhang D
Funktionsbeschreibung
CSV_Datei_laden()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Falls eine Ausgabedatei im CSV-Format vorhanden ist, so wird sie am Programmstart mit Hilfe dieser Funktion geladen. Dabei werden aus der Datei nur
die Adressen und der Zeitpunkt des letzten Lebenszeichens übernommen. Alle
anderen Daten, die in der Ausgabedatei abgelegt sind, werden als veraltet
betrachtet und nicht übernommen. Die geladenen Rechner werden in der Rechnerliste mit dem Programmsymbol eingetragen, wodurch angezeigt werden soll,
daß der aktuelle Zustand des Systems noch nicht bestimmt worden ist. Der
Name der Ausgabedatei kann in den Programmoptionen angegeben werden.
Standardmäßig lautet der Name cluster.csv.
Daten_aktualisieren()
Eingabeparameter:
_rechner rechner
int typ
Rückgabeparameter:
void
Beschreibung:
Diese Funktion aktualisiert die Systemdaten für einen Rechner, der sich bereits
im Rechnerfeld befindet. Das bedeutet, daß alle Datenstrukturen für dieses
System bereits vorher erstellt worden sind, in denen mindestens die IP-Adresse
und das letzte Lebenszeichen eingetragen sind. Die neuen Rechnerdaten werden
durch den Eingabeparameter rechner übergeben. Der zweite Parameter gibt an,
welche Daten aus rechner in die Rechnerliste eingetragen werden sollen. Dieser
Parameter kann drei unterschiedliche Werte besitzen, die den jeweiligen Typ
des ersten Parameters angeben (vgl. Tabelle D-1).
Typ
2
3
4
Bedeutung
Rechner über Ping erreichbar. In der _rechner-Struktur sind nur die
Felder IP-Adresse und Hostname gültig.
Auf Rechner läuft Applikation. Alle Felder der _rechner-Struktur sind
gültig.
Benchmark. Nur die Felder Bandbreite und Messungen sind gültig.
Tabelle D-1: Typen
81
Anhang D
Funktionsbeschreibung
Eigenes_Icon_ueberpruefen()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Diese Funktion ermittelt die Darstellung des eigenen Rechner-Symbols in der
Rechnerliste. Das Symbol wird aus dem Status des Bildschirmschoners und der
aktuellen CPU-Auslastung bestimmt.
Feld_anzeigen()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Hier wird die Ausgabe der Rechnerliste im Hauptdialogfeld gesteuert. Dazu
wird zuerst bestimmt welche Rechner-Typen überhaupt für den Benutzer
sichtbar sein sollen. Danach wird die Rechnerliste durchlaufen und für jeden
Rechner überprüft, ob er neu dargestellt werden muß. Falls sich die Ansicht
eines Rechners geändert hat, so ist in seinem Datensatz das changed-Flag
gesetzt. Hat sich die Ansicht der ganzen Rechnerliste geändert, so ist das
Member-Flag m_ViewChanged gesetzt und die gesamte Rechnerliste wird neu
dargestellt. Nachdem das Dialogfeld aktualisiert worden ist, werden alle
gesetzten Flags wieder auf FALSE gesetzt.
Konv_IP()
Eingabeparameter:
CString ip
Rückgabeparameter:
CString
Beschreibung:
Diese Funktion ändert die Darstellung von IP-Adressen. Dazu werden alle vier
Abschnitte der Adresse mit 0-en aufgefüllt. Der Eingabeparameter beinhaltet
die originale Adresse. Der Ausgabewert hat nach der Konvertierung eine Länge
von 15 Zeichen. Dadurch können IP-Adressen, die in CStrings gespeichert
worden sind, verglichen und sortiert werden. Bei einer unterschiedlichen Länge
der CStrings wäre eine Sortierung nicht möglich.
82
Anhang D
Funktionsbeschreibung
KonvBand()
Eingabeparameter:
Float wert
Rückgabeparameter:
CString
Beschreibung:
Die Verbindungsbandbreite wird im Rechnerdatensatz als Float-Wert in Bit/s
angegeben. Da die Performance oft bei einigen Mbit/s liegt, ist sie für den
Benutzer schlecht zu lesen. Zusätzlich negativ wirkt sich aus, daß die Anzahl
der Nachkommastellen variiert. Diese Funktion formatiert die Verbindungsbandbreite, indem die Einheiten kbit/s, Mbit/s und Gbit/s verwendet werden.
Außerdem werden die Nachkommastellen auf zwei begrenzt. Der Wert wird
dann als CString inklusive der verwendeten Einheit ausgegeben.
KonvBytes()
Eingabeparameter:
CString
Rückgabeparameter:
CString
Beschreibung:
Die Systemdaten, die eine Speichergröße beschreiben, wie z.B. freier
physikalischer Hauptspeicher, verwenden die Einheit Byte. Da die erfaßten
Daten jedoch Speichergrößen im MByte- oder GByte-Bereich besitzen, sind
diese Werte für den Benutzer schlecht überschaubar. Deshalb formatiert diese
Funktion die Speichergröße mit einer passenden Einheit, wobei die Anzahl der
Nachkommastellen auf zwei begrenzt wird.
LocalDisk()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Diese Funktion bestimmt die Größe und den freien Speicherplatz der Festplattenpartition, von der die Applikation gestartet worden ist.
83
Anhang D
Funktionsbeschreibung
LocalIPAdress()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Hier wird die lokale IP-Adresse bestimmt. Falls kein Netzwerk vorhanden ist,
wird die Loopback-Adresse 127.0.0.1 angegeben.
LocalMACAdress()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Die Funktion bestimmt die lokale MAC-Adresse. Falls keine Netzwerkkarte
vorhanden ist, wird die Adresse 00:00:00:00:00 angegeben
LocalMachine()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Es wird der lokale Computernamen bestimmt. Dabei wird nicht der Name vom
DNS-Server abgefragt, sondern der Eintrag in den lokalen Netzwerkeinstellungen verwendet.
LocalMemory()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Diese Funktion ermittelt die lokalen physikalischen und virtuellen Hauptspeicherwerte.
84
Anhang D
Funktionsbeschreibung
LocalOS()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Hier wird der Typ und die Versionsnummer des Betriebssystems bestimmt.
LocalProcessor()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Der Hersteller, der Typ und die Taktfrequenz des lokalen Prozessors wird
bestimmt. Dabei wird auf die Angaben zurückgegriffen, die von der CPU und
vom BIOS über das Betriebssystem geliefert werden.
LocalUser()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Diese Funktion liefert den Namen des Benutzers, der am lokalen Rechner angemeldet ist.
NetzwerkAktiv()
Eingabeparameter:
void
Rückgabeparameter:
BOOL
Beschreibung:
Es wird ermittelt, ob ein Netzwerk vorhanden ist. Die Funktion liefert den Wert
TRUE zurück, falls ein Netzwerk vorhanden ist, andernfalls wird FALSE
zurückgegeben.
85
Anhang D
Funktionsbeschreibung
OnAccept()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Die Funktion akzeptiert eine Verbindung auf dem Server-Socket.
OnClose()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Hier wird eine bestehende Verbindung auf dem Server-Socket geschlossen.
OnConnect()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Es wird eine Verbindung auf dem Server-Socket geöffnet und nach einem
erfolgreichen Verbindungsaufbau die Funktion OnSend aufgerufen.
OnDetails()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Diese Funktion erstellt das Details-Dialogfeld für den markierten Rechner.
Vorher werden die Systemdaten des Rechners in das Dialogfeld übernommen.
OnInitDialog()
Eingabeparameter:
void
86
Anhang D
Funktionsbeschreibung
Rückgabeparameter:
void
Beschreibung:
Diese Funktion wird zu Beginn des Programmes aufgerufen, noch bevor der
Hauptdialog erstellt wird. Es wird zuerst überprüft, ob ein Netzwerk vorhanden
ist und ob die Applikation schon auf dem lokalen Rechner läuft. Danach werden
die Programmparameter aus der Konfigurationsdatei geladen, die eigenen
Systemdaten bestimmt und die eventuell vorhandene Ausgabedatei geladen.
Letztlich werden die Timer und die nebenläufigen Threads gestartet.
OnOptions()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Diese Funktion erstellt ein modales Optionen-Dialogfeld. Vorher werden die
aktuellen Programmparameter in die Eingabefelder des Optionen-Dialogs
kopiert. Nach dem Schließen des Dialogs werden die Änderungen übernommen. Falls notwendig, werden die Timer neu gestartet, weil sich die
Intervallzeiten geändert haben.
OnReceive()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Es werden Daten aus dem Empfangspuffer gelesen. Das empfangene Paket wird
in Protokollkopf und Nutzdaten zerlegt. Am Protokollkopf ist ersichtlich, ob
das empfangene Paket von der Applikation Systemdetector abgesendet worden
ist. Falls der Protokollkopf ungültig ist, wird das Paket verworfen. Handelt es
sich um ein Datenpaket, so werden jetzt die Daten unter Verwendung der
Funktionen Daten_aktualisieren und Rechner_hinzufuegen in die Rechnerliste
eingetragen. Falls ein Benchmark-Paket eintrifft, wird die Verbindungsbandbreite bestimmt. Die bestehende Verbindung zu dem Rechner wird danach geschlossen.
87
Anhang D
Funktionsbeschreibung
OnSend()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Diese Funktion wird aufgerufen, wenn vom Server-Socket Daten gesendet
werden.
OnClose()
Eingabeparameter:
void
Rückgabeparameter:
void
Beschreibung:
Hiermit wird eine bestehende Verbindung auf dem Server-Socket geschlossen.
OnTimer()
Eingabeparameter:
UINT nIDEvent
Rückgabeparameter:
void
Beschreibung:
Die Funktion wird aufgerufen, wenn ein Timer-Event ausgelöst worden ist. Mit
dem Eingabeparameter nIDEvent wird die Nummer des Timer-Ereignisses
übergeben. Die an dieses Ereignis gekoppelten Anweisungen werden daraufhin
ausgeführt. In dieser Funktion werden alle zeitgesteuerten Funktionen, wie z.B.
die Feldanzeige und der Scanner, behandelt.
PingHost()
Eingabeparameter:
unsigned long ulIP
int iPingTimeout
Rückgabeparameter:
DWORD
Beschreibung:
Die Aufgabe dieser Funktion besteht darin, eine Ping-Anfrage an einen entfernten Host zu senden, um festgestellt, ob der Host konnektierbar ist. Mit den
88
Anhang D
Funktionsbeschreibung
Eingabeparametern wird die IP-Adresse und der Timeout-Wert mitgeteilt. Als
Funktionsergebnis wird die Antwortzeit des Hosts angegeben. Falls der Rechner
nicht antwortet, so wird ein Ausgabewert zurückgeliefert, der größer ist als der
Timeout-Wert, woraus die aufrufenden Funktionen erkennen, daß ein Rechner
nicht erreichbar ist.
Rechner_anzeigen()
Eingabeparameter:
_rechner* rechner
Rückgabeparameter:
void
Beschreibung:
Diese Funktion trägt einen Rechner in das Listenfeld im Hauptdialog ein. Dabei
wird die IP-Adresse in die erste, der Hostname in die zweite und der Benutzername in die dritte Spalte eingetragen.
Rechner_hinzufuegen()
Eingabeparameter:
_rechner rechner_daten
int typ
Rückgabeparameter:
void
Beschreibung:
Diese Funktion fügt dem Rechnerfeld einen neuen Rechner mit seinen Systemdaten hinzu. Der erste Eingabeparameter beinhaltet die Daten des Rechners, der
zweite Parameter gibt an, welche Felder im ersten Parameter gültig sind. Dazu
werden vier unterschiedliche Typen verwendet (vgl. Tabelle D-2).
Typ
1
2
3
4
Bedeutung
Rechnerdaten kommen aus der CSV-Datei. Es werden nur die
Felder IP-Adresse und letztes Lebenszeichen übernommen.
Rechner über Ping erreichbar. In der _rechner-Struktur sind nur die
Felder IP-Adresse und Hostname gültig.
Auf Rechner läuft Applikation. Alle Felder der _rechner-Struktur
sind gültig.
Benchmark. Nur die Felder Bandbreite und Messungen sind gültig.
Tabelle D-2: Typen
89
Anhang D
Funktionsbeschreibung
Rechner_suchen()
Eingabeparameter:
CString ip
Rückgabeparameter:
_rechner
Beschreibung:
Die Aufgabe dieser Funktion ist es, einen Rechner in der Rechnerliste zu
suchen. Als Suchkriterium dient die IP-Adresse als Eingabeparameter. Als Ausgabe wird der komplette Datensatz des Rechners geliefert.
Screensaver_abfragen()
Eingabeparameter:
void
Rückgabeparameter:
CString
Beschreibung:
Diese Funktion ermittelt den Namen des Bildschirmschoners, der für den
lokalen Rechner für den angemeldeten Benutzer momentan eingestellt ist. Der
Name wird als Rückgabeparameter zurückgeliefert. Falls keine Bildschirmschoner eingetragen ist, wird ein leerer String übergeben.
SD_running()
Eingabeparameter:
void
Rückgabeparameter:
BOOL
Beschreibung:
Hier wird ermittelt, ob bereits ein anderer Prozeß mit dem Namen Systemdetector läuft. Die Funktion liefert den Wert TRUE zurück, falls ein gleicher
Prozeß gefunden worden ist, andernfalls FALSE.
SortTextItems()
Eingabeparameter:
int nCol
BOOL bAscending
int low
int high
90
Anhang D
Funktionsbeschreibung
Rückgabeparameter:
BOOL
Beschreibung:
Diese Funktion sortiert das Rechnerlistenfeld im Hauptdialog. Dazu wird im
ersten Eingabeparameter die Spalte, nach der sortiert werden soll, angegeben.
Der zweite Parameter gibt an, ob auf- oder absteigend sortiert werden soll. Der
Wert TRUE bedeutet aufsteigende Sortierung. Mit den letzten beiden
Parametern wird die untere und obere Grenze der Indizes der Elemente angegeben, die sortiert werden sollen. Der Rückgabeparameter gibt mit TRUE eine
erfolgreiche Sortierung an. Falls eine Sortierung mit den angegebenen Parametern nicht möglich ist, wird FALSE zurückgeliefert.
91
Anhang E
Member-Objekte und Objekt-IDs
Anhang E Member-Objekte und Objekt-IDs
Bedienelement
Objekt-ID / Nachricht
CAboutDlg
Dialogfeld
IDD_ABOUTBOX
Member-Funktion /
Member-Variable
DoDataExchange
Text
Bitmap
Text
Version 1.0
Button
OK
CDetailsDialog
Dialogfeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Gruppenfeld
Gruppenfeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
IDC_STATIC
IDC_SYMBOL
IDC_VERSION
IDOK
IDD_DETAILS
IDC_ANZAHL_PROZESSOREN
IDC_BANDWIDTH
IDC_BENUTZERNAME
IDC_DOMAIN
IDC_FRAME1
IDC_FRAME2
IDC_IPADRESSE
IDC_MACADRESSE
IDC_NETZWERK
IDC_OS
IDC_P_LAST
IDC_PLATTENPLATZ
IDC_PLATTENPLATZ_FREI
IDC_PROZESSOR_HERSTELLER
IDC_PROZESSOR_SPEED
IDC_PROZESSOR_TYP
IDC_RAM
IDC_RAM_FREI
IDC_RAM_VIRT
IDC_RAM_VIRT_FREI
IDC_RECHNERNAME
IDC_SAVER
DoDataExchange
m_anzahl_prozessoren
m_bandwidth
m_benutzer_name
m_domain
m_ip_adresse
m_mac_adresse
m_netzwerk
m_os
m_p_last
m_plattenplatz
m_plattenplatz_frei
m_prozessor_hersteller
m_prozessor_speed
m_prozessor_typ
m_ram
m_ram_frei
m_ram_virt
m_ram_virt_frei
m_rechner_name
m_saver
92
Anhang E
Member-Objekte und Objekt-IDs
Bedienelement
Objekt-ID / Nachricht
Text
Eingabefeld
Eingabefeld
Button
Schließen
COptionsDialog
Dialogfeld
IDC_STATIC
IDC_SUBNETZMASKE
IDC_TIME
IDCANCEL
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Button
History
löschen
Eingabefeld
Eingabefeld
Eingabefeld
Eingabefeld
Button
Scanner
starten
SpinButton
SpinButton
SpinButton
SpinButton
SpinButton
SpinButton
SpinButton
SpinButton
Text
Member-Funktion /
Member-Variable
m_subnetzmaske
m_time
IDD_OPTIONS
IDC_BENCHMARK
EN_CHANGE
IDC_CPU
IDC_DATENAUSTAUSCH
EN_CHANGE
IDC_FELDANZEIGE
EN_CHANGE
IDC_FILE
IDC_HISTORY
DoDataExchange
OnInitDialog
m_Benchmark
OnChangeBenchmark
m_CPU
m_Datenaustausch
OnChangeDatenaustasch
m_Feldanzeige
OnChangeFeldanzeige
m_File
OnHistory
IDC_INFO
IDC_LEBENSZEICHEN
IDC_PING
IDC_SCANNER
EN_CHANGE
IDC_SCANNER_BUTTON
m_Info
m_Lebenszeichen
m_Ping
m_Scanner
OnChangeScanner
OnScannerButton
IDC_SPIN1
IDC_SPIN2
IDC_SPIN3
IDC_SPIN4
IDC_SPIN5
IDC_SPIN6
IDC_SPIN7
IDC_SPIN8
IDC_STATIC
m_Datenaustausch_Ctrl
m_Scanner_Ctrl
m_CPU_Ctrl
m_Systemdaten_Ctrl
m_Ping_Ctrl
m_Feld_Ctrl
m_lebenszeichen_Ctrl
m_Benchmark_Ctrl
93
Anhang E
Member-Objekte und Objekt-IDs
Bedienelement
Objekt-ID / Nachricht
Button
IDCANCEL
Abbrechen
Button
IDOK
OK
CSystemdetectorDlg
Dialogfeld
IDD_SYSTEMDETECTOR_DIALOG
Radiobutton
Listenfeld
Progressbar
CPUAuslastung
Button
Details
Button
Beenden
Button
Optionen
Radiobutton
WM_INIT_DIALOG
WM_PAINT
WM_QUERYDRAGICON
WM_SYSCOMMAND
WM_TIMER
IDC_ALIVE
IDC_CLUSTER
LVN_COLUMNCLICK
NM_DBLCLK
IDC_CPU
Member-Funktion /
Member-Variable
OnOK
DoDataExchange
OnInitDialog
OnPaint
OnTimer
OnAlive
m_Cluster
OnColumnClickCluster
OnDblclkCluster
IDC_DETAILS
OnDetails
IDC_EXIT_BUTTON
OnExitButton
IDC_OPTIONS
OnOptions
IDC_PING
OnAlive
Tabelle E-1: Member-Objekte und Objekt-IDs der Dialogfelder
94
Anhang F
Schnittstellen der Klassen
Anhang F Schnittstellen der Klassen
Zwischen den wichtigsten Klassen CSystemdetectorDlg, CDynamicDataThread,
COptionsdialog, CScannerThread, CServerSocket und CSysInfoThread sind Schnittstellen in bezug auf die aufzurufenden Funktionen und Variablen definiert worden.
Diese sind folgend tabellarisch aufgeschlüsselt.
Zeiger von CDynamicDataThread auf CSystemdetectorDlg: m_pOwner→
Funktion
LocalMemory
LocalDisk
Variablen
m_Disk_free
m_erster_rechner
m_AvailPhysMemory
m_AvailVirtualMemory m_TotalVirtualMemory
Tabelle F-1: Zugriff von CDynamicDataThread auf CSystemdetectorDlg
Zeiger von COptionsDialog auf CSystemdetectorDlg: m_pWnd→
Funktion
SuspendScanner
m_erster_rechner
m_Cluster
Variablen
m_Benchmarkintervall m_Ping
m_Filename
m_CPUintervall
m_Datenaustauschintervall m_Lebensintervall
m_Scannerintervall
m_Infointervall
m_Feldanzeigeintervall
Tabelle F-2: Zugriff von COptionsDialog auf CSystemdetectorDlg
Zeiger von CScannerThread auf CSystemdetectorDlg: m_pOwner→
Funktion
ResolveIP
Konv_IP
PingHost
Variablen
m_host
m_IpAdresse
Tabelle F-3: Zugriff von CScannerThread auf CSystemdetectorDlg
95
Anhang F
Schnittstellen der Klassen
Zeiger von CServerSocket auf CsystemdetectorDlg: m_pWnd→
Funktion
OnAccept
OnConnect
OnClose
OnReceive
OnSend
Tabelle F-4: Zugriff von CServerSocket auf CSystemdetectorDlg
Zeiger von CSysInfoThread auf CsystemdetectorDlg: m_pOwner→
Variablen
m_CPU
m_erster_rechner
m_Scanner_aktiv
m_CPUintervall
Tabelle F-5: Zugriff von CSysInfoThread auf CSystemdetectorDlg
96
Anhang G
Programmstrukturen
Anhang G Programmstrukturen
G-I Klasse CDynamicDataThread
Endlosschleife
Intervall abwarten
LocalDisk
LocalMemory
Neue Daten eintragen
Abbildung G-1:GetData
G-II Klasse COptionsDialog
Sicherheitsabfrage
Abfrage mit OK beantwortet ?
Nein
Ja
Rechnerliste löschen
Listenfeld im Hauptdialog löschen
%
Ausgabedatei löschen
Abbildung G-2: OnHistory
Scanner aktiv ?
Nein
Ja
Button Scanner starten
deaktivieren
%
Wertebereiche für Eingabefelder einstellen
Werte in Eingabefelder eintragen
Abbildung G-3: OnInitDialog
97
Anhang G
Programmstrukturen
Neue Werte OK ?
Ja
Nein
Neue Werte aus den
Eingabefeldern übernehmen
Einstellungen in
Konfigurationsdatei speichern
Fehler ausgeben
Dailogfeld schließen
Abbildung G-4: OnOK
G-III Klasse CScannerThread
PingHost
Antwortzeit<Timeout ?
Nein
Ja
Ping-Flag
setzen
Verbindung auf Port 9001 aufbauen
Verbindung erfolgreich ?
Ja
Nein
Verbindung
schließen
ApplikationsFlag setzen
Ping- und ApplikationsFlag löschen
Applikations-Flag
löschen
Abbildung G-5: Rechner_abfragen
98
Anhang G
Programmstrukturen
G-IV Klasse CSysInfoThread
Endlosschleife
CPU-Last, Scanner-Status und
Bildschirmschoner-Status abfragen
CPU-Last abspeichern
CPU-Last im Hauptdialog anzeigen
Scanner-Status abspeichern
Bildschirmschoner-Status abspeichern
Intervall abwarten
Abbildung G-6: GetSysInfo
G-V Klasse CSystemdetectorDlg
Aktuelle Systemzeit bestimmen
Schleife über alle Rechner
Lebenszeichen zu alt?
Ja
Nein
Symbol ändern
%
Abbildung G-7: Cluster_ueberpruefen
Schleife über alle Rechner
Erreichbar und Applikation?
Nein
Ja
Benchmark gelaufen?
Ja
Typ 1 senden
Nein
Typ 2 senden
Nur erreichbar?
Ja
Rechner mit
grauem Symbol
eintragen
Nein
%
Abbildung G-8: Connect_to_host
99
Anhang G
Programmstrukturen
Ausgabedatei erstellen
Zeile mit Überschriften abspeichern
Schleife über alle Rechner
Systemdaten abspeichern
Neue Zeile
Abbildung G-9: CSV_Datei
Ausgabedatei öffnen
Zeile mit Überschriften überspringen
Schleife über alle Zeilen
Neuen Rechner erstellen
IP-Adresse und letztes Lebenszeichen abspeichern
Abbildung G-10: CSV_Datei_laden
Rechner in Rechnerliste suchen
Fallunterscheidung Typ
3
2
Ändere Symbol
auf grau
Altes Symbol
farbig?
Ja
N
Lösche
Systemdaten
Bestimme
Hostnamen
Bestimme
farbiges
Symbol
Trage
% Systemdaten
ein
4
default
Trage
Bandbreite
ein
%
Abbildung G-11: Daten_aktualisieren
100
Anhang G
Programmstrukturen
Bildschirmschoner aktiv?
Ja
Nein
Fallunterscheidung CPU-Last
Fallunterscheidung CPU-Last
33%<Last
Last<=33% <=66%
Last>=67%
default
Gelbes
Symbol
%
Grünes
Symbol
Rotes
Symbol
33%<Last
Last<=33% <=66%
Last>=67%
Grünes Z Gelbes Z
Rotes Z
default
%
Hat sich Symbol geändert?
Ja
Nein
%
Rechner neu zeichnen
Abbildung G-12: Eigenes_Icon_ueberpruefen
Schleife über alle Rechner
Hat sich Rechneransicht geändert ?
Ja
Fallunterscheidung Symbol
Farbig
Rechner
neu
zeichnen
Grau
Durchgestrichen
Typ anzeigen?
Ja
Rechner
neu
zeichnen
default
Typ anzeigen?
N
Ja
Rechner
% neu
zeichnen
Nein
%
N
%
%
Abbildung G-13: Feld_anzeigen
Ist genau ein Rechner markiert?
Ja
Nein
Bestimme markierten Rechner
Kopiere Systemdaten ins Details-Dialogfeld
%
Erzeuge modalen Details-Dialog
Abbildung G-14: OnDetails
101
Anhang G
Programmstrukturen
Rufe Bestätigungs-Dialog auf
Ist Beenden bestätigt worden?
Nein
Ja
Server-Socket schließen
%
Programm beenden
Abbildung G-15: OnExitButton
Daten-Strukturen initialisieren
Läuft die Applikation bereits?
Nein
Ja
Ist ein Netzwerk vorhanden?
Nein
Ja
%
Eigene IP-Adresse auf Loopback setzen
Konfigurationsdatei auslesen
Lokale Systemdaten abfragen
Programm
beenden
Eigene Daten in Rechnerfeld eintragen
Existiert eine alte CSV-Datei ?
Ja
Nein
CSV Datei laden
%
Nebenläufige Threads starten
Timer starten
Eigene IP-Adresse=Loopback ?
Ja
Nein
Scanner starten
%
Abbildung G-16: OnInitDialog
102
Anhang G
Programmstrukturen
Programmeinstellungen in Optionen-Dialog kopieren
Optionen-Dialog als modales Fenster starten
Haben sich Intervalle geändert?
Ja
Nein
%
Timer beenden und neu starten
Abbildung G-17: OnOptions
Daten aus Empfangspuffer abholen
Paket in Protokollkopf und Nutzdaten zerlegen
Fallunterscheidung Protokollkopf
Typ 2
Letztes Paket?
Typ 1
Verbindung schließen
Rechner schon
im Rechnerfeld ?
Ja
Ja
Nein
Bandbreite
bestimmen
Nein
Verbindung
schließen
Verbindung
schließen
Daten_aktualisieren
Sonstiges
Rechner_hinzufuegen
Daten_aktualisieren
%
Werte neu
initialisieren
Abbildung G-18: OnReceive
Fallunterscheidung Timer-Event
2
1
Connect_to_hosts
Cluster_ueberpruefen
Eigenes_Icon_ueberpruefen
3
4
default
Feld_anzeigen
Reinitialize_Benchmark
%
Netzwerk?
Ja
N
SuspendScanner
%
Abbildung G-19: OnTimer
103
Anhang G
Programmstrukturen
Neue Rechnerstruktur am Ende der
Rechnerliste einfügen
Fallunterscheidung Typ
1
2
IP-Adresse
eintragen
IP-Adresse
eintragen
Lebenszeichen
eintragen
Hostnamen
eintragen
Programmsymbol
eintragen
3
4
Alle Systemdaten eintragen
Bandbreite
eintragen
default
Systemzeit und Systemzeit und
Lebenszeichen Lebenszeichen Systemzeit und
eintragen
eintragen
Lebenszeichen
Graues Symbol Farbiges Symbol eintragen
eintragen
eintragen
CSV-Datei
speichern
CSV-Datei
speichern
%
CSV-Datei
speichern
Abbildung G-20: Rechner_hinzufuegen
104