Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Neues in Java 7
2 Threads und nebenläufige Programmierung
3 Datenstrukturen und Algorithmen
4 Raum und Zeit
5 Dateien, Verzeichnisse und Dateizugriffe
6 Datenströme
7 Die eXtensible Markup Language (XML)
8 Dateiformate
9 Grafische Oberflächen mit Swing
10 Grafikprogrammierung
11 Netzwerkprogrammierung
12 Verteilte Programmierung mit RMI
13 RESTful und SOAP Web-Services
14 JavaServer Pages und Servlets
15 Applets
16 Datenbankmanagement mit JDBC
17 Technologien für die Infrastruktur
18 Reflection und Annotationen
19 Dynamische Übersetzung und Skriptsprachen
20 Logging und Monitoring
21 Java Native Interface (JNI)
22 Sicherheitskonzepte
23 Dienstprogramme für die Java-Umgebung
Stichwort

Buch bestellen
Ihre Meinung?

Spacer
Java 7 - Mehr als eine Insel von Christian Ullenboom
Das Handbuch zu den Java SE-Bibliotheken
Buch: Java 7 - Mehr als eine Insel

Java 7 - Mehr als eine Insel
Rheinwerk Computing
1433 S., 2012, geb.
49,90 Euro, ISBN 978-3-8362-1507-7
Pfeil 11 Netzwerkprogrammierung
Pfeil 11.1 Grundlegende Begriffe
Pfeil 11.2 URI und URL
Pfeil 11.2.1 Die Klasse URI
Pfeil 11.2.2 Die Klasse URL
Pfeil 11.2.3 Informationen über eine URL *
Pfeil 11.2.4 Der Zugriff auf die Daten über die Klasse URL
Pfeil 11.3 Die Klasse URLConnection *
Pfeil 11.3.1 Methoden und Anwendung von URLConnection
Pfeil 11.3.2 Protokoll- und Content-Handler
Pfeil 11.3.3 Im Detail: vom URL zur URLConnection
Pfeil 11.3.4 Der Protokoll-Handler für Jar-Dateien
Pfeil 11.3.5 Basic Authentication und Proxy-Authentifizierung
Pfeil 11.4 Mit GET und POST Daten übergeben *
Pfeil 11.4.1 Kodieren der Parameter für Serverprogramme
Pfeil 11.4.2 Eine Suchmaschine mit GET-Request ansprechen
Pfeil 11.4.3 POST-Request absenden
Pfeil 11.5 Host- und IP-Adressen
Pfeil 11.5.1 Lebt der Rechner?
Pfeil 11.5.2 IP-Adresse des lokalen Hosts
Pfeil 11.5.3 Das Netz ist klasse
Pfeil 11.5.4 NetworkInterface
Pfeil 11.6 Mit dem Socket zum Server
Pfeil 11.6.1 Das Netzwerk ist der Computer
Pfeil 11.6.2 Sockets
Pfeil 11.6.3 Eine Verbindung zum Server aufbauen
Pfeil 11.6.4 Server unter Spannung: die Ströme
Pfeil 11.6.5 Die Verbindung wieder abbauen
Pfeil 11.6.6 Informationen über den Socket *
Pfeil 11.6.7 Reine Verbindungsdaten über SocketAddress *
Pfeil 11.7 Client-Server-Kommunikation
Pfeil 11.7.1 Warten auf Verbindungen
Pfeil 11.7.2 Ein Multiplikationsserver
Pfeil 11.7.3 Blockierendes Lesen
Pfeil 11.7.4 Von außen erreichbar sein *
Pfeil 11.8 Apache HttpComponents und Commons Net *
Pfeil 11.8.1 HttpComponents
Pfeil 11.8.2 Apache Commons Net
Pfeil 11.9 Arbeitsweise eines Webservers *
Pfeil 11.9.1 Das Hypertext Transfer Protocol (HTTP)
Pfeil 11.9.2 Anfragen an den Server
Pfeil 11.9.3 Die Antworten vom Server
Pfeil 11.9.4 Webserver mit com.sun.net.httpserver.HttpServer
Pfeil 11.10 Verbindungen durch einen Proxy-Server *
Pfeil 11.10.1 System-Properties
Pfeil 11.10.2 Verbindungen durch die Proxy-API
Pfeil 11.11 Datagram-Sockets *
Pfeil 11.11.1 Die Klasse DatagramSocket
Pfeil 11.11.2 Datagramme und die Klasse DatagramPacket
Pfeil 11.11.3 Auf ein hereinkommendes Paket warten
Pfeil 11.11.4 Ein Paket zum Senden vorbereiten
Pfeil 11.11.5 Methoden der Klasse DatagramPacket
Pfeil 11.11.6 Das Paket senden
Pfeil 11.12 E-Mail *
Pfeil 11.12.1 Wie eine E-Mail um die Welt geht
Pfeil 11.12.2 Das Simple Mail Transfer Protocol und RFC 822
Pfeil 11.12.3 POP (Post Office Protocol)
Pfeil 11.12.4 Die JavaMail API
Pfeil 11.12.5 E-Mails mittels POP3 abrufen
Pfeil 11.12.6 Multipart-Nachrichten verarbeiten
Pfeil 11.12.7 E-Mails versenden
Pfeil 11.12.8 Ereignisse und Suchen
Pfeil 11.13 Tiefer liegende Netzwerkeigenschaften *
Pfeil 11.13.1 Internet Control Message Protocol (ICMP)
Pfeil 11.13.2 MAC-Adresse
Pfeil 11.14 Zum Weiterlesen

Rheinwerk Computing - Zum Seitenanfang

11.11 Datagram-Sockets *Zur nächsten Überschrift

Neben den Stream-Sockets gibt es im java.net-Paket eine weitere Klasse, die auch den verbindungslosen Pakettransport erlaubt. Dabei handelt es sich um die Klasse DatagramSocket. Datagram-Sockets basieren auf dem User Datagram Protocol (UDP). Dieses ist auf dem Internet-Protokoll aufgesetzt und erlaubt eine ungesicherte Übertragung – da es auf der Transportschicht des OSI-Modells (Schicht 4) angeordnet ist. Auch UDP erlaubt es einer Applikation, einen Service über einen Port zu kontaktieren. Genau wie TCP nutzt auch UDP verschiedene Port-Nummern, sodass 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 ebenso, doch 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 kennenlernen, das 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 unterschiedlichen 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 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 65.535 Byte (64 KiB – 1). Davon werden allerdings einige Bytes 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 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 können schneller sein. Da die Verbindung nicht verbindungsorientiert ist wie TCP/IP, lassen sich der Aufwand für die korrekte Reihenfolge und 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. Bei Diensten mit Quality of Service (QoS) könnte der Router aber TCP-Pakete bevorzugen und bei drohendem Vermittlungseinbruch UDP-Pakete verwerfen.

Da allerdings Pakete verloren gehen können, würden wir Datagram-Sockets nicht für große Daten verwenden. Für kleine, häufiger ü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 File System (NFS). NFS ist so ausgelegt, dass verloren gegangene Pakete wiederbesorgt werden.

Welche Klasse für welche Übertragung?

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 in UDP kein Konzept wie virtuelle Verbindungen existiert 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 voneinander. Bei UDP verwenden beide die Klasse DatagramSocket, die für eine eingehende und auch ausgehende Verbindung steht.

Tabelle 11.5: Welche Klasse für welchen Verbindungstyp

Klasse Protokoll Verbindungstyp Richtung

Socket

TCP

verbindungsorientiert, korrekte Reihenfolge

ausgehend

ServerSocket

TCP

verbindungsorientiert, korrekte Reihenfolge

hereinkommend

DatagramSocket

UDP

verbindungslos, Datagramme, beliebige Reihenfolge

ausgehend und
hereinkommend


Rheinwerk Computing - Zum Seitenanfang

11.11.1 Die Klasse DatagramSocketZur nächsten ÜberschriftZur vorigen Überschrift

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 diese Informationen nur im Paket 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

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, in denen wir erst ein leeres Paket als Anfrage schicken und dann den Server über uns informieren. Einen beliebigen Port nimmt der erste Konstruktor, da dieser 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 Clientseite festzusetzen, ist nur dann wichtig, wenn hinter einer Firewall operiert wird.

Abbildung

Abbildung 11.12: UML-Diagramm für DatagramPacket und DatagramSocket


Rheinwerk Computing - Zum Seitenanfang

11.11.2 Datagramme und die Klasse DatagramPacketZur nächsten ÜberschriftZur vorigen Überschrift

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, 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. Die folgenden Zeilen reichen für einen Server, der am Port des Duftes 4711 horcht:

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

Abbildung

Abbildung 11.13: UML-Diagramm für DatagramPacket


Rheinwerk Computing - Zum Seitenanfang

11.11.3 Auf ein hereinkommendes Paket wartenZur nächsten ÜberschriftZur vorigen Überschrift

Wenn wir was 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 als Argument übergebenen DatagramPacket ablegt. Mit den Methoden getPort() und getAddress() können wir herausfinden, woher das Paket stammt, wer also der Sender war. Mit getData() bekommen wir die Daten als Byte-Feld, 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 11.19: com/tutego/insel/net/udp/UDPServer.java

package com.tutego.insel.net.udp;

import java.io.IOException;
import java.net.*;

public class UDPServer
{
public static void main( String[] args ) throws IOException
{
DatagramSocket socket = new DatagramSocket( 4711 );

while ( true )
{
// Auf Anfrage warten

DatagramPacket 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.printf( "Anfrage von %s vom Port %d mit der Länge %d:%n%s%n",
address, port, len, new String( data, 0, len ) );
}
}
}

Rheinwerk Computing - Zum Seitenanfang

11.11.4 Ein Paket zum Senden vorbereitenZur nächsten ÜberschriftZur vorigen Überschrift

Wenn wir ein Paket senden wollen, müssen wir einem DatagramPacket auch noch mitteilen, 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 Byte-Feld 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 Byte-Feld geben wir die Anzahl der Bytes an, die gesendet werden sollen. Dies erinnert an C-Stil und ist eigentlich unnötig, weil in Java das Byte-Feld 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, eine Zeichenkette in ein Byte-Feld umzuwandeln (ohne besondere Berücksichtigung der Kodierung), 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 );

Rheinwerk Computing - Zum Seitenanfang

11.11.5 Methoden der Klasse DatagramPacketZur nächsten ÜberschriftZur vorigen Überschrift

Das DatagramPacket ist auch nachträglich veränderbar und kann mit Methoden angepasst und auch ausgelesen werden. Das folgende Programm zeigt ein zu sendendes Paket, und wir können die abgelegten Informationen wieder auslesen.

Listing 11.20: com/tutego/insel/net/udp/DatagramPacketEntries.java

package com.tutego.insel.net.udp;

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.printf( "Paket adressiert an %s an Port %d mit %d Byte:%n%s%n",
p.getAddress(), p.getPort(), p.getLength(),
new String(p.getData()) );
}
}
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()
    Liefert für ein hereinkommendes Paket die Port-Nummer vom Sender. Für ein ausgehendes Paket liefert getPort() den Port, an den das Datagramm geht.

Rheinwerk Computing - Zum Seitenanfang

11.11.6 Das Paket sendenZur vorigen Überschrift

Zum Senden eines DatagramPacket dient die DatagramSocket-Methode send(DatagramPacket). Sie schickt das Datagramm 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: Erst ein Datagram-Socket mit einem Standard-Konstruktor aufbauen, dann das DatagramPacket-Objekt mit dem Port und der Inet-Adresse des Empfängers erzeugen, und 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 11.21: com/tutego/insel/net/udp/UDPClient.java

package com.tutego.insel.net.udp;

import java.io.IOException;
import java.net.*;
import java.util.*;

class UDPClient
{
public static void main( String[] args ) throws IOException,
InterruptedException
{
InetAddress ia = InetAddress.getByName( "localhost" );

while ( true )
{
String s = new Date().toString();
byte[] raw = s.getBytes();

DatagramPacket packet = new DatagramPacket( raw, raw.length, ia, 4711 );

DatagramSocket dSocket = new DatagramSocket();

dSocket.send( packet );

System.out.println( "Weg is' es" );


Thread.sleep( 1000 );
}
}
}
Broadcast

Ein Client kann ein UPD-Paket im lokalen Netzwerk rundsenden (broadcast). Dazu ist als Ziel die besondere IP-Adresse 255.255.255.255 anzugeben. Alle Server im Netz, die empfangsbereit sind, bekommen die Nachricht. Das sieht im Prinzip so aus:

InetAddress inetAddress = InetAddress.getByName( "255.255.255.255" );
DatagramPacket packet = new DatagramPacket( bytes, length, inetAddress, port );
DatagramSocket socket = new DatagramSocket();
socket.setBroadcast( true );
socket.send( packet );

Router sperren oft Pakete dieser Art, daher muss der Netzwerkverwalter mitunter gewisse Vorbereitungen treffen.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
  Zum Katalog
Neuauflage: Java SE 8 Standard-Bibliothek
Neuauflage: Java SE 8 Standard-Bibliothek
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Professionell entwickeln mit Java EE 7






 Professionell
 entwickeln mit
 Java EE 7


Zum Katalog: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Katalog: Einstieg in Eclipse






 Einstieg in Eclipse


Zum Katalog: Einstieg in Java






 Einstieg in Java


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2012
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de