16.14 Datagram-Sockets

Neben den Stream-Sockets gibt es im java.net-Paket eine weitere Klasse, die auch den verbindungslosen Pakettransport erlaubt. Es handelt sich dabei um die Klasse DatagramSocket. Datagram-Sockets basieren auf dem User Datagram Protocol (UDP). Dies ist auf dem Internet-Protokoll aufgesetzt und erlaubt die ungesicherte Übertragung - es ist auf der Transportschicht des OSI-Modells (Schicht 4) angeordnet. Auch UDP erlaubt es einer Applikation, einen Service über einen Port zu kontaktieren. Genau wie TCP nutzt auch UDP verschiedene Port-Nummern, so dass mehrere Server unter unterschiedlichen Ports ihre Dienste anbieten können. Wichtig ist, dass UDP-Ports völlig eigenständig sind und mit TCP-Ports nichts gemeinsam haben. So kann ein Server-Socket für TCP am Port 4711 horchen und ein Datagram-Socket auch. Jedoch lässt sich für ein Programm nicht unbedingt jeder Port nutzen, da etwa das Unix-Betriebssystem einige Ports reserviert beziehungsweise wir nicht unter die 1024-Grenze kommen. Wir werden später ein Programm kennen lernen, welches freie Ports überprüft.

Die Datagram-Sockets benötigen im Gegensatz zu den Stream-Sockets keine feste Verbindung zum Server; jedes Datagramm wird einzeln verschickt und kann folglich auf verschiedenen Wegen und in verschiedener Reihenfolge am Client ankommen. So ist der Ausdruck »verbindungslos« zu verstehen. Die Datagramme sind von den anderen völlig unabhängig. Ist die Ordnung der Pakete relevant, muss über ein Zeitfeld dann die richtige Reihenfolge rekonstruiert werden.

Datagram-Sockets und Stream-Sockets im Vergleich

Stream-Sockets nutzen eine TCP/IP-Verbindung und die Fähigkeit, Daten in der richtigen Reihenfolge zu sortieren. Arbeiten wir also mit Stream-Sockets oder auch mit der URL-Klasse, so müssen wir uns um den Transport nicht kümmern. Wir werden also bei der Benutzung von Stream-Sockets von den unteren Netzwerkschichten getrennt, die die richtige Reihenfolge der Pakete garantieren. Datagram-Sockets nutzen ein anderes Protokoll: das UDP-Protokoll. Dabei wird nur ein einzelner Chunk - durch die Klasse DatagramPacket repräsentiert - übertragen, dessen Größe wir fast frei bestimmen können. Da jedoch UDP wie TCP das IP-Protokoll nutzt, ist die Größe eines Datagramms durch das Internet-Protokoll beschränkt und beträgt maximal 64 KB (65.535 Byte). Davon werden allerdings ein paar Byte für den Header benötigt, für Daten wie Sender- und Empfängeradresse und Port-Nummer. Eine Checksumme wie CRC ist nicht nötig. Ziehen wir die Bytes für den Header ab, beträgt der nutzbare Bereich 65.507 Byte. Mehr Daten können wir mit einer Übertragung nicht senden. Es ist somit unsere Aufgabe, größere Pakete zu zerteilen.

TCP würde diese Pakete dann wieder richtig zusammensetzen, doch UDP leistet dies nicht. Deswegen garantiert UDP auch nicht, dass die Reihenfolge der Pakete richtig ist. Da UDP nicht mit verlorenen Paketen umgehen kann, ist es nicht gewährleistet, dass alle Daten übertragen werden. Die Anwendung muss sich also selbst darum kümmern. Das hört sich jetzt alles mehr nach einem Nachteil als nach einem Vorteil an. Warum werden dann überhaupt Datagram-Sockets verwendet? Die Antwort ist einfach: Datagram-Sockets sind schnell. Da die Verbindung nicht verbindungsorientiert ist wie TCP/IP, lässt sich der Aufwand für die korrekte Reihenfolge und noch weitere Leistungen sparen. Verbindungslose Protokolle wie eben UDP bauen keine Verbindung zum Empfänger auf und senden dann die Daten, sondern sie senden einfach die Daten und lassen sie von den Zwischenstationen verteilen. UDP profitiert also davon, dass die Bestätigung der Antwort und die erlaubte Möglichkeit des Sendens nicht vereinbart werden. UDP sendet seine Pakete demnach einfach in den Raum, und es ist egal, ob sie ankommen oder nicht.

Da allerdings Pakete verloren gehen können, würden wir Datagram-Sockets nicht für große Daten verwenden. Für kleine, öfters übermittelte Daten eignet sich das Protokoll besser. Nehmen wir einmal an, ein Server sendet Börsendaten für die Interessenten. Dafür ist das UDP-Protokoll gut geeignet, denn die anfragenden Clients können auf ein Datenpaket vermutlich verzichten. Wir können davon ausgehen, dass der Server in regelmäßigen Abständen neue Pakete sendet. Hier geht also Geschwindigkeit vor Sicherheit. Bei einer Audio-Übertragung ist es beispielsweise besser, wenn das Paket verschwindet, als wenn das Paket erst zwei Minuten später ankommt und dann abgespielt wird. Das bedeutet, UDP kann überall dort eingesetzt werden, wo eine Empfangsbestätigung nicht relevant ist. Erhält ein Client innerhalb einer gewissen Zeit keine Antwort, so stellt er seine Anfrage einfach erneut. Wichtige Applikationen, die UDP nutzen, sind das Domain Name System (DNS), TFTP (Trivial File Transfer Protocol) und auch Suns Network Filesystem (NFS). NFS ist so ausgelegt, dass verloren gegangene Pakete wieder besorgt werden.

Welche Klasse für welche Übertragung verwenden?

Im Gegensatz zu TCP-Verbindungen gibt es bei UDP-Verbindungen kein Objekt wie Socket oder ServerSocket für Client und Server. Das liegt daran, dass es in UDP kein Konzept wie virtuelle Verbindungen gibt und die Adresse nicht im Socket gespeichert ist, sondern im Paket selbst. Die Dateneinheiten sind Datagramme, und nach einer Kommunikation wissen die Partner schon nichts mehr übereinander. Bei UPD verwenden beide die Klasse DatagramSocket, welche für eine eingehende und auch ausgehende Verbindung steht.

Tabelle 16.5 Welche Klasse wofür?

16.14.1 Die Klasse DatagramSocket

Damit wir später einmal ein Paket (durch die Klasse DatagramPacket repräsentiert) senden können, erzeugen wir zunächst ein DatagramSocket-Objekt. Dieses Objekt steht für einen Kommunikationspunkt auf unserer Rechnerseite. Im Konstruktor wird hier noch nicht die IP-Adresse des Empfängers eingegeben. Dies geschieht später durch DatagramPacket, da nur im Paket diese Informationen kodiert sind.

class java.net.DatagramSocket

DatagramSocket() throws SocketException

DatagramSocket( int port ) throws SocketException

DatagramSocket( int port, InetAddress laddr ) throws SocketException

DatagramSocket( SocketAddress bindaddr ) throws SocketException

Hier klicken, um das Bild zu Vergrößern

Häufig wird der erste Konstruktor für Client-Programme verwendet, die anderen beiden nutzt der Server. Der Unterschied in den Konstruktoren liegt darin, an welche Ports und Server die DatagramSocket-Objekte gebunden sind. Für den Client ist dies nicht so interessant, da er häufig als Absender einen beliebigen Port nutzen kann. Läuft ein Paket zum Server, kann dieser immer anhand der gespeicherten Adresse eine Rückantwort schicken. Wir werden das auch an den Beispielen sehen, wo wir erst ein leeres Paket als Anfrage schicken und dann den Server über uns informieren. Einen beliebigen Port nimmt der erste Konstruktor, denn der bedeutet, dass jeder Port zur Kommunikation in Richtung Server verwendet werden kann. Nur ein Client muss wissen, auf welchem Port ein Server seinen Dienst bereitstellt. Die Port-Adresse auf der Client-Seite festzusetzen, ist nur dann wichtig, wenn hinter einer Firewall operiert wird.

16.14.2 Datagramme und die Klasse DatagramPacket

Zum Senden und Empfangen wird in beiden Fällen die Klasse DatagramPacket benutzt. Hier sind zwei Fälle zu unterscheiden, die verschiedene Konstruktoren implementieren.

Ein Paket zum Empfang vorbereiten

Wenn wir Daten empfangen, dann müssen wir nur ein DatagramPacket-Objekt anlegen und den Speicherplatz angeben, an dem die Daten abgelegt werden sollen. Das Feld ist so etwas wie ein Platzhalter. Folgende Zeilen reichen für einen Server, der am Port des Duftes 4711 horcht:

Hier klicken, um das Bild zu Vergrößern

byte data[] = new Bytes[1024];
DatagramSocket socket = new DatagramSocket( 4711 );
DatagramPacket packet = new DatagramPacket( data, data.length );
socket.receive( packet );

16.14.3 Auf ein hereinkommendes Paket warten

Wenn wir empfangen wollen, müssen wir warten, bis ein Paket eintrifft. Das geschieht mit der DatagramSocket-Methode receive(DatagramPacket). Die Methode ist vergleichbar mit der accept()-Methode der Klasse ServerSocket, nur dass accept() ein Socket-Objekt zurückgibt und receive() die Daten in dem im Parameter übergebenen Objekt ablegt. Mit den Methoden getPort() und getAddress() können wir herausfinden, woher das Paket kam, wer also der Sender war. Mit getData() bekommen wir die Daten als Bytefeld, und getLength() liefert die Länge. Ist das empfangene Paket größer als unser Puffer, wird das Feld nur bis zur maximalen Größe gefüllt.

Das folgende Programm implementiert einen horchenden Server, der noch nicht auf Pakete antwortet. Es empfängt still und gibt die Informationen über das empfangene Paket aus.

Listing 16.18 UDPServer.java

import java.net.*;
public class UDPServer
{
  public static void main( String args[] )
  {
    try
    {
      DatagramSocket socket = new DatagramSocket( 4711 );
      DatagramPacket packet;
      while ( true )
      {
        // Auf Anfrage warten
        packet = new DatagramPacket( new byte[1024], 1024 );
        socket.receive( packet );
        // Empfänger auslesen
        InetAddress address = packet.getAddress();
        int         port    = packet.getPort();
        int         len     = packet.getLength();
        byte        data[]  = packet.getData();
        System.out.println( "Anfrage von " + address +
                            " vom Port " + port +
                            " Länge " + len +
                            "\n" + new String( data, 0, len ) );
      }
    }
    catch ( Exception e )
    {
      System.out.println( e );
    }
  }
}

16.14.4 Ein Paket zum Senden vorbereiten

Wenn wir ein Paket senden wollen, dann müssen wir einem DatagramPacket auch noch sagen, wohin die Reise geht, das heißt, der Port und die IP-Adresse des entfernten Rechners sind anzugeben. Der Empfänger wird durch ein InetAddress-Objekt repräsentiert, der Konstruktor ist leider nicht mit einem String-Objekt überladen, was sicherlich nützlich wäre. Es gibt aber einen speziellen Konstruktor, der die Inet-Adresse und den Port direkt entgegennimmt.

Folgende Zeilen erzeugen ein DatagramPacket-Objekt mit einem Bytefeld für den Empfänger und senden es gleich:

InetAddress ia;
ia = InetAddress.getByName( "www.reich-und-schoen-waere.toll" );
int port = 4711;
String s = "Wer andere links liegen lässt, steht rechts.";
byte data[] = s.getBytes();
packet = new DatagramPacket( data, data.length, ia, port );
DatagramSocket toSocket = new DatagramSocket();
toSocket.send( packet );

Zusätzlich zum Bytefeld geben wir noch die Anzahl der Bytes an, die gesendet werden sollen. Dies erinnert an C-Stil und ist eigentlich unnötig, da in Java das Bytefeld in der Länge abgefragt werden kann und hier fast immer data.length passt. Doch so sind wir etwas flexibler. Wenn wir Strings übermitteln, was häufig vorkommt, bietet sich getBytes() zur Umwandlung an. Eine andere Möglichkeit zur Umwandlung einer Zeichenkette in ein Bytefeld ist folgende:

String s = "Gebt einem Brandstifter nie euren Zündschlüssel."
byte data[] = new byte [ s.length() ];
s.getBytes( 0, data.length, data, 0 );

16.14.5 Methoden der Klasse DatagramPacket

Das DatagramPaket ist auch nachträglich veränderbar und kann mit Methoden angepasst und auch ausgelesen werden:

class java.net.DatagramSocket

InetAddress getAddress() Hier müssen wir unterscheiden, ob das Paket hereinkommend oder ausgehend ist. Für ein hereinkommendes DatagramPacket liefert die Methode die Adresse, von der das Paket kam. Für ein ausgehendes Paket liefert getAddress() die Adresse, an die das Paket geht.

public int getPort() Für ein hereinkommendes Paket liefert es die Port-Nummer vom Sender. Für ein ausgehendes Paket liefert getPort() den Port, an den das Datagram geht.

Das folgende Programm zeigt ein zu sendendes Paket, und wir können die abgelegten Informationen wieder auslesen.

Listing 16.19 DatagramPacketEntries.java

import java.net.*;
import java.util.*;
public class DatagramPacketEntries
{
  public static void main( String args[] ) throws Exception
  {
    byte data[] = new Date().toString().getBytes();
    InetAddress ia    = InetAddress.getByName( "localhost" );
    int         port = 7;
    DatagramPacket p = new DatagramPacket( data,data.length,ia,port );
    System.out.println( "Paket addressiert an " + p.getAddress()
                        + " an Port " + p.getPort() + "\n"
                        + "Mit " + p.getLength() + " Bytes: "
                        + new String(p.getData()) );
  }
}

16.14.6 Das Paket senden

Zum Senden eines DatagramPacket dient die DatagramSocket-Methode send(DatagramPacket). Sie schickt das Datagram an die im DatagramPacket enthaltene Port-Nummer und -Adresse. Im oberen Beispiel hatten wir diese Informationen einmal ausgelesen. Die Reihenfolge für Sendevorgänge ist also immer die gleiche: Ein Datagram-Socket mit einem Standard-Konstruktor erzeugen, das DatagramPaket-Objekt mit dem Port und der Inet-Adresse des Empfängers erzeugen, dann schickt send() das Paket auf die Reise. Wir sehen im folgenden Beispiel einen Client, der sich mit einem Server verbindet und einfach die Uhrzeit abschickt. Dies dient der Vorbereitung auf einen eigenen UDP-Zeit-Server.

Listing 16.20 UDPClient.java

import java.net.*;
import java.util.*;
class UDPClient
{
  public static void main( String args[] )
  {
    try
    {
      DatagramPacket packet;
      while ( true )
      {
        InetAddress ia = InetAddress.getByName( "localhost" );
        String s = new Date().toString();
        packet = new DatagramPacket( s.getBytes(),s.length(),ia,4711 );
        DatagramSocket dSocket = new DatagramSocket();
        dSocket.send( packet );
        System.out.println( "Weg is' es" );
        Thread.sleep( 1000 );
      }
    }
    catch ( Exception e )
    {
      System.out.println( e );
    }
  }
}

16.14.7 Die Zeitdienste und ein eigener Server und Client

Ein Zeit-Server bietet Clients immer die aktuelle Server-Uhrzeit an. Wir halten uns hier an das Daytime Protocol, welches im RFC 867 beschrieben ist. Ein Server lauscht auf Port 13 nach UDP-Paketen¹ und sendet dann die Antwort an den Sender, dessen Adresse er aus dem Paket nimmt. Im Gegensatz zu unseren bisher geschriebenen Programmen muss der Client erst ein Paket aufbauen, es senden und dann auf die Antwort warten. Der Server erwartet jedoch kein spezielles Anfrageformat. Er reagiert auf einen beliebigen Inhalt, da er diesen ohnehin verwirft. Die Zeichenkette vom Server muss kein spezielles Format besitzen, doch bietet sich hier eine Zeichenkette mit dem Format »Wochentag, Monat, Tag, Jahr, Zeitzone« an.

Da Client und Server ziemlich ähnlich aufgebaut sind, ist es eigentlich egal, mit welchem Teil wir beginnen. Sie unterscheiden sich wenig, da beide Daten empfangen und senden. Wenn wir einen Client für Zeitdienste programmieren, können wir den eingebauten Daytime-Server nutzen. Unter Unix ist dieser schon vorinstalliert. Unter Windows müssen wir den Dienst erst mit dem Zusatzprogramm Uatime32 aus den Socket-Programmen starten. Da wir aber gleich selber einen Server programmieren werden, lässt sich zum Testen auch ein Kapitel weiter schauen.

Client

Die folgende Implementierung zeigt, wie ein Zeit-Server angesprochen wird. Dazu wird zunächst ein leeres Paket als Anfrage an den Server gesendet. Anschließend wird mit receive() auf das hereinkommende Paket gewartet. Wenn dieses kommt, dann liefert getData() eine Zeichenkette mit der Zeit.

Listing 16.21 UDPTimeClient.java

import java.net.*;
class UDPTimeClient
{
  public static void main( String args[] )
  {
    try
    {
      DatagramPacket packet;
      while ( true )
      {
        // zunächst die Anfrage an den Server
        byte data[] = new byte[1024];
        InetAddress ia = InetAddress.getByName( "localhost" );
        packet = new DatagramPacket( data, data.length, ia, 13 );
        DatagramSocket toSocket = new DatagramSocket();
        toSocket.send( packet );
        // Jetzt vom Server was empfangen
        DatagramSocket fromSocket = toSocket;
        //new DatagramSocket();
        packet = new DatagramPacket( data, data.length );
        fromSocket.receive( packet );
        String s = "Server" + //packet.getAddress() +
                   " am Port " + packet.getPort() +
                   " gibt mit die Zeit "+
                   new String( packet.getData() );
        System.out.println( s );
        fromSocket.close();
        Thread.sleep( 1000 );
      }
    }
    catch ( Exception e )
    {
      System.out.println( e );
    }
  }
}

Zeit-Server

Der Server liest aus dem Paket die IP-Adresse und Port-Nummer des Senders heraus und schickt ein Paket mit einer Zeiteinheit zurück. Das nachfolgende Programm wartet auf dem Port auf eine Anfrage und gibt die aktuelle Zeit einfach aus.

Listing 16.22 UDPTimeServer.java

import java.net.*;
import java.util.*;
public class UDPTimeServer
{
  public static void main( String args[] )
  {
    try
    {
      byte data[] = new byte[ 1024 ];
      DatagramPacket packet;
      DatagramSocket socket = new DatagramSocket( 13 );
      while ( true )
      {
        // Auf Anfrage warten
        packet = new DatagramPacket( data, data.length );
        socket.receive( packet );
        // Empfänger auslesen, aber Paketinhalt ignorieren
        InetAddress adress = packet.getAddress();
        int         port   = packet.getPort();
        System.out.println( "Anfrage von " + packet.getAddress() +
                            " am Port " + packet.getPort() );
        // Paket für Empfänger zusammenbauen
        String s = new Date().toString() + "\n";
        s.getBytes( 0, s.length(), data, 0 );
        packet = new DatagramPacket(data,data.length,adress,port);
        socket.send( packet );
        Thread.sleep( 1000 );
      }
    }
    catch ( Exception e )
    {
      System.out.println( e );
    }
  }
}

¹ Den Zeitdienst gibt es auch als TCP-Dienst, der hier aber keine Rolle spielt.