Ins Netz gegangen

9. Februar 2007, 10:42 Uhr |
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Ins Netz gegangen

Die LPC2300-Bausteine besitzen eine spezielle DMA nur für die Ethernetschnittstelle. Diese DMA hilft dabei, die Datenpakete nach Empfang wieder korrekt zusammenzusetzen, denn es ist nicht immer gewährleistet, dass Datenpakete in derselben Reihenfolge beim Empfänger ankommen wie sie gesendet werden. Außerdem könnten auch mehrere unabhängige Datenströme parallel empfangen werden. Der »Transport Layer« ist für den Datentransfer zwischen den beiden Hosts zuständig. Sehr häufig wird auf diesem Layer das TCP (Transmission Control Protocol) angewendet. Mit diesem Protokoll ist eine zuverlässige Datenübertragung zwischen den Hosts garantiert. Dieser Teil des Protokolls verwaltet die Datenpakete und prüft, ob sie in einer vorgegebenen Zeit übertragen wurden. Falls nicht, wird ein nochmaliges Übertragen angefordert. Zusätzlich wird das Datenpaket an einen spezifischen Port übertragen. Die Adresse des Ports ist eine Zahl im 16-Bit-Format. Einige dieser Portadressen sind spezifischen Funktionen vorab zugeordnet, andere Ports werden dynamisch zugeordnet, während die Hosts die Kommunikation untereinander aufbauen. In dem MCB2370-Evaluationboard ist die TCP-Protokollsoftware mittels des TCP/IPStacks von NichLite implementiert.

Der »Application Layer« ist die höchste Ebene. Hier kommunizieren Prozesse eines Hosts mit denen des anderen Hosts. Ein Beispiel für eine solche Anwendung ist ein Webserver. Ein Webserver benützt HTTP, um Daten von einem Webserver zu dem Browser auf einem anderen Computer in Form von HTML oder JavaScript zu übertragen. Die Webserver- Anwendung kommuniziert also mit der Browseranwendung mit Hilfe eines API (Application Programming Interface). Die meisten APIs bauen auf dem BSD-Socket auf.

 Diese Berkeley-Sockets-API stellt eine Sammlung von Unterprogrammen zur Verfügung, die eine Anwendung dazu benützen kann, mit anderen Computern über ein Netzwerk unter Nutzung des TCP/IP-Stacks zu kommunizieren. In Bild 3 ist eine vereinfachte Darstellung des BSD-API zu sehen. Das Diagramm zeigt beide Seiten einer Client-Server- Verbindung. Ein typischer zeitlicher Ablauf sieht wie folgt aus:

  • Der Server ruft »socket()« auf, um eine Datenstruktur zu erzeugen, die Informationen über die Verbindung enthält.
  • Dann wird »bind()« aufgerufen, womit der Server eine Verbindung zwischen sich selbst und einer speziellen Socket-IPAdresse und einem Port herstellt.
  • Zuletzt ruft der Server »listen()« auf und wartet dann, welche Anforderungen vom Client zurückkommen.
  • Jetzt fordert der Client Daten vom Server an. Dazu ruft er seinerseits »socket()« auf, um wiederum auf seiner Seite eine Datenstruktur zu erzeugen.
  • Danach kommt ein Aufruf von »connect()«, um eine Verbindung zum Server zu erhalten.
  • Als nächstes ist der Server wieder in der Pflicht und ruft »accept()« auf, um die Verbindung anzunehmen.
  • Über die bestehende Verbindung sendet der Client jetzt einen Datenblock »send()« an den Server. ? Falls der Client Daten von einem http-Server anfordert, enthält der Datensatz eine http-GET-Anforderung. Der Server quittiert die Anforderung entsprechend.
  • Der Client ruft »recv()« für den Empfang auf, und nach Empfang der Daten rufen beide Seiten »close()« auf, um die Verbindung zu beenden.

Bild03__02.gif
Bild 3: Das Berkeley-Sockets-API

<< vorherige Seite1 | 23nächste Seite >>


  1. Ins Netz gegangen
  2. TCP/IP und die LPC2300-Familie
  3. Ins Netz gegangen

Jetzt kostenfreie Newsletter bestellen!