Na, wie geht’s uns denn so? (Clients and Servers.)

Ingo hat bei sich den Moodbear vorgestellt, mit dem man nonverbal seine Stimmung nach außen signalisieren kann, falls Mimik und Körperhaltung dazu nicht ausreichen. So etwas ähnliches hat ein unterbeschäftigter Informatik-Oberstufenschüler (leider nicht an meiner Schule) entworfen. Es handelt sich dabei um zwei Python-Skripte. Eines davon ist der Client: der schickt Anfragen oder Nachrichten an einen Server, der diese dann der Reihe nach abarbeitet und eventuell Informationen zurückmeldet. In der Regel kommen auf einen Server viele Clients, die unabhängig von einander mit dem Server kommunizieren.

Im Computerraum startet man auf jedem Schülerrechner den Client. Dann taucht zum Beispiel rechts unten am Bildschirm dieses Fensterchen auf:

Text und Farbe und Anzahl der Buttons und deren Beschriftung kann man natürlich verändern. Der Schüler drückt, sagen wir, den grünen Knopf, wenn es ihm gut geht, den gelben, wenn er sich langweilt und den roten, wenn er sich ärgert.

Auf dem Rechner des Lehrers startet man den Server. Das sieht dann so aus:

Man sieht die zuvor gestellte Frage und die Gesamtzahl der Antworten, also wie viele Schüler sich für welchen Knopf entschieden haben. Das kann man für Abstimmungen benutzen oder dafür, welche Stimmung gerade in der Klasse herrscht, oder um zu sehen, wie viele Schüler gerade an welcher Aufgabe arbeiten oder mit welcher Teilaufgabe bereits fertig sind. Wenn sich Schüler umentscheiden, werden die neuen Zahlen sofort beim Lehrer angezeigt.

(Ist in Python geschrieben, das bei uns im Computerraum installiert ist. Könnte man so ähnlich auch in Java machen.)

– Diese Client-Server-Struktur ist Stoff in der Q12 in Informatik. Man findet sie zum Beispiel bei Anfragen an einen Webserver, wo ein Client (ein Webbrowser) über ein bestimmtes Protokoll (etwa http oder https) Anfragen an einen Webserver schickt, der daraufhin damit reagiert, dass er den HTML-Text der angeforderten Seite zurückschickt.

Dazu müssen sich Client und Server erstens über eine gemeinsame Sprache einig sein, also darauf, welche Art Anfrage des Clients welche Reaktion des Servers nach sich ziehen soll. Diese Sprachen heißen Protokolle. Nach dem hypertext transfer protocol (http) sieht eine Anfrage an den Server zum Beispiel so aus:

GET /wordpress/ HTTP/1.1
Host: www.herr-rau.de
<Leerzeile>

Da hilft es nichts, wenn man stattdessen sendet “Dear www.herr-rau.de, please send me: /wordpress/”. Wenn man die falsche Sprache – das falsche Protokoll – benutzt, versteht der Server nur Bahnhof. Als Benutzer muss man diese Zeilen eigentlich nie eingeben, die Verbindungsaufnahme und das Versenden der http-Nachricht übernimmt der Browser für einen. Man kann aber, wenn man möchte, auch in einem Terminal zuerst eine Telnet-Verbindung zum Webserver aufbauen und dann von Hand die http-Anfragen stellen.

– Auch das Programm von oben benutzt ein Protokoll. Wenn der Client dem Server eine Nachricht schickt, muss das in einer bestimmten Form geschehen, damit der Server weiß, was damit gemeint ist. Nur ist dieses Protokoll halt nicht standardisiert, sondern vom Softwareentwickler für seinen Zweck angelegt.

Zweitens muss der Client die Adresse des Servers kennen. Die besteht aus der IP-Adresse des Rechners, auf dem das Serverprogramm läuft. Da man die IP-Adresse in der Regel nicht auswendig weiß, gibt man stattdessen die Web-Adresse des Rechners an, also www.herr-rau.de, und dann wird automatisch in einem Internet-Telefonbuch (DNS) gesucht, welche IP-Adresse zu diesem Namen gehört. (Siehe: Die Maus erklärt das Internet.)
So ein Rechner hat in der Regel mehrere Kanäle, auf denen er nach Anfragen der verschiedenene Art lauscht. Diese Kanäle heißen ports, einige davon sind standardisiert. An Port 80 sendet man zum Beispiel standardmäßig http-Anfragen, und auf Port 80 lauscht ein Webserver nach eben diesen Anfragen, um sie zu beantworten. Kommen mehr Anfragen, als der Server nach und nach beantworten kann, dann ist der überlastet und kann nicht mehr reagieren. Als Angriff auf einen Server heißt das dann DoS-Angriff – denial of service, wenn der Server mit so vielen Anfragen bombardiert wird, dass er kapituliert.

Damit Client A eine http-Anfrage an Server B stellen kann, muss vorher eine Verbindung zwischen Rechner A und Rechner B hergestellt worden sein. Diese Verbindung kann man sich vorstellen wie ein langes Kabel, das – zugegeben, vermittelt durch viele Zwischenstationen – zwischen A und B gespannt ist. Diese Verbindung wird nach dem Protokoll TCP (transmission control protocol) aufgebaut.
Es gibt noch ein weiteres Protokoll, mit dem Client A mit Server B in Kontakt treten kann, das Protokoll UDP. Dieses Protokoll ist verbindunglos und eher einem Brief vergleichbar, den man aufgibt und von dem man hofft, dass er schon ankommen wird. Tut er auch meist, aber bei UDP kann es sein, das zwischendrin ein paar Teile verlorengehen, anders als bei TCP. Bei Echtzeit-Videoübertragungen macht es vielleicht weniger aus, wenn zwischendurch ein paar Bilder fehlen, als dass der Video hängt, weil man auf den nächsten Teil wartet.
Anfragen mit http sind übrigens nur möglich, wenn vorher eine Verbindung hergestellt wurde, also über TCP. Andere Anfragen können auch über UDP laufen.

– Auch die Clients des Programms von oben brauchen die IP-Adresse des Servers. Allerdings geschieht hier die Kommunikation diesseits des Routers, der all diese Rechner mit dem Internet verbindet. Das sind dann lokale IP-Adressen, die nur auf dieser Seite des Routers gelten, und die vom Router vergeben werden – entweder wechselnd oder fest. Die Welt draußen kennt nur die von der Telekommunikationsgesellschaft zugewiesene und häufig wechselnde IP-Adresse des Routers; innerhalb des Router-Heimnetzes hat dann jeder Rechner seine eigene lokale IP-Adresse, meist 192.168.0.xxx oder 192.168.2.xxx oder so ähnlich.
Diese LAN-interne IP-Adresse gibt man bei dem Programm in eine Konfigurationsdatei ein, ebenso den gewünschten Port. Das sollte irgendeiner sein, der nicht standardmäßig einem bestimmten Protokoll zugewiesen ist.

Und leider, leider funktioniert das Programm bei uns an der Schule nicht. Genauer: die Rechner können keinen Kontakt zwischen einander herstellen, obwohl die IP-Adresse korrekt ist und ich einen geeigneten Port eingegeben habe. Das habe ich in der Q12 mit einem selbst geschriebenen Java-Chatserver auch schon gemerkt. Weder TCP noch UDP funktionieren; ich vermute, dass der Router einfach keinen Nachrichtenaustausch zwischen den einzelnen Rechnern erlaubt, sondern nur zwischen dem Rechner und dem gemeinsamen Fileserver. Der Systembetreuer weiß schon Bescheid, er will sich darum kümmern. (Ich halte es für kein ernst zu nehmendes Problem, dass findige Schüler dann ihre eigene Client-Server-Struktur aufbauen und mittels kleiner Java-Programme miteinander während des Unterrichts Verbindung aufnehmen könnten.)

3 Antworten auf „Na, wie geht’s uns denn so? (Clients and Servers.)“

  1. Das ist eine schöne Aufgabe für ein Projekt in der zwölften Klasse. Das mit der fehlenden Kommunikation im Schulnetzwerk kenne ich auch. Ein Schüler von mir hat es bei sich zu Hause ans Laufen gebracht, in dem er die Ports auch in der Windows-Firewall freigegeben hat. Die sind bei unserem Schulnetzwerk nämlich standardmäßig alle zu.
    Den Chatserver bringe ich in der Schule daher immer nur lokal ans laufen. Ich öffne das Server-BlueJ-Projekt und das Client-BlueJ-Projekt in zwei Instanzen von BlueJ. Damit stören sie sich nicht und laufen in verschiedenen Virtualmachines – denke ich. Das klappt dann immerhin so weit, dass auf einem Computer gechattet werden kann.

  2. Ja, zu Hause im LAN/WLAN funktionieren der Chatserver und das Stimmungsbarometer ganz wunderbar. Und auf einem einzelnen Rechner auch in der Schule. Beides brauche ich in der Realität eben weniger.

    Die Buttons kann man ja noch mit Text bestücken. Theoretiker streiten sich ja darüber, ob die Anzahl der Optionen unbedingt ungerade sein muss, oder unbedingt gerade sein muss – ich lese beides. Das Lila könnte dann stehen für: Können wir draußen Unterricht machen?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.