Desingnproblem bei LAN-Broadcast

[Brüggendiek]

Hallo!

Bei dieser Frage handelt es sich nicht um ein Programmierproblem an sich, es ist eher eine Designfrage. Deshalb halte ich auch die Rubrik "Programmieren allgemein" für die Richtige. "Internet / IP / LAN" ist wohl eher für Programmier-Probleme der Bauart "Wie schreibe ich das".

Die programmiertechnische Umsetzung ist kein Problem (sollten Fragen auftreten, kann ich ja nochmal in der passenden Sparte fragen ), es geht mir um den (von der verwendeten Sprache unabhängigen) Lösungsweg bzw. das Programm-Design.

Vorgeschichte des Problems

• 1. Wie hinreichend bekannt ist, wird eine T-DSL-Verbindung nach 24 Stunden getrennt.
• 2. Die Software der bekannten Fritz!-Karten von AVM bieten die Möglichkeit, beim Internet-Connect ein beliebiges Programm zu starten. Die zugewiesene IP wird dabei als Parameter übergeben. Das gilt für DSL und ISDN.
• Ein Freeware-Telefon für VoiceOverIP erweist sich als nicht T-DSL-kompatibel - nach der Zwangstrennung mag das Tele nicht mehr bimmeln. Programm beenden und neu starten ist angesagt

Der Lösungsansatz

Ein Programm schreiben, das bei Connect (also neuer IP) das Telefon sucht, beendet und neu startet.
Da bei meiner Konfiguration das Telefon nicht auf dem Rechner mit der Fritz!-Karte läuft, kommt nur eine Netzwerk-Lösung in Frage. Ein IP-Signal informiert ein Programm, daß ein Connect erfolgt ist.
Nach den ersten Überlegungen folgte die "übliche Eskalation":

• 1. Es wäre schön, die IP für Alle verfügbar zu haben - kein Thema, schreiben wir sie in eine Datei.
• 2. Es sollte die Art der Verbindung bekannt sein - einfach das Programm zweimal speichern (ISDN und DSL) und den Programmnamen in der Datei mitspeichern.
• 3. Übertragen der Informationen im LAN - auch kein großes Problem.
• 4. Es sollten mehrere Rechner informiert werden - mit UDP-Broadcast zu lösen.
• 5. Das System soll universell einsetzbar werden.

Beim letzten Punkt tritt ein Problem auf. Wenn ich alle möglichen und denkbaren Anwendungen in ein Program stecke, züchte ich mir eine "gefiederte, eierlegende Wollmilch-Reit-Sau" - vom Speicherverbrauch der ja prinzipbedingt ständig laufenden Applikation gar nicht zu reden.
Zum UDP-Broadcast brauche ich einen Client als Sender und einen Server als Empfänger. Bei mehreren Rechnern spielt das keine Rolle - mehrere Rechner mit Empfänger auf dem gleichem UDP-Port sind möglich, das Ganze klappt bereits. Bei mehreren Programmen auf einem Rechner stoße ich allerdings auf das Problem, daß diese nicht denselben Port benutzen können - es nur 1 Server pro Port erlaubt.


Für mich bieten sich 2 Lösungswege an:

Lösung A

Da der verwendete UDP-Port sowieso einstellbar sein soll, lasse ich den Sender eben an mehrere Ports senden (wieviele soll ich vorsehen ). Der Benutzer stellt zunächst den Empfänger auf einen freien Port und gibt dann am Sender die Portnummer an.
Bei dieser Lösung gibt es dann für jede Aufgabe ein entsprechendes Empfänger-Programm, das bei eingehender Nachricht die gewünschte Funktion ausführt.

Lösung B

Es wird nur ein Port verwendet. Der Empfänger löst nicht die anstehenden Aufgaben, sondern startet per ShellExecute eine Liste von Programmen, die jeweils eine der gewünschten Aufgaben erledigen.


Um es nochmal klarzustellen: Das Senden per UDP ist bereits realisiert, Programmiertips oder Source benötige ich keinen! Es geht mir nur um Eure Meinungen, welche der beiden Lösungen ich realisieren sollte. Vielleicht hat ja jemand sogar noch eine dritte Lösung, über die wir diskutieren können - ich bin für Vorschläge offen!


Für Eure Beteiligung bedanke ich mich im Voraus,

Gruß

Dietmar Brüggendiek

[Basilikum]

es gäbe eine dritte Lösung - verschiedene Applikationen auf dem gleichen PC auf dem gleichen Port; gerade im Zusammenhang mit dem Empfang von Broadcasts ist dies einfach machbar (siehe WinSock-API setsockopt Parameter SO_REUSEADDR).

[fiasko]

Hallo,

andere Idee: die Client-Programme schicken beim Start ein UDP Broadcast "Ich will über neue IP informiert werden" oder direkt an den Server falls die bekannt ist (Art Registrierung).

Wenn nun eine neue Verbindung erstellt wird schickt der Master an alle Clients "neue IP blah...". Dabei schickt er an jeden IPort die er von der Registrierung noch kennt zurück. Damit kann auf einem Rechner ohne Probleme mehrere Clients lauschen. Der Port auf den Clients ist somit auch wurscht.
Wenn man noch ganz profi ist macht man das mit Multicasts und dann entstehen auch nicht mehr Packete als beim Broadcast.

PS: natürlich muß noch eine deregistrierung über timeout o.ä. rein - nicht das nach einer Woche hunderte Packete ins leere gehen.

[Brüggendiek]

Hallo!

@Basilikum: Diese Möglichkeit kannte ich nocht nicht. Da sehe ich aber 2 Probleme:
1. Wie sage ich es meinem Indy? (bei TCP scheint es möglich zu sein, aber bei UDP?)
2. Was ist, wenn eine Fremdapplikation auf diesem Port läuft und Fehler produziert? Der gemeine Benutzer schiebt die Probleme doch auf das neue Programm, auch wenn das Alte mit dem Datenformat nicht klar kommt und statt Ignorieren des unverständlichen Pakets einen Fehler produziert. Bei individuellen Ports ist es leichter möglich, Doppelbelegung mit Fremdanwendungen zu vermeiden.


@fiasko: Das wäre doch Overkill. Außerdem: was passiert, wenn der Sender-PC neugestartet wird (und eine der Anforderungen nicht gespeichert wurde)?

Da bei mir zumindest die betroffenen Rechner dauernd laufen, wären Inkonsistenzen bei den Daten problematisch. Dann kommt wieder das regelmäßige Abgleichen.
Außerdem bleibt das Problem, daß der "Verwaltungsport" vom Anwender ausgesucht werden muß.

Hinzu kommt ja nochwas: Das Sender-Programm läuft ja beim augenblicklichen Konzept gar nicht dauernd! Es wird vom Internet-Zugang der Fritz!-Karte mit IP als Parameter gestartet. Dann sendet es seine Nachricht(en) ins Netz und beendet sich wieder - ohne jede Meldung auf dem Bildschirm. Lediglich bei Start ohne Parameter wird eine GUI aufgerufen, wo der Anwender Einstellungen vornehmen (und eine Test-Sendung veranlassen) kann.
Wenn das Programm dauernd läuft, muß ich wieder feststellen, daß schon eine Instanz läuft und dieser eine Nachricht schicken. Alternativ wären 2 Programme - eines, das die Ports verwaltet und ein Sende-Programm. Hier ergibt sich wieder das Problem der Daten-Konsistenz (wenn während der Verarbeitung einer Anforderung ein Connect erfolgt).

Die Problematik liegt darin, daß einige Ports (bis 1024) "well known" sind, also fest vergeben. Alles Andere ist Wildwuchs. Sogar die VoiceOverIP-Telefone benutzen nicht alle einheitliche Ports - lediglich 5060 scheint da einheitlich zu sein! Es ist also unverzichtbar, die Ports vom Anwender einstellen zu lassen. Wenn der Empfänger auf "seinem" Rechner einen Port als frei erkennt, kann dieser doch auf einem anderen Rechner belegt sein. Die möglichen Folgen habe ich ja schon am Anfang erwähnt.

Gruß

Dietmar Brüggendiek

[Basilikum]

Hallo...

die Klasse TIdSocketHandle kapselt die WinSock-API setsockopt, welche wiederum als Public-Properties (Client: Binding / Server: Bindings) von TIdUDP* zur Verfügung gestellt wird.

Das Wiederverwenden von Adressen funktioniert nur, sofern bereits die 1. Applikation, die den Port belegt, die Socket-Option (SO_REUSEADDR) entsprechend setzt. Insofern dürfte also keine "alte" Applikation zum Absturz gebracht werden können, da zu vermuten ist, dass diese SO_REUSEADDR nicht gesetzt hat.

Das Problem mit dem Port-Wildwuchs oberhalt 1024 dürfte vernachlässigbar sein - die Wahrscheinlichkeit, dass 2 Applikationen den selben Port verwenden, beträgt 15 ppm
Aber der Flexibilität halber sollte man den Port konfigurierbar auslegen, jedoch mit der Auflage, dass auf allen beteiligten PCs der selbe Port gewählt werden muss.

Ein anderer Ansatz wäre ein TCP-Server auf dem "Chef"-PC, zu dem die Informationsbezüger eine Verbindung aufbauen; bei Änderungen sendet der Chef-PC allen verbundenen Applikationen die Mitteilung. Bei diesem Ansatz wäre dann nur noch auf diesem PC ein freier Port zu suchen, der jedoch wieder bei allen Clients konfiguriert werden muss.

Eine etwas aufwändigere Lösung wäre, wenn man ein bestehendes Protokol verwendet - SNMP-Trap wäre beispielsweise denkbar; hier bietet Windows APIs an, so dass mehrere Applikationen daran teilhaben können (SNMP-Extensible-Agent / SNMP-Trap-Listener).

Gruss Basilikum

[fiasko]

Zitat von Brüggendiek:

@fiasko: Das wäre doch Overkill. Außerdem: was passiert, wenn der Sender-PC neugestartet wird (und eine der Anforderungen nicht gespeichert wurde)?

OK, ich bin gerade vom Gegenteil ausgegangen - der "Server" läuft immer und die Clients nicht.
Wenn die Sache nicht so zeitkritisch ist (jemand will sofort Telefonieren nachdem der Server neugestartet wurde) kann man das mit einer Ping-Pong Registrierung und timeouts lösen bzw. beim beenden sich die Daten merken und nach dem Start auf gut Glück ein paar Info Packete schicken das der Server neugestartet ist.

Zitat von Brüggendiek:

Außerdem bleibt das Problem, daß der "Verwaltungsport" vom Anwender ausgesucht werden muß.

In meiner ursprünglichen Idee muß nur auf einem Rechner ein Port festgelegt werden. Bei deiner ursprünglichen Idee mit Broadcasts muß der Port auf allen Rechnern gleich sein.

Zitat von Brüggendiek:

Hinzu kommt ja nochwas: Das Sender-Programm läuft ja beim augenblicklichen Konzept gar nicht dauernd! Es wird vom Internet-Zugang der Fritz!-Karte mit IP als Parameter gestartet. Dann sendet es seine Nachricht(en) ins Netz und beendet sich wieder - ohne jede Meldung auf dem Bildschirm. Lediglich bei Start ohne Parameter wird eine GUI aufgerufen, wo der Anwender Einstellungen vornehmen (und eine Test-Sendung veranlassen) kann.
Wenn das Programm dauernd läuft, muß ich wieder feststellen, daß schon eine Instanz läuft und dieser eine Nachricht schicken. Alternativ wären 2 Programme - eines, das die Ports verwaltet und ein Sende-Programm. Hier ergibt sich wieder das Problem der Daten-Konsistenz (wenn während der Verarbeitung einer Anforderung ein Connect erfolgt).

Ich dachte an einen Dienst der dauern im Hintergrundläuft und der neben Primitiven zur (De)Registrierung auch über eine zum senden der "Neue IP blah..."-Message verfügt. Das Fritz! Programm startet dann einfach einen kleines Helper Programm welches an den Dienst die Meldung absetzt und die dann rundgesendet wird.

Zitat von Brüggendiek:

...die Ports vom Anwender einstellen zu lassen. Wenn der Empfänger auf "seinem" Rechner einen Port als frei erkennt, kann dieser doch auf einem anderen Rechner belegt sein. Die möglichen Folgen habe ich ja schon am Anfang erwähnt.

Dieses Problem hat mein Ansatz aber nicht...


Grüße
Thomas

[Brüggendiek]

Hallo!

leider konnte ich mich bisher nicht weiter um das Problem kümmern.

Eine Lösung, bei der ein Sender-Programm immer laufen soll, kommt erstmal nicht in Frage. Router-Rechner sind in der Regel nicht die leistungsstärksten Maschinen und ich will sparsam mit Ressourcen umgehen. Deshalb sind auch keine Anmeldungen sinnvoll. Abgesehen davon, da muß ja auch netzweit ein Port gefunden werden, bei dem die Anmeldungen nichts Ungewolltes bewirken.

Die Entscheidung ist jetzt:
Es werden 3 Methoden gleichzeitig verwendet:

• Die Sender erhalten eine Portliste.
• Es gibt dedizierte Emfänger (wenn für eine Aktion ein Programm geschrieben werden muß, kann es auch gleich auf einem Port lauschen) und einen Universal-Empfänger, der eine Liste von Programmen starten kann.
• Mehrere Server auf einem Port werden unterstützt.

Da die sich jetzt ergebende Frage nur noch wenig mehr mit dem ursprünglichen Thema zu tun hat und auch in eine andere Sparte gehört, habe ich
hier einen neuen Thread eröffnet.

Gruß

Dietmar Brüggendiek