Home » Tutorials » Netzwerk und Internet » Sockets mit WinAPI

Sockets mit WinAPI

Programm für Sockets präparieren

Was ist ein Socket

 

Wer das Wort Socket vor dem ersten Kapitel schon mal gehört hat, kann diesen Punkt getrost überspringen.
Und für die anderen machen wir es uns mal einfach. Ein Socket ist etwas ganz tolles. Und das allerbeste daran ist, es wird von Windows verwaltet und wir brauchen eigentlich gar nichts weiter zu wissen darüber, außer dessen Nummer. Und wie bei allem in der WinAPI ist diese Nummer ein Handle auf ein Objekt, welches Socket heißt. Wir können es auch einen Socket Descriptor nennen, der auf einen Transmission Control Block (TCB) zeigt. Aber, wie gesagt, dass ist alles vom Betriebssystem bereitgestellt. Wir wollen da gar nicht zu viel drüber wissen. Wir nennen es einfach unser Socket. Davon kann man an einem Rechner und auch innerhalb einer Anwendung mehrere haben. Und jetzt schauen wir noch mal ein klein wenig hinein, was es in so einem Socket (also im TCB) gibt.
Wir stellen uns so ein Socket einfach mal als großen Container vor. Der Container hat zwei große Teile, die wir ab jetzt Buffer nennen, und da können Daten liegen. Standardmäßig ist unter Windows so ein Buffer 8 KByte groß. Neben den beiden Buffern gibt es noch einen Zettel mit ein paar weiteren Informationen.In dem einen Buffer liegen ausgehende Daten und in dem anderen eingehende Daten. Unser Socket ist demnach Vollduplex fähig.
Den Container stellen wir uns ähnlich vor, wie ein Postfach. Da werden alle eingehenden Nachrichten gesammelt und irgendwann gehen wir mal vorbei und holen das Zeug ab. Das können wir regelmäßig machen (Polling-Modus) oder wir lassen uns von der Post, also vom Socket, anrufen wenn noch etwas im Postfach liegt. Und dann holt man eben soviel ab, wie man tragen kann. Es ist kein Problem mehrmals zu laufen. Wir können uns natürlich auch bei der Post hinstellen und einfach warten, aber in dieser Zeit können wir auch nichts anderes tun. Das Programm würde hängen.
Neben dem Container beinhaltet unser Socket je nach Sockettyp auch noch folgende Informationen (Der Zettel am Container):

• Local IP Address
• Local Port
• Remote IP Address
• Remote Port
• Sockettyp
• Und je nach Sockettyp und Protokoll weitere Informationen

Soviel erstmal zum Inhalt des Sockets. Und was können wir jetzt damit anstellen? Na wir können ihm eine Adresse geben, sodass das Socket Daten senden und empfangen kann. Das war’s dann auch schon. Jetzt können wir auf Post warten oder eben selber welche verschicken.

Die eigentlichen Programmvorbereitungen

Bevor wir überhaupt mit Sockets arbeiten können, müssen wir Windows erstmal veranlassen uns die nötigen Funktionen samt DLL zur Verfügung zu stellen. Windows interessiert dabei vor allem, welche Version der Windows Sockets DLL wir gerne hätten. Und Delphi interessiert sich erstmal dafür, dass wir Windows Sockets überhaupt verwenden. Also binden wir die Unit WinSock ein:

uses winsock;

Nachdem nun Delphi Bescheid weis, können wir auch Windows Bescheid geben. Der Befehl dazu lautet WSAStartup. Übergeben werden zwei Parameter. Zum einen die von uns verlangte Versionsnummer als Word und zum anderen ein Record, der schließlich die verwendete Version zurückliefert. Zudem beinhaltet das Record noch weitere Informationen, die uns aber nicht weiter interessieren. Ab Version 2.0 der Sockets DLL werden diese weiteren Informationen auch größtenteils nicht mehr verwendet. Günstigerweise legt man das WSAStartup in den initialization Teil einer entsprechenden Unit.

procedure InitSockets;
var Data: WSAData;
begin
  WSAStartup( MakeWord(1,1), Data);  //Das wäre dann Version 1.1
end;

...

initialization

  Initsockets;

Die Version 1.1. ist die häufigste Variante die ich in Beispielcode gefunden habe (wahrscheinlich weil alle voneinander abschreiben). Auch wenn es die Version 2.0 (und 2.2) gibt, reicht uns die 1.1 für unsere Belange aus. Auch Delphi (in Delphi 7) verwendet diese Version. Grundlegend kann man sich merken, dass wir immer die Version bekommen, die wir anfordern, solange es diese oder eine höhere Version gibt. Ansonsten wird ein Fehler ausgelöst (nächstes Kapitel). Wer möchte, kann sich das WSAData-Record auch hinterher noch ansehen. Wir gehen jetzt einfach davon aus, dass jeder Rechner unseren Anforderungen genügt.
Am Ende des Programms (oder eben, wenn wir keine Sockets mehr benötigen) müssen wir dann Windows sagen, dass es wieder alles aufräumen kann:

finalization
  WSACleanup;

Ein Befehl, keine Parameter. Dieser würde analog zu WSAStartup in den finalization Teil passen. Wir müssen dabei darauf achten, dass für jeden erfolgreichen Aufruf von WSAStartup, auch ein WSACleanup erfolgen muss. Ohne den Aufruf von WSAStartup würde jeder Socket-Befehl einen WSANOTINITIALISED-Fehler auslösen.

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11