Multicast - genauer Nachgeschaut
Da das ja heute bei der Tafelrunde eher etwas zusammengesucht war, habe ich mich noch mal hingesetzt und mir die Dinge an-/eingelesen.
Ich werde einfach mal versuchen die Fragen, die da aufkamen wiederzugeben und dann mit passenden Texten beantworten:
- Was ist Multicast?
Multicast ist eine Nachrichtenübertragung von einem Punkt zu einer Gruppe von Empfängern (auch Mehrpunktverbindung genannt).
Daneben gibt es noch weitere Arten von Übertragungen:
- Unicast: eine Punkt-zu-Punkt-Verbindung (klassische Client<->Server Verbindung)
- Broadcast- und die Anycast-Übertragung ("ich bin da - wer noch?" - ping an x.x.x.255)
- Geocast, ein besonderer Multicast, der räumlich begrenzt ist.
- Unicast: eine Punkt-zu-Punkt-Verbindung (klassische Client<->Server Verbindung)
- Was sind die Vorteile von Multicast gegenüber Unicast?
Es sind gleichzeitige Nachrichten an mehrere Teilnehmer möglich, ohne dass sich die Bandbreite des Senders verändert (für den Sender ist es als würde man eine Nachricht an einen Empfänger senden).
Handelt es sich um paketorientierte Datenübertragung, findet die Vervielfältigung der Pakete an jedem Verteiler (Switch, Router) auf der Route statt. - Wie geht das nun genau?
Multicast ist die übliche Bezeichnung für IP-Multicast, das es ermöglicht, in IP-Netzwerken effizient Daten an viele Empfänger zur gleichen Zeit zu senden. Das passiert mit einer speziellen Multicast-Adresse. In IPv4 ist hierfür der Adress-Bereich 224.0.0.0 bis 239.255.255.255 (Klasse D), in IPv6 jede mit FF00::/8 beginnende Adresse reserviert.
Bei der Übertragung über Ethernet werden die IPv4- bzw. IPv6-Multicastadressen auf bestimmte Pseudo-MAC-Adressen abgebildet, um bereits durch die Netzwerkkarte eine Filterung nach relevantem Traffic zu ermöglichen. - Okaaaaay.... Wer macht sowas? Ist sowas nützlich?
Ja ist es. Bekannte Anwendungen sind:
- Audio- und Videoübertragungen (Protokolle wie RTP)
- Verwendung beim Clustering und beim Routing nach dem Routing Information Protocol (RIP) Version 2.
- ist für ein funktionierendes AppleTalk-Netzwerk notwendig.
- Als Service Location Protocol und Multicast DNS wird als Teilimplementierung von Zeroconf Multicast (Rendezvous - inzwischen Bonjour) betrieben
- automatische Zuweisung von IP-Adressen ohne DHCP-Server
- übersetzen von Hostnamen in IP-Adressen ohne DNS-Server
- automatisches Finden von Diensten im lokalen Netzwerk ohne einen zentralen Directory-Server
- In Windows wird es im Simple Service Discovery Protocol benutzt
- Weitere Multicast-Protokolle
- Internet Relay Chat (IRC) bildet Netzwerke, welche einen einfachen TCP-basierten Multicast-Baum realisieren - wer hätte das gedacht ^^
- Es wird überlegt in Jabber Multicast nach zurüsten.
- Und das geht jetzt auch über das Internet oder wie jetzt?
Jein... also:
Multicast-Pakete werden von den meisten Routern im Internet nicht verarbeitet. Deswegen werden multicastfähige Teilnetze über Tunnel zu Multicast Backbones (MBones) verbunden.
Um Multicast-Pakete zwischen mehreren Netzen zu koordinieren, werden spezielle Multicast-Routing-Protokolle verwendet. - Ahja... sehr schön - kann da nix passieren / durcheinander kommen?
Es existieren bei der Verwendung bestimmter Adressbereiche einiger Switches Probleme bei der Weiterleitung von Multicastnachrichten.
Die Adressen von 224.0.0.0 bis 224.255.255.255 sind für Routingprotokolle reserviert und für diese Adressen sendet der Router keine IP-Multicast-Datagramme. Die Adressen von 239.0.0.0 bis 239.255.255.255 sind für scoping reserviert, eine Weiterleitung innerhalb dieses Adressbereichs ist ebenfalls Switch abhängig. Adressen im Bereich 225.x.x.x bis 238.x.x.x sind frei verfügbar. - Nachwort:
Multicasting wird wieder populär, weil IPTV darauf basiert.
Für verteilte Chat-Netzwerke wurde mittlerweile allgemein eingesehen, dass sie nicht mittels IP-Multicast realisiert werden können.
Der Einsatz weiterer Multicast-Protokolle ist daher unumgänglich. Na da haben wirs!
Schamlos kopiert von http://de.wikipedia.org/wiki/Multicast - teiweise gekürtzt und ein wenig angepasst.
Die Formulierungen sind auf die frühe Stunde zurück zu führen.
Anschließend zur Entspannung noch ein wenig Java - ein einfacher Chat-Server:
Zuerst der "Server" - Der ja eigentlich auch Teil jedes Clients ist:
public class NameServer{
// the multicast group address sent to new members
private static final String GROUP_HOST = "228.5.6.7";
private static final int PORT = 1234; // for this server
private static final int BUFSIZE = 1024; // max size of a message
private DatagramSocket serverSock;
// holds the names of the current members of the multicast group
private ArrayList groupMembers;
try { // try to create a socket for the server
serverSock = new DatagramSocket(PORT);
}catch(SocketException se){
System.out.println(se);
System.exit(1);
}
groupMembers = new ArrayList();
waitForPackets();
// das ist dann hier wieder die typische Server-While-Schleifen-Methode
private void waitForPackets(){
DatagramPacket receivePacket;
byte data[];
System.out.println("Ready for client messages");
try {
while (true) {
data = new byte[BUFSIZE]; // set up an empty packet
receivePacket = new DatagramPacket(data, data.length);
serverSock.receive( receivePacket ); // wait for a packet
// extract client address, port, message
InetAddress clientAddr = receivePacket.getAddress();
int clientPort = receivePacket.getPort();
String clientMsg = new String( receivePacket.getData(), 0, receivePacket.getLength() ).trim();
processClient(clientMsg, clientAddr, clientPort);
}
}catch(IOException ioe){
System.out.println(ioe);
}
}
...
}
Und hier dann noch mal der "Client"-Anteil:
public class MultiChat {
// timeout used when waiting in receive()
private static final int TIME_OUT = 5000; // 5 secs
// max size of a message
private static final int PACKET_SIZE = 1024;
// NameServer address and port constants
private static final String SERVER_HOST = "localhost";
private static final int SERVER_PORT = 1234;
/* The multicast port. The multicast group address is
obtained from the NameServer object. */
private static final int GROUP_PORT = 5555;
// for communication with the NameServer
private DatagramSocket clientSock;
private InetAddress serverAddr;
// for communication with the multicast group
private MulticastSocket groupSock;
private InetAddress groupAddr;
public MultiChat(String nm){
/* Attempt to register name and get multicast group
address from the NameServer */
makeClientSock();
waitForPackets();
} // end of MultiChat();
private void makeClientSock(){
try { // try to create the client's socket
clientSock = new DatagramSocket();
clientSock.setSoTimeout(TIME_OUT); // include a time-out
}catch( SocketException se ) {
se.printStackTrace();
System.exit(1);
}
try { // NameServer address string --> IP no.
serverAddr = InetAddress.getByName(SERVER_HOST);
}catch( UnknownHostException uhe) {
uhe.printStackTrace();
System.exit(1);
}
} // end of makeClientSock()
private void waitForPackets(){
DatagramPacket packet;
byte data[];
try {
while (true) {
data = new byte[PACKET_SIZE]; // set up an empty packet
packet = new DatagramPacket(data, data.length);
groupSock.receive(packet); // wait for a packet
processPacket(packet);
}
}catch(IOException ioe){
System.out.println(ioe);
}
} // end of waitForPackets()
}
Wie man ziemlich gut erkennen kann, ist es auch nicht wesentlich anders, als wenn man sich direkt Sockets erstellt. Gefunden habe ich das Ganze in dem Buch "Killer Game Programming in Java" - heißt wirklich so - hin und wieder finden sich da wirklich interessante Dinge besprochen (Link: hier!).
So das wars.
Die Tage wollte ich noch mal bissel was zu OSGi schreiben - so denn das schöne Buch ankommt.
Und aus - leider aktuellem Anlass - zu IPMI und wieso es eigentlich schon fast unverschämt ist, dass ein _mitgelieferetes_ Linux-Tool fehlerhaft ist und deswegen vom Hersteller empfohlen wird, extra dafür ein Windows aufzusetzen. Nichts gegen Windows, aber wieso liefert man ein fehlerhaftes Tool dann mit?
P.S.: Schreibt mal wieder ;-)