Senden von TCP/IP-Telegrammen aus einem Visual Basic

Transcription

1
Senden von TCP/IP-Telegrammen aus
einem Visual Basic-Programm
Von:
Fabian Baur, Matrikelnummer 156002
und
Daniel Letzgus, Matrikelnummer 156040
Seminararbeit an der Fachhochschule Heilbronn
Studiengang:
Wirtschaftsingenieurwesen
Lehrveranstaltung:
Ausgewählte Kapitel
der Automatisierungstechnik
Abgabedatum:
15. Dezember 2003
Betreuer:
Prof. Dr.-Ing. H. Frank
Senden von TCP/IP Telegrammen aus einem Visual Basic-Programm
2
Inhaltsverzeichnis
1. Einleitung......................................................................................................... 4
2. Konkrete Aufgabenstellung.......................................................................... 5
3. Grundlagen...................................................................................................... 6
3.1 Das TCP/IP – Protokoll ............................................................................ 6
3.1.1 Einordnung in das ISO/OSI - Referenzmodell............................. 6
3.1.2 Das TCP - Protokoll........................................................................... 7
3.1.2.1 Die Phasen einer TCP-Verbindung [7] ................................... 8
Die Einrichtungsphase ......................................................................... 8
Die Datenaustauschphase ................................................................ 10
Die Abschlussphase............................................................................ 10
3.1.3 Das IP – Protokoll ........................................................................... 12
3.2 Das Winsock – Objekt in Visual Basic ................................................ 13
3.2.1 Kurzbeschreibung:.......................................................................... 13
3.2.2 Eigenschaften
[104]..................................................................... 14
3.2.3 Ereignisse [6] ................................................................................. 16
3.2.4 Methoden [6].................................................................................. 19
4. Lösung der Aufgabenstellung .................................................................... 25
4.1 Senden von TCP/IP – Telegrammen aus Visual Basic .................... 26
4.1.1 Die Benutzeroberflächen ............................................................... 26
4.1.2 Programmablaufpläne .................................................................... 27
4.1.2.1 Verbindungsaufbau.................................................................. 28
4.1.2.2 Textversand von Server an Client ........................................ 29
4.1.2.3 Textversand von Client an Server ........................................ 30
4.2 Die Protokollanalyse mit „Ethereal“.................................................... 33
Literaturhinweise .............................................................................................. 37
Anhang
3
Abbildungsverzeichnis
Abbildung 3-1: ISO OSI Referenzmodell [2] ................................................................... 7
Abbildung 3-2: Der TCP Header [8] .................................................................................... 8
Abbildung 3-3: Die Einrichtungsphase [7] ....................................................................... 9
Abbildung 3-4: Die Datenaustauschphase [7].............................................................. 10
Abbildung 3-5: Die Abschlussphase [7] .......................................................................... 11
Abbildung 3-6: Der IP Header [8]...................................................................................... 12
Abbildung 3-7: Eigenschaften,Ereignisse und Methoden des Winsock-Objekts
[6] .......................................................................................................................................... 13
Abbildung 4-1: Benutzeroberfläche des Server-Programms .................................. 26
Abbildung 4-2: Benutzeroberfläche des Clientprogramms...................................... 27
Abbildung 4-3: Verbindungsaufbau-Programmablaufplan ...................................... 28
Abbildung 4-4: Datenaustausch-Programmablaufplan (ServerÆ Client) .......... 29
Abbildung 4-5: Datenaustausch-Programmablaufplan (Client Æ Server)......... 30
Abbildung 4-6: Kommentierter Quellcode des Server-Programms...................... 31
Abbildung 4-7: Kommentierter Quellcode des Client-Programms ....................... 32
Abbildung 4-8: TCP-Einrichtungsphase, Synchronisationsaufforderung........... 33
Abbildung 4-9: TCP-Einrichtungsphase, Synchronisationsantwort ..................... 34
Abbildung 4-10: TCP-Einrichtungsphase, Synchronisationsbestätigung........... 35
Abbildung 4-11: TCP-Datenaustauschphase, Datenversand mit
Bestätigungsaufforderung............................................................................................ 35
Abbildung 4-12: TCP-Datenaustauschphase, Empfangsbestätigung................... 36
Tabellenverzeichnis
Tabelle 3-1: Einstellungen der Winsock-Protocol-Eigenschaft [6] ...................... 14
Tabelle 3-2: Einstellungen der Winsock-State-Eigenschaft [6]............................. 16
Tabelle 3-3: Einstellungen für die Winsock-Typ-Methode [6]................................ 21
Tabelle 3-4: Die Winsock-Fehlercodes [6] ..................................................................... 24
4
1. Einleitung
Der Trend hin zu vernetzten Fertigungen ist deutlich zu erkennen und nicht mehr
aufzuhalten.
In der Steuerungs- und Automatisierungstechnik setzt sich in diesem Zuge das
Ethernet immer mehr durch. Oft werden dabei SPS1-Steuerungen über das
Ethernet mit PC´s vernetzt.
Der Transport von Daten über das Ethernet kann mit mehreren verschiedenen
Protokollen vorgenommen werden, welche im ISO2/OSI3–Referenzmodell auf der
vierten Schicht, der Transportschicht, zu finden sind. Die zwei bedeutendsten
dieser Protokolle sind das TCP 4und das UDP 5Protokoll. Der wesentliche
Unterschied besteht in der Verlässlichkeit der Protokolle. Beim TCP–Protokoll
wird nach Erhalt eines Datenpaketes eine Bestätigung versendet. Diese
Bestätigung gibt es beim UDP–Protokoll nicht, was dieses Protokoll unverlässlich
macht. Aus diesem Grund ist bei Anwendungen mit geforderter Verlässlichkeit das
TCP–Protokoll zu verwenden.
1
Speicherprogrammierbare Steuerungen
2
International Standards Organisation
3
Open System Interconnection
4
Transmission Control Protocol
5
User Datagram Protocol
5
2. Konkrete Aufgabenstellung
Thema dieser Seminararbeit ist das Senden von TCP/IP6-Telegrammen aus
einem Visual Basic (VB)-Programm. Die Ergebnisse dieses Projektes sollen
Grundlage sein für das Vernetzen bzw. die Kommunikation von SPS-Steuerungen.
Im ersten Schritt soll eine Möglichkeit gefunden werden um Telegramme aus
einem VB-Programm über das Ethernet an ein VB-Programm auf einem anderen
PC zu senden.
Im zweiten Schritt soll kontrolliert werden, ob tatsächlich das TCP/IP – Protokoll
verwendet wird und wie die übertragenen Daten im Protokoll dargestellt werden.
6
Internet Protocol
6
3. Grundlagen
In diesem Kapitel werden die, für die Lösung der Aufgabenstellung benötigten,
Grundlagen erklärt.
3.1 Das TCP/IP – Protokoll
Das TCP/IP–Protokoll wird gerne als ein Protokoll verstanden. Tatsächlich sind es
aber zwei Protokolle, das TCP–Protokoll und das IP–Protokoll.
3.1.1 Einordnung in das ISO/OSI - Referenzmodell
„Das ab 1978 von der ISO entwickelte OSI Referenzmodell stellt einen (durchaus
gelungenen) Versuch dar die Kommunikation zwischen
Informationsverarbeitenden Endsystemen auf internationaler Ebene zu
standardisieren.
Die ISO beschreibt in ihrem OSI Standard ein 7 Schichten Modell, in dem jede
Schicht (engl. Layer) seine eigenen speziellen Aufgaben wahrnimmt. Jede Schicht
bietet ihren nächsten beiden Schichten, also der höher und der niedriger
liegenden Schicht ein transparentes Interface an.“ [1]
Das TCP–Protokoll ist im ISO/OSI–Referenzmodell auf der Schicht vier, der
Transportschicht, das IP-Protokoll auf der Schicht drei, der Netzwerkschicht,
angesiedelt (vgl. Abbildung 3-1).
„Die Transportschicht ist für die zuverlässige Datenübermittlung zwischen zwei
Kommunikationspartnern verantwortlich.
Die Netzwerkschicht ist in erster Linie für das Routing zuständig.“ [3]
7
Abbildung 3-1: ISO OSI Referenzmodell [2]
3.1.2 Das TCP - Protokoll
„TCP ist ein verbindungsorientiertes Transportprotokoll für den Einsatz in
paketvermittelten Netzen. Das Protokoll baut auf dem IP-Protokoll auf, unterstützt
die Funktionen der Transportschicht und stellt vor der Datenübertragung eine
gesicherte Verbindung zwischen den Instanzen her. Die Daten der höheren
Schichten werden durch TCP nicht verändert, sondern lediglich segmentiert und in
einzelnen Datenpaketen versendet. Jedes Oktett (Anm. d. Verf.: Byte) eines
Segments wird von TCP mit einer Sequenznummer versehen, um empfangsseitig
die richtige Reihenfolge zu garantieren.
Die wesentlichen Dienstleistungen, die das TCP-Protokoll in Verbindung mit dem
IP-Protokoll für die Anwendungsprozesse bereitstellt, sind die Ende-zu-EndeKontrolle, das Verbindungs-Management, die Flusskontrolle, die Zeitkontrolle und
das Multiplexen von Verbindungen sowie die Fehlerbehandlung.“ [4]
8
Die Abbildung 3-2 zeigt den Aufbau des TCP – Protokollkopfs.
Abbildung 3-2: Der TCP Header [8]
Auf ein ausführliche Beschreibung der Felder des TCP – Headers wird an dieser
Stelle verzichtet, jedoch auf den Anhang verwiesen.
3.1.2.1 Die Phasen einer TCP-Verbindung [7]
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 (vgl. Abbildung 3-3), die Datenaustauschphase
(vgl. Abbildung 3-4) und die Abschlussphase (vgl. Abbildung 3-5) eingeteilt.
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
TCP-Ebene. Die TCP-Implementierung erzeugt ein Segment und gibt es an die IPSchicht weiter, die daraus ein IP-Datagramm erzeugt. Im TCP-Segment ist das
SYN-Flag gesetzt, um dem Empfänger-System zu signalisieren, dass sich die
beiden Systeme auf die gültigen Sequenz- und Bestätigungsnummern einigen
9
müssen. Das Sende-System trägt seine aktuelle Sequenznummer in das Segment
ein. Die Bestätigung 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 SendeSystem bestätigt dieses Segment, indem das ACK-Flag gesetzt wird. Die
Bestätigungsnummer enthält die erhöhte Sequenznummer des EmpfängerSystems.
Damit ist die TCP-Verbindung eingerichtet und die Sequenznummern
ausgetauscht. Beide Stationen sind jetzt bereit, die eigentlichen Daten
auszutauschen.
Sender
Netz
Empfänger
SYN=153
ACK=?
SYN 1
53
kein A
CK
SYN=321
ACK=154
K 154
21 AC
3
N
Y
S
SYN=154
ACK=322
ACK
322
Zeit
Abbildung 3-3: Die Einrichtungsphase [7]
10
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 das einfachste Szenario, dass bei einer Dateübertragung stattfinden
kann.
Netz
Sender
Die Daten
„xx“ werden
gesendet
SEQ=
102 A
CK=1
19
Empfänger
Data=
xx
Empfang wird
bestätigt
103
ACK=
9
1
1
SEQ=
Zeit
Abbildung 3-4: Die Datenaustauschphase [7]
Der Sender sendet seine Daten an den Empfänger und erwartet ein BestätigungsSegment. Dabei wird am Sender ein Timer gestartet. Sollte die vorher festgelegt
Zeitgrenze für dir 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.
Die Abschlussphase
Möchte eines der beteiligten Systeme die bestehende Verbindung beenden, so
initiiert es die Abschlussphase. Dabei sendet dieses System ein TCP-Segment in
dem das FIN-Flag gesetzt ist. Das andere System bestätigt zuerst den Empfang
mit einem Segment und antwortet dann mit einem zusätzlichen Segment, in dem
11
ebenfalls das FIN-Flag gesetzt ist. Auch dieses Segment muß vom Sender noch
einmal bestätigt werden.
Sender
Netz
Empfänger
SEQ=
306 A
CK=5
17 FIN
07
ACK 3
07
CK=3
517 A
SEQ=
FIN
ACK
=518
Zeit
Abbildung 3-5: Die Abschlussphase [7]
Die Verbindung wird nicht als geschlossen betrachte, solange nicht beide Systeme
Segment, in denen das FIN-Flag gesetzt ist, gesendet und den Empfang der FINSegmente bestätigt haben. Falls in dieser Phase Segmente verloren gehen, wird
die Verbindung nach Ablauf eines Timeout als getrennt betrachtet
12
3.1.3 Das IP – Protokoll
„Die Aufgabe des Internet-Protokolls (IP) besteht darin, Datenpakete von einem
Sender über mehrere Netze hinweg zu einem Empfänger zu transportieren. Die
Übertragung ist paketorientiert, verbindungslos und nicht garantiert. IP garantiert
weder die Einhaltung einer bestimmten Reihenfolge noch eine Ablieferung beim
Empfänger. Empfangsquittungen gibt es auf IP-Schicht nicht. Die maximale Länge
von IP-Datenpaketen ist auf 65.535 Bytes beschränkt.
Da das Internet-Protokoll auf der Vermittlungsschicht aufsetzt und diese für das
IP-Routing durch ein Netzwerk zuständig ist, erlaubt das Protokoll auch die
Identifikation von Stationen anhand der IP-Adresse. Damit die Datenpakete nicht
unendlich durch das Netz irren und dieses verkehrsmäßig belasten, hat der IPHeader ein Time-to-Live-Feld (TTL), in dem die Lebensdauer eines Datagramms
festgelegt wird. Dieses Feld setzt die Zeitdauer fest, nach der ein Datenpaket
verworfen wird.“ [4]
Die Abbildung 3-6 zeigt den Header des IP – Protokolls.
Abbildung 3-6: Der IP Header [8]
Auf ein ausführliche Beschreibung der Felder des IP – Headers wird an dieser
Stelle verzichtet, jedoch auf den Anhang verwiesen.
13
3.2 Das Winsock – Objekt in Visual Basic
Zur Lösung der Aufgabenstellung wird das Visual Basic–Steuerelement „Winsock“
verwendet.
3.2.1 Kurzbeschreibung:
„Das Winsock-Steuerelement vereinfacht die Kommunikation zwischen PCs unter
VB erheblich. Es fasst alle TCP/IP-Befehle der API 7von Windows in einem Control
zusammen. Winsock beherrscht auch das Protokoll UDP.“ [5]
In folgender Abbildung ist eine Übersicht über die Eigenschaften, Ereignisse und
Methoden des Winsock – Objekts dargestellt.
Eigenschaften
BytesReceived
LocalHostName
LocalIP
LocalPort
Protocol
RemoteHost
RemoteHostIP
RemotePort
SocketHandle
Ereignisse
Close [Ereignis]
Connect [Ereignis]
ConnectionRequest
DataArrival
Error
SendComplete
SendProgress
Methoden
Accept
Bind
Close
Connect
GetData
Listen
PeekData
SendData
State
Abbildung 3-7: Eigenschaften,Ereignisse und Methoden des Winsock-Objekts [6]
7
Application Programming Interface
14
3.2.2 Eigenschaften [104]
In diesem Kapitel werden die verwendeten Eigenschaften des Winsock-Objekts
beschrieben. Für Beschreibungen aller Eigenschaften des Winsock-Objekts wird
auf den Anhang verwiesen.
a)
LocalPort (Long):
Gibt den zu verwendenden lokalen Anschluß zurück oder legt diesen fest. Zur
Entwurfszeit nicht verfügbar.
b)
Protocol:
Gibt das Protokoll zurück oder legt dieses fest, entweder TCP oder UDP, daß vom
Winsock-Steuerelement verwendet wird.
Die möglichen Protokoll-Einstellungen sind in Tabelle 3-1 dargestellt.
Konstante
Wert Beschreibung
sckTCPProtocol
0
Voreinstellung. TCP-Protokoll.
sckUDPProtocol
1
UDP-Protokoll.
Tabelle 3-1: Einstellungen der Winsock-Protocol-Eigenschaft [6]
Anmerkung
Da standardmäßig das TCP – Protokoll eingestellt ist, konnte auf die Verwendung
dieser Eigenschaft verzichtet werden.
c)
RemoteHost (String):
Gibt den Remote-Computer zurück, an den ein Steuerelement Daten sendet oder
von dem es Daten erhält, oder legt ihn fest. Man kann entweder einen HostNamen bereitstellen, z.B. "FTP://ftp.microsoft.com", oder eine IPAdressenzeichenfolge im Format mit Punkten, wie z.B. "100.0.1.1".
Anmerkungen:
Wird diese Eigenschaft angegeben, so wird die URL-Eigenschaft aktualisiert, um
den neuen Wert anzuzeigen. Diese Eigenschaft wird auch dann aktualisiert, um
den neuen Wert wiederzugeben, wenn der Host-Bereich des URLs aktualisiert
wird.
15
Die RemoteHost-Eigenschaft kann auch durch den Aufruf der OpenURL- oder
Execute-Methoden geändert werden.
Zur Laufzeit hat die Änderung dieses Wertes keine Auswirkung bis zur nächsten
Verbindung.
d)
RemoteHostIP (String):
Gibt die IP-Adresse des Remote-Computers zurück.
•
Für Client-Anwendungen enthält diese Eigenschaft die IP-Zeichenfolge des
Remote-Computers, nachdem eine Verbindung über die Connect-Methode
eingerichtet wurde
•
Für Server-Anwendungen enthält diese Eigenschaft nach einer
eingehenden Verbindungsanforderung (ConnectionRequest-Ereignis) die
IP-Zeichenfolge des Remote-Computers, der die Verbindung hergestellt
hat.
•
Bei Verwendung des UDP-Protokolls enthält diese Eigenschaft die IPAdresse des Rechners, der die UDP-Daten gesendet hat, nachdem das
DataArrival-Ereignis aufgetreten ist.
e)
RemotePort (Long):
Gibt die Netzanschlussnummer zurück oder stellt diese ein, mit der die
Verbindung aufgebaut werden soll.
Anmerkungen
Wenn man die Protocol-Eigenschaft festlegt, wird die RemotePort-Eigenschaft
automatisch auf den passenden Standardanschluss für jedes Protokoll festgelegt.
f)
State (Integer):
Gibt den Status des Steuerelements als numerische Konstante zurück. Die
Eigenschaft ist schreibgeschützt und zur Entwurfszeit nicht verfügbar.
Die möglichen Einstellungen für die State-Eigenschaft sind in Tabelle 3-2
aufgeführt.
16
Konstante
Wert Beschreibung
Voreinstellung.
sckClosed
0
sckOpen
1
Geöffnet
sckListening
2
Überwachen
sckConnectionPending 3
Geschlossen
Verbindung
anstehend
Host-Name wird
sckResolvingHost
4
sckHostResolved
5
sckConnecting
6
Verbinden
sckConnected
7
Verbunden
sckClosing
8
sckError
9
aufgelöst
Host-Name wurde
aufgelöst
Partner schließt die
Verbindung
Fehler
Tabelle 3-2: Einstellungen der Winsock-State-Eigenschaft [6]
3.2.3 Ereignisse [6]
In diesem Kapitel werden die verwendeten Ereignisse des Winsock-Objekts
beschrieben. Für Beschreibungen aller Ereignisse des Winsock-Objekts wird auf
den Anhang verwiesen.
a)
Close [Ereignis]:
Tritt ein, wenn der Remote-Computer die Verbindung beendet. Anwendungen
sollten die Close-Methode zur korrekten Beendigung einer TCP-Verbindung
verwenden.
Syntax: Winsock_Close ()
17
b)
Connect [Ereignis]
Tritt auf, nachdem eine Verbindung zum Server aufgebaut wurde.
Syntax: Winsock_Connect ()
Anmerkungen
Man kann das Connect-Ereignis abfangen und jede Art von anfänglichen Abfragen
durchführen, die für eine neue Verbindung erforderlich sind, zum Beispiel den
Vergleich der Datenbankversion mit der Version des Clients oder die Einstellung
einer Standard-Datenbank, die in der Verbindungszeichenfolge nicht angegeben
ist. Man kann auch prüfen, ob während des Verbindungsaufbaus Fehler oder
Meldungen zurückgegeben wurden, oder auch nur die Informationsmeldungen aus
der rdoErrors-Auflistung (vgl. Tabelle 3-4) löschen.
c)
ConnectionRequest:
Tritt ein, wenn ein Remote-Computer eine Verbindung anfordert.
Nur für TCP-Server-Anwendungen. Das Ereignis tritt ein, wenn eine
Verbindungsanforderung eingeht. Die Eigenschaften RemoteHostIP und
RemotePort speichern die Informationen über den Client, nachdem das Ereignis
aktiviert wurde.
Syntax: Winsock_ConnectionRequest (AnforderungsID As Long)
AnforderungsID:
Der eingehende Bezeichner der Verbindungsanforderung. Dieses Argument
sollte der Accept-Methode in der zweiten Steuerelementinstanz übergeben
werden.
Anmerkungen:
Der Server kann entscheiden, ob die Verbindung akzeptiert wird oder nicht. Wird
die eingehende Verbindung nicht akzeptiert, so erhält der Partner (Client) das
Close-Ereignis. Um eine eingehende Verbindung zu akzeptieren, verwendet man
die Accept-Methode (in einer neuen Steuerelementinstanz).
d)
DataArrival
Tritt ein, wenn neue Daten ankommen.
Syntax: Winsock_DataArrival (AnzahlBytes As Long)
18
AnzahlBytes
Die Gesamtmenge der Daten, die abgerufen werden können.
Anmerkungen:
Dieses Ereignis tritt nicht ein, wenn man nicht alle Daten in einem einzigen
GetData-Aufruf anfordert. Es wird nur ausgelöst, wenn neue Daten vorhanden
sind. Um zu überprüfen wie viele Daten jeweils verfügbar sind verwendet man die
BytesReceived-Eigenschaft
e)
Error:
Tritt immer dann ein, wenn ein Fehler bei der Hintergrundverarbeitung auftritt (z.B.
ein Verbindungsfehler oder ein Fehler beim Senden oder Abrufen von Daten im
Hintergrund).
Syntax: Winsock_Error(Zahl As Integer, Beschreibung As String, Scode As
Long, Quelle As String, Hilfedatei as String, Hilfekontext As Long,
AnzeigeAbbrechen As Boolean)
Zahl
Eine Ganzzahl, die den Fehler-Code angibt. (vgl. Tabelle 3-4)
Beschreibung
Eine Zeichenfolge, die den Fehler beschreibt.
Scode
Der SCODE.
Quelle
Eine Zeichenfolge, die die Fehlerquelle beschreibt.
Hilfedatei
Eine Zeichenfolge, die den Dateinamen einer Hilfedatei angibt.
Hilfekontext
Hilfekontext.
AnzeigeAbbrechen
Gibt an, ob die Anzeige abgebrochen werden soll. Die Voreinstellung ist
False, d.h., das Standard-Fehlermeldungsfeld wird angezeigt. Wenn man
das Standard-Meldungsfeld nicht verwenden nöchte, muss man
AnzeigeAbbrechen auf True setzen.
19
f)
SendComplete:
Tritt ein, wenn eine Senden-Operation beendet wurde
Syntax: Winsock_SendComplete
g)
SendProgress:
Tritt ein, während Daten gesendet werden.
Syntax: Winsock_SendProgress (gesendeteBytes As Long,
zuSendendeBytes As Long)
gesendeteBytes
Die Anzahl der Bytes, die seit der letzten Aktivierung dieses Ereignisses
gesendet wurden.
zuSendendeBytes
Die Anzahl der Bytes im Puffer, die noch gesendet werden sollen.
3.2.4 Methoden [6]
In diesem Kapitel werden die verwendeten Methoden des Winsock-Objekts
beschrieben. Für Beschreibungen aller Methoden des Winsock-Objekts wird auf
den Anhang verwiesen.
a)
Accept:
Nur für TCP-Server-Anwendungen. Diese Methode wird dazu verwendet, eine
eingehende Verbindung zu akzeptieren, während ein ConnectionRequest-Ereignis
behandelt wird.
Syntax: Winsock.Accept AnfrageID
Anmerkungen
Die Accept-Methode wird im ConnectionRequest-Ereignis verwendet. Das
ConnectionRequest-Ereignis verfügt über ein entsprechendes Argument, den
Parameter AnforderungsID, der an die Accept-Methode übergeben werden sollte.
b)
Close [Methode]
Schließt eine TCP-Verbindung oder einen überwachenden Socket für Client- und
20
Server-Anwendungen.
Syntax: Winsock.Close
c)
Connect [Methode]
Stellt eine Verbindung zu einem Server her.
Syntax: Winsock.Connect [RemoteHost], [RemotePort]
d)
RemoteHost
IP-Adresse oder Hostname (wird automatisch aufgelöst) des Remote-Computers.
e)
RemotePort
Legt die Netzanschlußnummer fest.
Anmerkungen
Wenn die Eigenschaften RemoteHost und RemotePort gesetzt wurden, können
die Argumente weggelassen werden.
f)
GetData:
Ruft den aktuellen Datenblock ab und speichert diesen in einer Variablen vom Typ
Variant.
Syntax: Winsock.GetData Daten, [Typ,] [maxLänge]
Daten
Enthält die abgerufenen Daten, nachdem die Methode erfolgreich
zurückgegeben wurde. Sind nicht genügend Daten für den angeforderten
Typ verfügbar, so wird Daten auf Empty gesetzt.
Typ
Optional. Typ der abzurufenden Daten, wie unter Einstellungen (vgl.Tabelle
3-3) beschrieben.
maxLänge
Optional. Gibt die gewünschte Größe an, wenn ein Byte-Datenfeld oder
eine Zeichenfolge abgerufen wird. Fehlt dieses Argument für ein ByteDatenfeld oder eine Zeichenfolge, so werden alle verfügbaren Daten
21
abgerufen. Wird dieses Argument für andere Datentypen als ByteDatenfelder und Zeichenfolgen bereitgestellt, so wird es ignoriert.
Datentyp
Konstante
Byte
vbByte
Integer
vbInteger
Long
vbLong
Single
vbSingle
Double
vbDouble
Currency
vbCurrency
Date
vbDate
Boolean
vbBoolean
Long (Fehler-Code) vbError
String
vbString
Byte-Datenfeld
vbArray + vbByte
Tabelle 3-3: Einstellungen für die Winsock-Typ-Methode [6]
Anmerkungen
Gewöhnlich wird die GetData-Methode mit dem DataArrival-Ereignis verwendet,
welches das Argument AnzahlBytes beinhaltet. Wenn man eine maxLänge kleiner
als AnzahlBytes angeben, erhält man die Warnung 10040, die angibt, daß die
verbleibenden Bytes verlorengehen.
g)
Listen
Erstellt einen Socket und setzt diesen in den Überwachen-Modus. Diese Methode
funktioniert nur bei TCP-Verbindungen. Die Eigenschaft LocalPort sollte zuerst
gesetzt werden.
Syntax: Winsock.Listen
Anmerkungen
Das ConnectionRequest-Ereignis tritt ein, wenn eine Verbindung angefordert wird.
Bei der Behandlung des ConnectionRequest-Ereignisses sollte die Anwendung
22
die Accept-Methode verwenden (in einer neuen Instanz des Steuerelements), um
die Verbindung zu akzeptieren.
h)
SendData:
Sendet Daten an einen Remote-Computer.
Syntax: Winsock.SendData Daten
i)
Daten
Zu sendende Daten. Für binäre Daten sollten Byte-Datenfelder verwendet
werden.
23
j)
Die Winsock - Fehlercodes
In der Tabelle 3-4 sind die möglichen Fehlercodes des Winsock-Objekts
dargestellt.
Konstante
Wert Beschreibung
sckOutOfMemory
7
Nicht genügend Speicher
sckInvalidPropertyValue
380
Der Eigenschaftswert ist ungültig
sckGetNotSupported
394
Die Eigenschaft kann nicht gelesen werden
sckSetNotSupported
383
Die Eigenschaft ist schreibgeschützt
sckBadState
40006
Falsches Protokoll oder falscher Verbindungszustand für die
angeforderte Transaktion oder Anforderung
Das an eine Funktion übergebene Argument war nicht im
sckInvalidArg
40014 richtigen Format oder hatte keinen Wert im angegebenen
Bereich
sckSuccess
40017 Erfolgreich
sckUnsupported
40018 Nicht unterstützter Variant-Typ
sckInvalidOp
40020 Ungültige Operation für den aktuellen Zustand
sckOutOfRange
40021 Argument liegt außerhalb des zulässigen Bereichs
sckWrongProtocol
40026
sckOpCanceled
1004 Die Operation wurde abgebrochen
sckInvalidArgument
10014
sckWouldBlock
10035
sckInProgress
10036
sckAlreadyComplete
10037
sckNotSocket
10038 Der Deskriptor ist kein Socket
sckMsgTooBig
10040
sckPortNotSupported
10043 Der angegebene Anschluß wird nicht unterstützt
sckAddressInUse
10048 Adresse wird bereits verwendet
sckAddressNotAvailable
10049 Adresse steht vom lokalen Computer aus nicht zur Verfügung
Falsches Protokoll für die angeforderte Transaktion oder
Anforderung
Die angeforderte Adresse ist eine Broadcast-Adresse, aber das
Attribut wurde nicht gesetzt
Socket erlaubt keine Blockierungen, und die angegebene
Operation hat eine Blockierung zur Folge
Momentan wird eine blockierende Winsock-Operation
ausgeführt
Die Operation ist abgeschlossen. Momentan wird keine
blockierende Operation durchgeführt
Das Datagramm ist zu groß für den Puffer und wird
abgeschnitten
sckNetworkSubsystemFailed 10050 Netzwerk-Subsystem fehlgeschlagen
sckNetworkUnreachable
10051 Das Netzwerk ist von diesem Host aus zur Zeit nicht erreichbar
24
Zeitüberschreitung für Verbindung, wenn SO_KEEPALIVE
sckNetReset
10052
sckConnectAborted
11053
sckConnectionReset
10054 Die Verbindung wurde vom Remote-Computer zurückgesetzt
sckNoBufferSpace
10055 Kein Pufferspeicher verfügbar
sckAlreadyConnected
10056 Socket ist bereits verbunden
sckNotConnected
10057 Socket ist nicht verbunden
sckSocketShutdown
10058 Socket wurde heruntergefahren
sckTimedout
10060 Socket hat eine Zeitüberschreitung verursacht
sckConnectionRefused
10061 Herstellen der Verbindung wird absichtlich verweigert
sckNotInitialized
10093 WinsockInit muß zuerst aufgerufen werden
sckHostNotFound
11001 Autorisierte Antwort: Host nicht gefunden
gesetzt ist
Verbindung wurde aufgrund einer Zeitüberschreitung oder
eines anderen Fehlers getrennt
sckHostNotFoundTryAgain 11002 Nicht autorisierte Antwort: Host nicht gefunden
sckNonRecoverableError
11003 Nicht behebbare Fehler; Fortsetzung nicht möglich
sckNoData
11004 Gültiger Name; kein Datensatz des angeforderten Typs
Tabelle 3-4: Die Winsock-Fehlercodes [6]
25
4. Lösung der Aufgabenstellung
Wie in der Aufgabenstellung (vgl. Kapitel 2) erwähnt, ist die Aufgabe in zwei Teile
untergliedert:
•
Senden von TCP/IP – Telegrammen aus einem Visual Basic –
Programm
•
Analyse der Protokolle des Datenverkehrs
Zur Realisierung wurden folgende Geräte und Programme benutzt
•
1 Laptop, Betriessystem WinXP, 2,2 GHz – Prozessor, 512 MB RAM,
incl. einer PCMCIA-Wlan Karte, IP-Adresse 192.168.1.10; im folgenden
als PC1 bezeichnet.
•
1 Laptop, Betriebssystem Win2000, 400MHz – Prozessor, 192 MB
RAM, incl. einer PCMCIA-Wlan Karte, IP-Adresse 192.168.1.11; im
folgenden als PC2 bezeichnet.
•
1 Wlan-Switch, 11mBits/s, Marke DrayTek
•
Das Programm Visual Basic Studio zur Erstellung der benötigten Visual
Basic Programme. Installiert auf dem PC1.
•
Das Programm EtheReal zur Analyse des Datenflusses
Netzwerkverkehres. Installiert auf dem PC2.
Anmerkung:
Die Datei mswinsck.ocx musste auf dem PC2 noch in das Verzeichnis
C:\Winnt\system32 kopiert werden. Dazu wurde die Datei aus dem Internet
heruntergeladen.
26
4.1 Senden von TCP/IP – Telegrammen aus Visual Basic
Zum Senden der Telegramme wurden zwei Programme in Visual Basic erstellt.
Das eine wird im folgenden als Server – Programm, das andere als Client –
Programm bezeichnet. Das Server – Programm wird auf PC1 ausgeführt, das
Client – Programm auf PC2.
Die Funktion der Programme besteht darin, einen, in ein Eingabefeld
eingegebenen, Text über das Ethernet in das Textausgabefeld des anderen
Programms, auf dem anderen PC, zu schreiben.
4.1.1 Die Benutzeroberflächen
Zur Ein- und Ausgabe des Textes haben beide Programme eine
Benutzeroberfläche, welche in den beiden folgenden Abbildungen dargestellt sind.
(vgl. Abbildungen 4-1 und 4-2)
Textausgabefeld
Texteingabefeld
Abbildung 4-1: Benutzeroberfläche des Server-Programms
27
Textausgabefeld
Texteingabefeld
Abbildung 4-2: Benutzeroberfläche des Clientprogramms
Gibt der Anwender des Serverprogramms einen Text in sein Eingabefeld ein und
betätigt dann den „Senden“-Button wird der Text an das Client-Programm, auf der
Client-Seite, übertragen. In diesem Client-Programm wird der Text in das
Textausgabefeld geschrieben. Um die Kommunikation nachvollziehen zu können,
wird der Text auch im Textausgabefeld des Server-Programms angezeigt.
Nach dem gleichen Prinzip funktioniert auch der Text-Versand vom ClientProgramm zum Server-Programm.
4.1.2 Programmablaufpläne
Die Aufgaben der Programme lassen sich in drei Bereiche aufteilen:
•
Verbindungsaufbau (vgl. Abbildung 4-3)
•
Text von Server/Client an Client/Server senden (vgl. Abbildungen 4-4
und 4-5)
•
Text von Client bzw. Server empfangen (vgl. Abbildungen 4-4 und 4-5)
Zur Umsetzung dieser Aufgaben wird insbesondere das Winsock – Objekt (siehe
Kapitel 3.2) benutzt.
28
In den folgenden drei Programmablaufplänen wird der Einsatz des Winsock –
Objektes, seiner Eigenschaften, seiner Ereignisse und seiner Methoden
dargestellt.
4.1.2.1 Verbindungsaufbau
In diesem Programmablaufplan (vgl. Abbildung 4-3) ist der Verbindungsaufbau
zwischen den beiden Programmen dargestellt, sowie die Ausgaben in den
jeweiligen Textausgabefeldern SrvEtxt und CltEtxt.
Programmablaufplan
Client – Seite (PC2)
Server – Seite (PC1)
Server-Programm starten
Form_Load()
¾ Winsock.LocalPort = „85“
Verbindungsaufbau
¾ WinSock.Listen
¾ SrvEtxt.Text = „Winsock initialiert“
¾ SrvEtxt.SelStart = Len(SrvEtxt.Text)
Client-Programm starten
Form_Load()
¾ Winsock.RemoteHost =
„192.168.1.10“
¾ WinSock.RemotePort = „85“
¾ Wincok.Connect
¾ CltEtxt.Text = „Winsock initialisiert
Winsock_ConnectionRequest(ByVal
request ID as Long)
¾ Winsock.Close
Winsock_Connect()
¾ WinSock.Accept requestID
¾ CltEtxt.Text = CltEtxt.Text & vbCrlf
& „Client verbunden mit Server“
Legende
- Eigenschaften - Ereignisse - Methoden
Abbildung 4-3: Verbindungsaufbau-Programmablaufplan
29
4.1.2.2 Textversand von Server an Client
In diesem Programmablaufplan (siehe Abbildung 4-4) ist das Senden von Text
vom Serverprogramm zum Clientprogramm dargestellt, sowie die Ausgaben in
den jeweiligen Textausgabefeldern SrvEtxt und CltEtxt.
Programmablaufplan
Text von Server an Client senden
Text im Eingabefenster eingeben
und auf „senden“ drücken
SrvSenden_Click()
¾ if Winsock.State <> 0 And
Winsock.Stat <> 2 then
¾ SrvEtxt.text = SrvEtxt &
vbCrlf & „Server:“ &
SrvStxt.Text
¾SrvEtxt.SelStart = Len
(SrvEtxt.Text)
Winsock_DataArrival (ByVal
bytesTotal as Long)
¾ Dim Daten as String
¾WinSock.SendData
SrvStxt.Text
¾SrvStxt.Text = „“
¾ Winsock.GetData Daten
¾ CltEtxt.Text = CltEtxt.Text & vbCrlf
& „Server (“ & Winsock.RemoteHost &
„) : & Daten
¾ CltEtxt.SelStart = Len(CltEtxt.Text)
Legende
Abbildung 4-4: Datenaustausch-Programmablaufplan (ServerÆ Client)
30
4.1.2.3 Textversand von Client an Server
In diesem Programmablaufplan (siehe Abbildung 4-5) ist das Senden von Text
vom Clientprogramm zum Serverprogramm dargestellt, sowie die Ausgaben in
den jeweiligen Textausgabefeldern SrvEtxt und CltEtxt.
Programmablaufplan
Text von Client an Server senden
Text im Eingabefenster eingeben
und auf „senden“ drücken
CltSenden_Click()
¾ if Winsock.State <> 0 And
Winsock.State <> 2 then
¾ CltEtxt.text = CltEtxt & vbCrlf
& „Client:“ & CltStxt.Text
¾CltEtxt.SelStart = Len
(CltEtxt.Text)
¾WinSock.SendData
CltStxt.Text
Winsock_DataArrival (ByVal
bytesTotal as Long)
¾CltStxt.Text = „“
¾ Dim Daten as String
¾ Winsock.GetData Daten
¾ SrvEtxt.Text = SrvEtxt.Text & vbCrlf
& „Client (“ & Winsock.RemoteHostIP
& „) : & Daten
¾ SrvEtxt.SelStart = Len(SrvEtxt.Text)
Legende
Abbildung 4-5: Datenaustausch-Programmablaufplan (Client Æ Server)
4.1.3 Der Quellcode
In diesem Kapitel sind die Quellcodes der beiden Programme kommentiert
dargestellt. (vgl. Abbildungen 4-6 und 4-7)
Bei der Programmierung der Bedienoberflächenformulare ist darauf zu achten,
dass man in diese das Winsock-Steuerelement einbettet. Zu finden ist das
Steuerelement im Menü Æ Projekt Æ Komponenten Æ Register „Steuerelement“.
31
In diesem Register „Microsoft Winsock Control 6.0“ auswählen und mit OK
bestätigen. Im nächsten Schritt muss das Winsock-Icon, welches nun in der
Steuerelement-Toolbox zu finden ist, auf das Formular per „Drag & Drop“ gezogen
werden.
Abbildung 4-6: Kommentierter Quellcode des Server-Programms
In der Abbildung 4-6 ist der Quellcode des Serverprogrammes dargestellt. Die
Kommentare der einzelnen Befehle sind in grüner Schrift.
32
Abbildung 4-7: Kommentierter Quellcode des Client-Programms
In der Abbildung 4-7 ist der Quellcode des Clientprogrammes dargestellt. Die
Kommentare der einzelnen Befehle sind in grüner Schrift.
33
4.2 Die Protokollanalyse mit „Ethereal“
Der zweite Teil der Aufgabenstellung ist die Analyse des Datenverkehres beim
Senden eines Textes.
Dazu wird auf dem PC2 das Programm Ethereal („The Ethereal Network
Analyzer“) installiert. Mit Hilfe dieses Programms kann der Verkehr auf dem
Netzwerk aufgezeichnet und anschließend betrachtet werden.
Für das Aufbauen der Verbindung zwischen den beiden Programmen bzw. PC´s
und das Senden des Textes „hallo fabian“ ist in den Abbildungen 4-8 bis 4-12 der
Datenverkehr auf dem Netzwerk dargestellt
Abbildung 4-8: TCP-Einrichtungsphase, Synchronisationsaufforderung
In Abbildung 4-8 ist der Beginn der Einrichtungsphase (vgl. Kapitel 3.1.2.1)
dargestellt. Diese wird durch den Programmstart des Clients begonnen. Der Client
34
sendet dabei ein TCP-Segment in dem das SYN-Flag gesetzt und das ACK-Flag
nicht gesetzt ist.
Abbildung 4-9: TCP-Einrichtungsphase, Synchronisationsantwort
In Abbildung 4-9 ist Antwort des Serverprogramms auf die
Synchronisationsaufforderung des Clientprogramms dargestellt. Hierbei antwortet
der Server mit einem TCP-Segment in dem das SYN- und das ACK-Flag gesetzt
sind. (vgl. Kapitel 3.1.2.1)
In Abbildung 4-10 ist die Bestätigung des soeben erhaltenen TCP-Segments
dargestellt. Zur Bestätigung ist in diesem TCP-Segment das ACK-Flag gesetzt.
Damit ist die TCP-Verbindung eingerichtet und die Synchronisation
abgeschlossen. (vgl. Kapitel 3.1.2.1)
35
Abbildung 4-10: TCP-Einrichtungsphase, Synchronisationsbestätigung
Abbildung 4-11: TCP-Datenaustauschphase, Datenversand mit Bestätigungsaufforderung
In Abbildung 4-11 ist der Beginn der Datenaustauschphase dargestellt. Der Client
sendet das TCP-Segment mit den Daten zum Server und erwartet dann eine
Empfangsbestätigung des Servers (vgl. Abbildung 4-12). Die Daten (hier: der Text
36
„hallo fabian“) sind in der Abbildung 4-11 rot unterstrichen. Der Datenblock ist 12
Bytes groß (11 Buchstaben und eine Leerzeichen) und, wie in der linken Seite der
Abbildung zu sehen, hexadezimal dargestellt.
Abbildung 4-12: TCP-Datenaustauschphase, Empfangsbestätigung
In Abbildung 4-12 ist das TCP-Segment mit der Empfangsbestätigung des Servers
dargestellt. Hat der Client dieses TCP-Segment empfangen, ist die
Datenübertragung abgeschlossen. (vgl. Kapitel 3.1.2.1)
37
Literaturhinweise
[1]
Daniel Baulig:
ISO OSI Referenzmodell
http://ip-web.hn.org/osi-referat/
(eingesehen am 08.12.2003)
[2]
N.N.
Das ISO/OSI Refernmodell
www.fh-wedel.de
[3]
N.N.
Schichtenmodelle
http://www.tecchannel.de/tecspecial1/artikel/so_funktioniert_tcp_ip/0.html
[4]
N.N.
Siemens AG Lexikon
www.siemens.de
[5]
N.N.
VB – Magazin: Der Anfänger-Guide zu Visual Basic
http://www.vb-magazin.de/new/contentid-66.html
[6]
N.N.
VB – Magazin: Der Anfänger-Guide zu Visual Basic
http://www.vb-magazin.de/new/contentid-69.html
[7]
Volker Schüppel
Entwicklung einer Client-/Server-Applikation zum Informationsaustausch
von Systemdaten zwischen entfernten Systemen, 1999
RVHR-Universität Bochum, Diplomarbeit
http://www.etdv.ruhr-uni-bochum.de/dv/diplomarbeiten/d341/d341.pdf
38
[8]
Heiko Holtkamp
Einführung in TCP/IP
Technische Fakultät, Universität Bielefeld
http://www.rvs.uni-bielefeld.de/~heiko/tcpip/kap_2_3.html#ip

Senden von TCP/IP-Telegrammen aus einem Visual Basic

Transcription

Documents pareils

Welche Ports werden von der Hardware

Internet

Unterstützung von Microsoft Visual Studio 2005

Systemvoraussetzungen - abacus edv

Visual Kei - transcript Verlag

Burren Niklaus: Hardwaresimulation für Softwaretests

Microsofts .NET-Technologie – wohin geht die

Protokoll zum Webquest "Holidays in Great Britain"