17.8 Client/Server-Kommunikation

Bevor wir weitere Dienste untersuchen, wollen wir einen kleinen Server programmieren. Server bauen keine eigene Verbindung auf, sondern horchen an ihrem zugewiesenen Port auf Eingaben und Anfragen. Ein Server wird durch die Klasse ServerSocket repräsentiert. Der Konstruktor bekommt einfach die Port-Nummer, zu der sich Clients verbinden können, als Argument übergeben.

ServerSocket serverSocket = new ServerSocket( 1234 );

Natürlich müssen wir unserem Client eine noch nicht zugewiesene Port-Adresse zuteilen, andernfalls ist uns eine IOException sicher. Damit der eigene Java-Server nicht mit einem anderen Server in Konflikt gerät, sollten wir einen Blick auf die aktuell laufenden Dienste werfen. Unter Windows listet auf der Kommandozeile netstat -a die laufenden Serverdienste und die belegten Ports auf. Bei Unix-Systemen können nur Root-Besitzer Ports unter 1024 nutzen. Unter dem herkömmlichen Windows ist das egal. Läuft ein Server unendlich, so muss darauf geachtet werden, eine alte Instanz erst zu beenden, damit er neu gestartet werden kann.

17.8.1 Warten auf Verbindungen

Nachdem der Socket eingerichtet ist, kann er auf hereinkommende Meldungen reagieren. Mit der blockierenden Methode accept() der ServerSocket-Klasse nehmen wir genau eine wartende Verbindung an:

Socket server = serverSocket.accept();

Nun können wir mit dem zurückgegebenen Client-Socket genauso verfahren wie mit dem schon programmierten Client. Das heißt: Wir öffnen Ein- und Ausgabekanäle und kommunizieren. In der Regel wird ein Thread den Client-Socket annehmen, damit der Server schnell wieder verfügbar ist und neue Verbindungen annehmen und verarbeiten kann.

Wichtig bleibt zu bemerken, dass die Konversation nicht über den Server-Socket selbst läuft. Dieser ist immer noch aktiv und horcht auf eingehende Anfragen. Die accept()-Methode sitzt daher oft in einer Endlosschleife und erzeugt für jeden Hörer einen Thread. Die Schritte, die also jeder Server vollzieht, sind folgende:

Der Server wartet auch nicht ewig

Soll der Server nur eine gewisse Zeit auf einkommende Nachrichten warten, so lässt sich ein Timeout einstellen. Dazu ist der Methode setSoTimeout() die Anzahl der Millisekunden zu übergeben. Nimmt der Server dann keine Fragen entgegen, bricht die Verarbeitung mit einer InterruptedIOException ab. Diese Exception gilt für alle Ein- und Ausgabe-Operationen und ist daher auch eine Ausnahme, die nicht im Net-Paket, sondern im IO-Paket deklariert ist.

ServerSocket server = new ServerSocket( port ); 
// Timeout nach 1 Minute 
server.setSoTimeout( 60000 ); 
try { 
  Socket socket = server.accept(); 
} catch ( InterruptedIOException e ) { 
  System.err.println( "Timeout after one minute" ); 
}

17.8.2 Ein Multiplikationsserver

Der erste Server, den wir programmieren wollen, soll zwei Zahlen im Wertebereich eines Bytes (-128 bis +127) multiplizieren. Nach dem Aufbau eines ServerSocket-Objekts soll der Server mit accept() auf einen interessierten Client warten. Nach der akzeptierten Verbindung soll handleConnection() das Protokoll und die Logik übernehmen: im Eingabestrom werden zwei Zahlen erwartet, die multipliziert zurückzuschreiben sind.

Listing 17.12 com/tutego/insel/net/MulServer.java

package com.tutego.insel.net; 
 
import java.io.*; 
import java.net.*; 
 
public class MulServer 
{ 
  private static void handleConnection( Socket client ) throws IOException 
  { 
    InputStream  in  = client.getInputStream(); 
    OutputStream out = client.getOutputStream(); 
 
    int factor1 = in.read(); 
    int factor2 = in.read(); 
 
    out.write( factor1 * factor2 ); 
  } 
 
  public static void main( String[] args ) throws IOException 
  { 
    ServerSocket server = new ServerSocket( 3141 ); 
 
    while ( true ) 
    { 
      Socket client = null; 
 
      try 
      { 
        client = server.accept(); 
        handleConnection ( client ); 
      } 
      catch ( IOException e ) { 
        e.printStackTrace(); 
      } 
      finally { 
        if ( client != null ) 
          try { client.close(); } catch ( IOException e ) { } 
      } 
    } 
  } 
}

Kommt es zu einem Verbindungsaufbau, erfragt der Server den Client und die Kommunikationsströme. Über den Eingabestrom werden zwei byte erwartet; die blockierende read()-Methode übernimmt diese Aufgabe. Kommen die Bytes nicht an, wartet der Server ewig auf seine Daten und ist unterdessen blockiert, da er in dieser Implementierung nur einen Client bedient. Bekommt er die beiden Bytes, multipliziert er sie und sendet das Ergebnis zurück. Nach dem Senden ist das Protokoll beendet, und die Verbindung zum Client kann unterbrochen werden. Durch die Endlosschleife ist der Server bereit für neue Anfragen.

Auf der anderen Seite steht der Client, der aktiv eine Verbindung zum Server aufbaut. Er nutzt ein mit Internet-Adresse und Port initialisiertes Socket-Objekt, um den ein- und ausgehenden Datenstrom zu erfragen und zwei Bytes zu übertragen. Das Ergebnis sammelt er ein und gibt es auf dem Bildschirm aus. Nach der Kommunikation wird die Verbindung geschlossen, um die nötigen Ressourcen wieder freizugeben.

Listing 17.13 com/tutego/insel/net/MulClient.java

package com.tutego.insel.net; 
 
import java.net.*; 
import java.io.*; 
 
class MulClient 
{ 
  public static void main( String[] args ) 
  { 
    Socket server = null; 
 
    try 
    { 
      server = new Socket( "localhost", 3141 ); 
      InputStream  in  = server.getInputStream(); 
      OutputStream out = server.getOutputStream(); 
 
      out.write( 4 ); 
      out.write( 9 ); 
      int result = in.read(); 
      System.out.println( result ); 
    } 
    catch ( UnknownHostException e ) { 
      e.printStackTrace(); 
    } 
    catch ( IOException e ) { 
      e.printStackTrace(); 
    } 
    finally 
    { 
      if ( server != null ) 
 
 
        try { server.close(); } catch ( IOException e ) { } 
    } 
  } 
}

Erweiterung der Ströme

Natürlich ist der Server in der Funktionalität beschränkt, da nur Bytes übertragen werden. So kann das Ergebnis nicht größer als 127 werden, da es sonst falsch übermittelt würde. Dennoch lässt sich das Programm leicht als Ausgangspunkt für einige Server erweitern. Ein erster Schritt wäre zum Beispiel die Aufwertung des einfachen InputStream/OutputStream zum DataInputStream/DataOutputStream.

In einer realistischen Client/Server-Anwendung mit Sockets würden immer gepufferte Ströme eingesetzt, um nicht laufend kleine Datenpakete zu senden. Werden jedoch Ströme wie BufferedInputStream oder BufferedOutputStream eingesetzt, sollten wir uns bewusst sein, dass die Informationen im Puffer zwischengespeichert und insofern nicht direkt zum anderen Rechner übertragen werden. In einem Frage-Antwort-Szenario muss der Server oder Client die Anfrage direkt übertragen und die Nachricht darf nicht im Puffer verweilen. Zu passenden Zeitpunkten müssen die flush()-Methoden der Puffer-Klassen die aufgenommenen Daten vermitteln, damit die Kommunikation weitergeht.

Erweiterung durch Multi-Threading

Ein anderer Punkt ist die Tatsache, dass Server im Allgemeinen multithreaded ausgelegt sind, damit sie mehrere Anfragen gleichzeitig ausführen können. Der Server erzeugt nicht pro Anfrage einen Thread – dies ist relativ teuer –, sondern nimmt die Threads aus einem Thread-Pool. Mit der Thread-Pool-Klasse aus der Java-Bibliothek lässt sich die Aufgabe vorzüglich bewältigen.

17.8.3 Blockierendes Lesen

Eine Eigenschaft ist bei der Server-Programmierung zu beachten: Erwartet der Client aus dem InputStream Daten, schickt der Server aber keine, dann blockiert die Funktion. Aus dieser Sackgasse gibt es zwei Auswege: das einfache Schließen des Sockets mit close() und der völlig unterschiedliche Ansatz mit NIO. Wenn der Socket geschlossen wird, werden alle Datenstrom-Operationen abgebrochen, und eine IOException wird ausgelöst.

Damit ist ein gutes Mittel gefunden, um wenigstens blockierte Socket-Verbindungen wieder zu befreien. Dies soll auch das nächste Beispiel demonstrieren. Zuerst wird ein nutzloser ServerSocket aufgebaut, der weder etwas annimmt noch etwas schickt. Der Client verbindet sich zum Server und versucht zu lesen. Da aber vom Server kein Zeichen gesendet wird, hängt read() und wartet auf ein Byte. All das läuft in einem Thread ab. Nach dem Start wird zwei Sekunden später der Socket geschlossen, was zum Abbruch von read() und in den Anweisungsblock der Exception-Behandlung führt.

Listing 17.14 com/tutego/insel/net/CloseConnection.java

package com.tutego.insel.net; 
 
import java.io.IOException; 
import java.net.*; 
 
public class CloseConnection 
{ 
  public static void main( String[] args ) throws Exception 
  { 
    new ServerSocket( 12345 );     // Server anmelden 
 
    final Socket t = new Socket( "localhost", 12345 ); 
 
    new Thread( new Runnable() 
    { 
      public void run() 
      { 
        try 
        { 
          System.out.println( "Gleich hängt er!" ); 
          System.out.println( t.getInputStream().read() ); 
          System.out.println( "Hier hängt er!" ); 
        } 
        catch ( IOException e ) 
        { 
          System.out.println( "Blockierung gelöst" ); 
        } 
      } 
    } ).start(); 
 
    Thread.sleep( 2000 ); 
 
    t.close();  // Löst die Blockierung 
  } 
}

Mit der Ausgabe

Gleich hängt er! 
Blockierung gelöst

17.8.4 Von außen erreichbar sein

Ein Server lässt sich nur auf dem eigenen Rechner starten. Ist der Rechner vom Internet aus erreichbar, können externe Rechner auf ihn zugreifen. Anders sieht es aus, wenn der Rechner eine Internet-Adresse hat, die von außen nicht sichtbar ist, weil er zum Beispiel über einen Router ins Internet geht. Dann vergibt dieser Router eine eigene Adresse – die oft mit 192.168 oder 10 beginnt – und setzt sie per NAT um, sodass unsere private Adresse außen verborgen bleibt. Die Frage ist nun, ob wir trotzdem einen Serverdienst anbieten können.

Diese Möglichkeit gibt es tatsächlich, wenn einige Randbedingungen gegeben sind: Zunächst muss unsere interne IP-Adresse relativ stabil sein – und unsere äußere IP-Adresse vom Router ins Internet ebenso. Dann muss auf dem Router eine Einstellung vorgenommen werden, damit wir auf bestimmten Ports von außen angesprochen werden können. Diese Einstellung sieht bei jedem Router anders aus, und in größeren Unternehmen wird der Sicherheitsverantwortliche dies nicht akzeptieren. Nach der entsprechenden Einstellung benötigen wir eine globale Adresse, die wir weitergeben können. Dies wird keine IP-Adresse sein, sondern ein Name, der über DNS aufgelöst wird. Das ist schon der Trick, weil der konstant bleibende Name mit immer unterschiedlichen IP-Adressen verbunden werden kann, was sich daran zeigt, dass wir zum Beispiel mit einem Einwahl-Router immer unterschiedliche IP-Adressen bekommen. Daher heißt diese Technik auch dynamisches DNS. Eine feste URL gibt es bei unterschiedlichen Anbietern oft auch unentgeltlich, zum Beispiel bei http://www.dyndns.com/. Nach dieser Anmeldung lässt sich ein Subname registrieren, sodass etwa unter meinserver. dyndns.com die IP-Adresse des Einwahl-Routers steht. Dieser leitet nach der entsprechenden Einstellung eine Anfrage an unseren Rechner mit unserem Java-Server weiter.

Ihr Kommentar