trotz dyn-IP server finden

[Andi_CH]

Ich soll einen Server finden, der allerdings eine dynamische IP hat, aber auf dem eine Software von mir laufen kann. (Also habe ich wohl alle Möglichkeiten)
Die Server bieten CAM-Bilder (http) an, welche auf ein bestimmtes Triggerevent "gleichzeitig" vom Client-PC gespeichert werden sollen.

Es ist wieder einmal eine Frage nach den "best practices", also habe ich noch keinen Code.
Es gibt möglicherweise mehrere Server - ich muss alle finden, nicht nur einen.

Ich habe bis jetzt nur eine Idee die in Anlehnung an DHCP entstanden ist:
- Broadcast - die Server geben Antwort - ich muss aber zuverlässig alle Server finden. Server die starten senden auch einen Broadcast, damit schon laufende Clients davon erfahren


Gibt es andere Ideen? (Vorteile / Nachteile)

 

[Tomate_Salat]

Mir ist die Topologie nicht ganz klar. Aber: hast du irgendwo einen Server mit Statischer IP zur verfügung? An den könnten die anderen Server ihre Daten senden und du könntest von deiner Workstation aus die Daten dort abholen. Wenn die Server sich gegenseitig kennen sollen, könnte der zentrale Server diese miteinander bekannt machen.

Eine ähnlich idee wäre: nimm oder bau dir sowas wie dyndns nach. Irgendwo zentral updated jeder Server seine aktuelle IP und diese tabelle kannst du dann abfragen.

 

[Andi_CH]

Ich schreib doch dass ich dynamische IPs habe :bahnhof: was ist daran unklar ???:L

EDIT: Ach ja noch was - verrate mir wie ich den dynDNS Server finden soll? Auch der hätte eine dynamische IP.

 

[Tomate_Salat]

hast du irgendwo einen Server mit Statischer IP zur verfügung?

Mir geht es hier um einen Extra-Server. Der steht dann z.B. bei euch inhouse und nicht draußen beim Kunden oder wo auch immer.

Ach ja noch was - verrate mir wie ich den dynDNS Server finden soll? Auch der hätte eine dynamische IP.

habe schon ewig nichts mehr mit dyndns gemacht. Aber die bieten(damals zumindest noch, wie es heute ausschaut :bahnhof ein Programm, welches deine IP mit einer domain synchronisiert. Also: deine IP wird dynamisch neu zugewiesen, das Programm bekommt das mit und informiert einen anderen Server (hierfür würde schon ein Webserver ausreichen).

 

[Andi_CH]

Bring jetzt bitte kein Chaos hier rein - NEIN ich habe KEINE fixe IP zur Verfügung.

Vergiss dein Denken an dynIP - das verwirrt nur - Ich suche ein Lösung für mein Problem und keine weiteren Probleme

Ich will die IP-Nummern der Server finden - ähnlich DHCP - da schreit man aufs Netz und der Server antwortet mit seiner IP (danach gehts dann weiter)

Wenn jemand einen Vorschlag hat der noch einfacher ist ok, aber ich glaube kaum dass es einfacher geht.

Ein weiteres Problem ist ja auch, dass ich eine unbekannte Anzahl Server im Netz habe und alle finden muss - wie soll mir DHCP oder was auch immer dabei helfen?

(Das Thema Broadcastgrenzen habe ich absichtlich noch nicht angschnitten, aber mir ist das schon klar)

 

[TheRealSpikee]

Also das einfachste ist wirklich DynDNS *es gibt ja verschiedene anbieter*.

Was passiert bei DynDNS ?

Du hast eine FESTE Domain !
Dieser FESTEN Domain wird durch ein Tool auf dem Client-Rechner *die meisten modernen Router können sowas auch *zumindest mit DynDNS.org** in regelmäßigen Abständen die aktuelle IP zugewiesen.
Was nun passiert ist das der Client den DNS von DynDNS nach einer Domain fragt ... dieser sieht in seiner DB nach und löst die Domain in die aktuelle IP auf ... FERTIG.

Was du also nun zu verwenden hast ist NICHT die IP ... sondern die DOMAIN ! ... Der Rest wird durch DNS transparent im HG gemacht.

Was Broadcasting angeht : du weist schon das du nur innerhalb des selben SubNet Broadcasten kannst oder ? Wenn dein "Server" also nun eine dyn IP hat müsstest du zumindest für sorgen das diese immer im selben SubNet mit deiner eigenen ist ... was ich sehr stark bezweifel. Auch ist es in den meisten öffentlichen Netzen nicht möglich zu Broadcasten da solche Pakete von den Verbindungs-Servern der Anbieter geschluckt werden.

 

[Andi_CH]

Warum meint ihr mein Problem ändern zu müssen bzw. können. Jedes mal wenn eine etwas komplexere Anfrage kommt laufen die Threads ins Wirre, obwohl ja das die interessanten Themen der Informatik wären und nicht die ewigen "wie zeichne ich ein Pacalsches Dreieck" u.Ä.

Also Neustart:
dynDNS nütz bei meinem Problem rein gar nichts! Wer es nicht versteht muss es einfach glauben. (Wie soll mir DNS dabei helfen Dienste im Netz zu finden? Nebenbei: ich habe 10.x.x.x IP's!)

Ich will etwas implementieren, das eine Ähnlichkeit mit DHCP hat (wer das mittels dynDNS lösen kann, empfehle ich für den Nobelpreis der Informatik)

Ich will die IP Nummern aller Server die einen bestimmten Dienst anbieten herausfinden.
- Idee Broadcast
- Frage: Wie mache ich einen Broadcast?
- Frage: Wie fange ich alle Antworten ab?





----------
Noch einige Details, die aber nicht diskutiert werden müssen und die ich nicht diskutieren werde

Netzwerke an und für sich habe ich definitiv begriffen - auch wie weit Pakete laufen - glaubt es einfach.

Wenn man lange genug wartet, kann der DNS sogar die Rechneramen auflösen die dynamische IPs haben, aber das nützt mir NICHTS weil ich die Namen nicht kenne. Es gibt, wie oben erwähnt, keinen Verzeichnisdienst der das kann - es gibt auf der ganzen Welt keinen der das kann und wenn ich so einen erfinden würde ... wer sagt meinem Progrämmchen zur Laufzeit auf welchem Rechner dieser Dienst laufen würde? Auch der hat bei jeder Installation einen anderen Namen ...

 

[Tomate_Salat]

Warum meint ihr mein Problem ändern zu müssen bzw. können.

Gibt es andere Ideen? (Vorteile / Nachteile)

Dann stelle diese Frage einfach nicht. Wenn du unbedingt das ganze via Broadcast lösen möchtest, dann hätteste einfach danach gefragt.

Nebenbei: ich habe 10.x.x.x IP's!

Wäre vllt schon früher interessant gewesen.

Ich will die IP Nummern aller Server die einen bestimmten Dienst anbieten herausfinden.
- Idee Broadcast
- Frage: Wie mache ich einen Broadcast?
- Frage: Wie fange ich alle Antworten ab?

Das könnte dich vllt interessieren: Broadcasting to Multiple Recipients (The Java™ Tutorials > Custom Networking > All About Datagrams)

Ansonsten: In der Theorie würde ichs so machen, wie du schon beschrieben hast:
-> Server startet
-> Server startet einen Thread, um auf UDP-Anfragen reagieren zu können.
-> Server schickt ein Signal in den vorgegebenen Adressraum (UDP)
---> Server wartet eine vorgegebene Zeit auf eine Antwort
---> Kommt eine Antwort: Server merkt sich die IP

 

[HoaX]

Wie wäre es mit DNS-SD?.

 

[Andi_CH]

Danke für den Hinweis auf die Broadcasterei - das habe ich bis jetzt wirklich noch nicht gefunden.

Dann stelle diese Frage einfach nicht. Wenn du unbedingt das ganze via Broadcast lösen möchtest, dann hätteste einfach danach gefragt.

Gibt es denn einen gangbaren Weg um in einem Netzwerk alle Server zu finden die einen bestimmten Dienst anbieten? Bis jetz nicht ;-)

Ich persönlich kenne übrigens keine einzige Firma in der noch offizielle IPs verwendet werden - die machen alle NAT.

Der Thread hier erinnert mich irgendwie daran ;-)

 

[Tomate_Salat]

Der Thread hier erinnert mich irgendwie daran ;-)

Ich liebe diesen Cartoon

Da ich noch nie mit UDP gearbeitet habe, hats mich gereitzt mal sowas im kleinen (lokal :lol zu testen. Dazu habe ich noch diese Seite genutzt: A Simple Java UDP Server and UDP Client | systemBash ist etwas kompakter als die andere.

Hier mal mein kleiner Test:

package de.broadcast;

import java.net.DatagramPacket;
import java.net.DatagramSocket;
import java.net.InetAddress;
import java.net.SocketTimeoutException;

public class BroadCastingSystem extends Thread
{
	public final int PORT;
	
	public static void main(final String[] args) throws Exception {
		new BroadCastingSystem(50505,true);
		BroadCastingSystem b2=new BroadCastingSystem(50505,false);
		
		b2.sendSignal();
		
		// Zur sicherheit bzgl. der Daemon-Threads
		Thread.sleep(3000);
	}
	
	public BroadCastingSystem(final int PORT, final boolean startServer)
	{
		this.PORT=PORT;
		setDaemon(true);
		if(startServer)
			start();
	}
	
	public void sendSignal()
	{
		String server="255.255.255.255";
		try {
			DatagramSocket client=new DatagramSocket();
			byte[] message="bcs".getBytes();
			DatagramPacket packet=new DatagramPacket(message, message.length, InetAddress.getByName(server), PORT);
			client.send(packet);
			
			byte[] answer=new byte[2048];
			DatagramPacket awPacket=new DatagramPacket(answer, answer.length);
			client.setSoTimeout(2000);
			client.receive(awPacket);
			
			System.out.println("Antwort: " + new String(awPacket.getData()));
			System.out.println("Von    : " + awPacket.getAddress().getHostAddress());
		} catch (SocketTimeoutException e) {
			System.err.println(server + " antwortet nicht auf das BroadcastSignal"); // <-- hatte mal Sinn ergeben, als in server noch meine IP-Adresse
		} catch (Exception e) {
			System.err.println("Fehler beim Senden des Signals");
		}
	}
	
	@Override
	public void run()
	{
		try {
			byte[] receiveData=new byte[2048];
			DatagramSocket udpServer=new DatagramSocket(PORT);
			DatagramPacket udpPacket=new DatagramPacket(receiveData, receiveData.length);
			
			while(true) {
				udpServer.receive(udpPacket);
				String message=new String(udpPacket.getData());
				InetAddress adress=udpPacket.getAddress();
				int port=udpPacket.getPort();
				
				System.out.println("Gefunden");
				System.out.println("----------------------------");
				System.out.println("IP     : " + adress.getHostAddress());
				System.out.println("Port   : " + port);
				System.out.println("Message: " + message);
				System.out.println("----------------------------");
				System.out.println();
				
				byte[] send=message.toUpperCase().getBytes();
				DatagramPacket srvPacket=new DatagramPacket(send, send.length, adress, port);
				udpServer.send(srvPacket);
			}
			
		} catch(Exception e) {
			System.err.println("Konnte UDP-Signal nicht empfangen");
		}
	}
}

Das ist ganz nett. Ich sende den Broadcast an die Broadcast-Adresse 255.255.255.255 und bekomme als Antwort meinen Rechner .

Gefunden
----------------------------
IP     : *.*.*.*
Port   : 51596
Message: bcs
----------------------------

Antwort: BCS
Von    : *.*.*.*

 

[Andi_CH]

uuhhhh böses Program - die Windooffirewall liebt das gar nicht, aber die kann man ja "überreden"

Auf XP tut es gar nicht - "255:255:255:255 antwortet nicht auf das Broadcastsignal"

 

[Tomate_Salat]

Du hast auch an allem was auszusetzen

Bin hier unter Win7 aber ich denke nicht, dass es damit etwas zu tun hat. Vllt hast du einfach eine andere Broadcastadresse in deinem Netz

 

[Andi_CH]

Auf der Win7 Kiste die gleich daneben steht tut es - ich wollte eigentlich nur feststellen ob der Broadcast bis zum anderen PC geht oder nicht ;-)

Die XP-Kiste sieht nicht mal sich selbst, aber ist ja egal.

Du meinst eine andere Broadcastadresse? Soll ich mal 127.0.0.1 ausprobieren?

 

[HoaX]

Wenn du einen Standard willst dann nimm DNS-SD/Bonjour/ZeroConf. Das wird auch z.B. von UPnP zur Service Discovery eingesetzt. Als Javalib gibts da z.B. jmdns (JmDNS). Beispiele gibts da: https://jmdns.svn.sourceforge.net/svnroot/jmdns/tags/jmdns-3.4.1/src/sample/java/samples/

 

[Tomate_Salat]

Du meinst eine andere Broadcastadresse? Soll ich mal 127.0.0.1 ausprobieren?

Nein, nimm lieber "localhost" :joke:. So kurz vor der Mittagspause lasse ich mir gerne solch kleinen Fehler durchgehen .

 

[thE_29]

Du bist dir sicher, dass die Server eine Portweiterleitung eingerichtet haben, bzw. die direkt im Netz hängen?

Sonst bringt dir der Broadcast übers Inet nicht wirklich was..

 

[Andi_CH]

Ja ich weiss - Auftrag: Keine Konfiguration - einfach einstöpseln und es muss alles automatisch laufen ;-)

(Wobei die 1-3 Webcams wohl meistens am selben PC eingestöpselt sein werden und der "Klick" der auslöst, dass die Bilder gespeichert werden geographisch ganz aus der Nähe kommt - die Chancen stehen gar nich soooo schlecht. Was aber definitiv ist: Netz = Intranet!

Ich wurde noch auf Multicast aufmerksam gemacht - da haben wir je nach Switch bessere Chancen, aber damit habe ich null Erfahrung.

 

[HoaX]

ZeroConf/DNS-SD/Bonjour verwendet Multicasts.

 

[thE_29]

Achja, es kann sein das Broadcast unter Windows mit Java nicht klappt..

Zumindest kann ich mich an was erinnern und dieser Bug: Bug ID: 4212324 Packets sent to broadcast address not received on servers bound to specific addr sagt auch aus, dass die Antworten nicht klappen..

Man solle einfach alle Ip-Adressen in einer Schleife durchgehen oder Linux benutzen..

 

[HoaX]

Achja, es kann sein das Broadcast unter Windows mit Java nicht klappt..

Zumindest kann ich mich an was erinnern und dieser Bug: Bug ID: 4212324 Packets sent to broadcast address not received on servers bound to specific addr sagt auch aus, dass die Antworten nicht klappen..

Man solle einfach alle Ip-Adressen in einer Schleife durchgehen oder Linux benutzen..

Der Bug tritt ja nur aus wenn man den Serversocket an eine feste IP bindet. Das sollte in diesem Anwendungsfall ja nicht erforderlich sein.

 

[Gast2]

Sonst bringt dir der Broadcast übers Inet nicht wirklich was..

Broadcast wird vom Internet gefiltert - bzw. - gar nicht erst weiter geleitet (weil es entsprechend konfiguriert werden muss)

Ich wurde noch auf Multicast aufmerksam gemacht - da haben wir je nach Switch bessere Chancen, aber damit habe ich null Erfahrung.

das ist abhängig vom Switch und ich hatte bis dato nur schlechte Erfahrung

Achja, es kann sein das Broadcast unter Windows mit Java nicht klappt..
[...]
Man solle einfach alle Ip-Adressen in einer Schleife durchgehen oder Linux benutzen..

das ist murks und hat werder was mit Windows, Linux noch Mac am Hut ... das Problem ist das Du meist mehrere IPs im Rechner hast (bei mir eth1 vmnet1, vmnet8, tap0 und manchmal noch tap1) ... als Absender im Broadcast wird vom Betriebssystem aber nur eine IP eingetragen ... die Wahrscheinlichkeit das die richtige IP (bzw. richtiges Netz) eingetragen ist, sinkt also mit steigender Anzahl der IPs ... es bringt nichts wenn man für den UDP-Server an der Stelle 0.0.0.0 angibt - da muss schon das richtige Netz angegeben werden ... das zu Grunde liegende Problem wurde aber diese Woche schon diskutiert

 

[HoaX]

das ist murks und hat werder was mit Windows, Linux noch Mac am Hut ... das Problem ist das Du meist mehrere IPs im Rechner hast (bei mir eth1 vmnet1, vmnet8, tap0 und manchmal noch tap1) ... als Absender im Broadcast wird vom Betriebssystem aber nur eine IP eingetragen ... die Wahrscheinlichkeit das die richtige IP (bzw. richtiges Netz) eingetragen ist, sinkt also mit steigender Anzahl der IPs ... es bringt nichts wenn man für den UDP-Server an der Stelle 0.0.0.0 angibt - da muss schon das richtige Netz angegeben werden ... das zu Grunde liegende Problem wurde aber diese Woche schon diskutiert

Nein. Da je Interface ein Paket vom OS versendet wird ist diesem auch das Interface und die richtige IP bekannt. Und die wird da auch eingesetzt, egal welches OS.
Zu dem Thema kann ich auf die Schnelle in deinem Link absolut nichts finden. Welchen Beitrag meinst du genau? Imo gehts da mehr um Kollisionen...

Das Problem beim verlinkten Bug ist dass die Antwort des Clients ebenfalls über den Broadcast kommt und mit Java nicht abgefragt werden kann über welches Interface das Paket kam.

 

[Andi_CH]

Auf zwei meiner Maschinen sind Linuxe (eine Debian, eine Kubuntu) dann eine mit Win XP und eine mit Win7 ... ich habe nicht alles auf allen Versucht.

Alle IPs durchgehen? Sozusagen einen Portscanner implementieren? (Ich weiss ja in welchem Portrange Bilder angeboten werden) Lieber nicht, wenn es anders geht - aber DHCP läuft hier doch auch durch alle Switsches hindurch, wobei im Moment alle meine Kisten an ein und demselben Switsch hängen

--
Warum soll man eigentlich Switch schreiben wenn man Switsch spricht - ja das erste war noch ein Vertipper - das zweite pure Absicht

 

[thE_29]

Du machst den Fehler von einem LAN oder WAN auf das Internet zu schließen..

Klar ist das Internet auch nur ein riesen WAN, aber da wird viel gefiltert/geblockt und somit ist das ganze schwer zu vergleichen..


Bau dir halt ne Klasse was nen IP-Range durchgeht (10.0.0.X bis 10.254.X.X) und via UDP an einen fixen Port (weil auf den Maschinen läuft ja was von dir) ne Anfrage hinschickt..

Ist der Server richtig konfiguriert (Port) + hat Weiterleitung oder hängt direkt im Netz, so solltest du ne Antwort kriegen..

Läuft zufällig was auf dem gleichen Port, so wirst du eine Antwort kriegen die dir nicht passt (musst halt ne Routine einbauen) oder gar keine bekommen..

Läuft gar nix auf dem Port oder wird der Port nicht weitergereicht oder ist der Server falsch konfiguriert, tjo, dann hastn Pech

 

[Andi_CH]

LAN, WAN oder Wahn das ist hier die Frage Ich habe nicht verstanden was ich verwechseln soll.
Aber das ein HUB Dinge durchlässt die schon beim Switch, spätestens aber bei Router stecken bleiben ist bekannt und ein heutiges LAN besteht beinahe nur noch aus Switches.

Was ich nicht verstehe, weil ich es noch nie angeschaut habe, ist Mulitcast.

Wie soll denn das mit dem Routing dieser eigentlich virtuellen IP Nummern gehen?

 

[TheRealSpikee]

Warum meint ihr mein Problem ändern zu müssen bzw. können. Jedes mal wenn eine etwas komplexere Anfrage kommt laufen die Threads ins Wirre, obwohl ja das die interessanten Themen der Informatik wären und nicht die ewigen "wie zeichne ich ein Pacalsches Dreieck" u.Ä.

Also Neustart:
dynDNS nütz bei meinem Problem rein gar nichts! Wer es nicht versteht muss es einfach glauben. (Wie soll mir DNS dabei helfen Dienste im Netz zu finden? Nebenbei: ich habe 10.x.x.x IP's!)

Ich will etwas implementieren, das eine Ähnlichkeit mit DHCP hat (wer das mittels dynDNS lösen kann, empfehle ich für den Nobelpreis der Informatik)

Ich will die IP Nummern aller Server die einen bestimmten Dienst anbieten herausfinden.
- Idee Broadcast
- Frage: Wie mache ich einen Broadcast?
- Frage: Wie fange ich alle Antworten ab?





----------
Noch einige Details, die aber nicht diskutiert werden müssen und die ich nicht diskutieren werde

Netzwerke an und für sich habe ich definitiv begriffen - auch wie weit Pakete laufen - glaubt es einfach.

Wenn man lange genug wartet, kann der DNS sogar die Rechneramen auflösen die dynamische IPs haben, aber das nützt mir NICHTS weil ich die Namen nicht kenne. Es gibt, wie oben erwähnt, keinen Verzeichnisdienst der das kann - es gibt auf der ganzen Welt keinen der das kann und wenn ich so einen erfinden würde ... wer sagt meinem Progrämmchen zur Laufzeit auf welchem Rechner dieser Dienst laufen würde? Auch der hat bei jeder Installation einen anderen Namen ...

Sorry ... aber da muss ich dir jetzt mal diesen Vorschlaghammer zurückgeben ...

Warum wir bis dahin alle an DynDNS gedacht haben : weil du nicht damit rausgerückt bist das du da ganze innerhalb eines LAN's machen willst *zugegeben ... ein Class-A Netz *10.0.0.0/8* ist schon ein etwas größeres LAN* ... und wir alle so "dumm" waren und dachten das du sowas übers Netz machen willst.

Es wäre also von Vorteil für DICH gewesen wenn du das gleich im ersten Post erwähnt hättest anstatt dich erstmal 3 Posts darüber aufzuregen das wir scheinbar alle zu dumm dazu sind um dein Problem zu begreifen ... Aber wenn du der Meinung bist das wir alle Glaskugeln haben und du mit solchen wichtigen Infos nicht rausrückst ... dann beschwer dich nicht drüber wenn niemand dein Problem versteht.


Was eine solche Aktion im LAN angeht : Multicast ! Das mit Broadcast wird in einem Class-A-Netz irgendwo ins Leere laufen ... Multicast und entsprechend konfigurierte Switches und Router sollten hier die Lösung sein.

Ein sehr einfaches Beispiel welches sogar über V-LAN funktioniert *mit einige Modifikationen*

MulticastServer.java

import java.net.*;
import java.io.*;
public class MulticastServer
{
	static String groupAddress="226.77.45.33";
	static int port=4533;
	public static void main(String[] args)
	{
		try
		{
			byte[] buffer=new byte[128];
			DatagramPacket packet=new DatagramPacket(buffer, buffer.length);
			InetAddress address=InetAddress.getByName(groupAddress);
			MulticastSocket socket=new MulticastSocket(port);
			socket.joinGroup(address);
			while(true)
			{
				socket.receive(packet);
				String message=new String(packet.getData(), 0, packet.getLength());
				if(!message.equals("MULTICAST_DISCOVER"))
					continue;
				System.out.println("Nachricht empfangen: "+message+" von "+packet.getAddress());
				message = "MULTICAST_RESPONSE";
				DatagramPacket response=new DatagramPacket(message.getBytes(), message.length(), packet.getAddress(), packet.getPort());
				socket.send(response);
			}
		}
		catch(Exception e) { e.printStackTrace(); }
	}
}

MulticastClient.java

import java.net.*;
import java.io.*;
public class MulticastClient
{
	static String groupAddress="226.77.45.33";
	static int port=4533;
	public static void main (String[] args)
	{
		try
		{
			InetAddress address=InetAddress.getByName(groupAddress);
			byte[] message="MULTICAST_DISCOVER".getBytes();
			DatagramPacket packet=new DatagramPacket(message, message.length, address, port);
			MulticastSocket socket=new MulticastSocket();
			socket.setSoTimeout(2000);
			socket.send (packet);
			byte[] b=new byte[128];
			packet.setData(b);
			packet.setLength(b.length);
			socket.receive(packet);
			String response=new String(packet.getData(), 0, packet.getLength());
			if(response.equals("MULTICAST_RESPONSE"))
				System.out.println("Antwort empfangen: "+response+" von "+packet.getAddress());
			socket.close();
		}
		catch (Exception e) { e.printStackTrace(); }
	}
}

 

[Gast2]

Was ich nicht verstehe, weil ich es noch nie angeschaut habe, ist Mulitcast.
Wie soll denn das mit dem Routing dieser eigentlich virtuellen IP Nummern gehen?

das kann Dir (eigentlich) egeal sein - darum kümmern sich das Netzwerk "selber" ... Du sagst nur eins von 2 Dingen dem Netzwerk

1. Ich habe hier was auf IPort für das Netzwerk
2. Ich will was von IPort haben

dann kümmert sich Dein Switch, an dem mit Deinem Kupfer- (oder WLAN-) Kabel hängst, das Du entsprechend via Multicast senden bzw. empfangen kannst

Das mit Broadcast wird in einem Class-A-Netz irgendwo ins Leere laufen

hä?? ... dann ist das Netzwerk entsprechend NICHT konfiguriert

Multicast und entsprechend konfigurierte Switches und Router sollten hier die Lösung sein.

ahh - und was ist jetzt der Unterschied zu Broadcast mit entsprechend konfigurierten Switchen ???:L

Ein sehr einfaches Beispiel welches sogar über V-LAN funktioniert

ein V-LAN ist transparent für das Netzwerk ... quasi kann der Teil "V-" völlig ignoriert werden ... darum hat sich nur der Netzadmin zu kümmern - als Programmierer ist das Banane

hand, mogel

BTW: die Netzeinteilung nach Klassen (Class-A, Class-B, etc) ist seit 1993 veraltet

 

[Spacerat]

Broadcast? Multicast? Egal wie... es dauert unter Umständen viel zu lange, bis alle Server bzw. Clients antworten. Ich würde es so machen, wie es Vuze, E-Mule und wie diese ganzen Filesharingprogramme sonst noch heissen. Verbreiten und ständiges Aktualisieren von Serverlisten. Dazu wäre im Zweifelsfalle aber mindestens ein Server erforderlich, der ständig online ist oder zumindest per Dyn-DNS erreicht werden kann, weil sonst alle aktuellen Serverlisten, die im Umlauf sind, auf einen Schlag ungültig werden würden, wenn das gesamte Netzwerk zusammenbricht.

 

[TheRealSpikee]

Warum ein Broadcast in einem Class-A ins Leere läuft ? Weil du um ein Class-A aufzubauen eine ganze Menge an Switches und Routern brauchst und das Broadcast irgendwann irgendwo hängen bleibt. Bei einem Multicast gibt es das Problem nicht da dies ein Packet ist was als Ziel eine bestimmte IP hat ... und nicht einfach AN ALLE gehen soll. Das ein Multicast-Paket genau so an alle geht wie ein Broadcast-Paket ist mir auch klar ... jedoch wird ein solches Paket auch geroutet ... was ein Broadcast-Paket eben nicht wird.

DAS ist der Unterschied zwischen Broad- und Multicast ...

Was das V-LAN angeht : ich meinte das es mit genau diesem Source möglich ist auch über V-LAN Multicasts zuversenden ... und das ohne irgendwas am Netz zu ändern. Ich spreche bei V-LAN im übrigen über Software ... also virtuelle NICs ... und nicht über ein physisches V-LAN mit entsprechenden V-LAN Routern ...

@TO
Nun ... das es bei einem Class-A relativ lange dauert bis alle Server erkannt wurden dürfte an der Größe des Netzes liegen. Auch kann es sein das gewisse UDP-Pakete durch Kollisionen verloren gehen ... du also beim ersten Durchlauf unter Umständen nicht alle findest.

 

[Gast2]

Weil du um ein Class-A aufzubauen eine ganze Menge an Switches und Routern brauchst und das Broadcast irgendwann irgendwo hängen bleibt.

???:L ... vertrau mir - bei 16 Mio Rechner werden auch Multicast-Pakete in den Weiten des Netzwerks verschwinden

Bei einem Multicast gibt es das Problem nicht da dies ein Packet ist was als Ziel eine bestimmte IP hat ... und nicht einfach AN ALLE gehen soll. Das ein Multicast-Paket genau so an alle geht wie ein [...]

im ersten Satz behauptest Du das Multicast nicht an alle geht ... im Zweiten genau das Gegenteil :bahnhof:

Broadcast-Paket ist mir auch klar ... jedoch wird ein solches Paket auch geroutet ... was ein Broadcast-Paket eben nicht wird.

wie ich schon in einem anderem Posting erwähnte ... damit der Broadcast (255.255.255.255) in andere Netze geroutet wird, muss das im Router aktiviert werden ... damit der Router Multicast weiter leitet, muss das aktiviert werden

DAS ist der Unterschied zwischen Broad- und Multicast

es gibt keinen wesentlichen Unterschied zwischen Broadcast und Multicast ... Broadcast und Multicast muss vom Router aktivert werden damit es im gesamten LAN funktioniert ... beides basiert auf UDP und damit geht in beiden Fällen auch mal ein Paket verloren ... also - welchen Qualitativen Vorteil hat an der Stelle Multicast gegenüber Broadcast

hand, mogel

BTW: die Netzeinteilung nach Klassen (Class-A, Class-B, etc) ist seit 1993 veraltet

 

[TheRealSpikee]

Ey weiste ...

denkst du mir ist das nicht klar das es offiziell diese Netzklasseneinteilung nicht mehr gibt ?

Junge echt ... es reicht wenn man sowas EINMAL schreibt ... wir sind hier in nem Forum ... da kann man auch noch nach 3 Jahren lesen was geschrieben wurde ...

Jedoch ist es bei weitem einfach einfach Class-A zu schreiben als xxx.0.0.0/8 ... außerdem weis jeder der sich halbwegs mit Netzwerken auskennt was damit gemeint ist ... wenn ich mir so den Mist von *namentlich* SemperVideo auf YT ansehe und feststelle wie falsch dort Netzklassen und Subnetmasken erklärt werden ... bleibe ich lieber bei einer 20 Jahre alten Bezeichnungsart die dafür jeder versteht ...


Was den Unterschied Broadcast vs Unicast angeht : mach dir mal den Spass und bau mal folgendes Netzwerk

       Master-Router
          |        |
Sub-Router 1 Sub-Router 2
|                    |
PC 1               PC 2

Und versuch mal mit Broadcast eine Nachricht zwischen beiden auszutauschen ... das wird nicht funktionieren ... Multicast jedoch schon ...

Nur weil man so n fetter Lobbyist is ... muss mans nich raushängen lassen ...


gott wie ihr mich hier alle anwiedert ... ich glaub ich muss mal ne regel gegen 85.158.183.169 einrichten ...

 

[Tomate_Salat]

gott wie ihr mich hier alle anwiedert ... ich glaub ich muss mal ne regel gegen 85.158.183.169 einrichten ...

Zwingt dich niemand hier zu sein.

wir sind hier in nem Forum ... da kann man auch noch nach 3 Jahren lesen was geschrieben wurde

hmm. Darüber solltest DU dir vllt mal Gedanken machen.

BTW: die Netzeinteilung nach Klassen (Class-A, Class-B, etc) ist seit 1993 veraltet

 

[Andi_CH]

Das läuft jetzt ein bisschen aus dem Ruder - sowohl Thematisch als auch auch im Umgangston - ich markiere das als beendigt und wenn ein Mod den Thread aus irgendeinem Grund schliesst, habe ich gar nichts dagegen einzuwenden ...