Konfiguration für einen Dienst

[Bummi]

@himitsu

schöner sicher, das hier geschilderte Szenario geht aber davon aus daß man gar nicht weiß wen man fragen könnte ...

[himitsu]

Ob der Server ständig alle anderen Rechner fragt, ob da zufällig grade ein Client ist, welcher was von ihm will,

oder ob der Client einmal alle anderen Rechner fragt, ob dort ein Server rumgammelt, der mit einem reden will...



Soeinen großen Unterschied kann ich da erstmal nicht erkennen. :gruebel: (außer der Häufigkeit der Rundrufe)

[BUG]

Ein Problem besteht darin, wenn die 2000+ Clients gleichzeitig nachfragen wollen (weil der Server kurz weg war) und dann alle das Netz zubrüllen.

[mjustin]

Zitat:

Zitat von himitsu (Beitrag 1186262)

Wäre es da nicht andersrum viel schöner?

- der Server lauscht die ganze Zeit nur rum
- kommt ein Client, sendet er einen Broadcast "hallo Server, wo bist du?"
- und dann antwortet der Sever dem Clienten und sie bauen die Verbindung auf

So müßte niemand ständig irgendwas rumspammen, in der Hoffung es könnte eventuell irgendwann mal jemand was wollen.

Der Client muss dazu allerdings einen Port öffnen, da es sonst nicht möglich ist, dass der Server dem Client antwortet. Das ist wegen notwendiger Firewallkonfiguration in der Praxis aufwendiger (2000 Clients müssen dann den richtigen Port in ihrer lokalen Firewall öffnen)

[hesch21]

Wirklich besten Dank für die Unterstützung

zu MJustin: Ja, das mit der Multicastgroup ist mir schon klar. Eine 'normale' IP geht auch gar nicht. Aber trotzdem muss das Ding zusammen mit dem Port fest verdrahtet sein wie in Deinem Beispiel in Deinem Blog oder irgendwo hinterlegt sein.
Und zu Deiner Antwort an himitsu: Das mit der Firewall würde mich nicht interessieren. Meine Software wird ausschliesslich in LANs betrieben und da ist keine Firewall aktiv. Sonst hätte ich das Problem auch mit der 'normalen' Applikation, welche vom Client-Programm aus über eine Indy-TCPClient-Kompo eine Verbindung zum Server aufbaut.

zu Bummi und himitsu: Also das müsste im Prinzip schon gehen. An sich sind ja so oder so beim Casting die Rollen vertauscht. Eigentlich ist der Server nicht wie gewohnt der Listener sondern der 'Sender' und der Client spielt Listener. Wenn ich nun dem Server-Programm diese Listner-Funktion übertrage, also die Client-Kompo einbinde, müsste das Client-Programm einfach beim Start irgend etwas über die Cast-Server-Kompo senden. Aber wie bekomme ich dann die IP und den Port vom Server-Programm zurück? Ich habe noch nicht geshen, ob da noch ein Dialog möglich ist.

[Bummi]

Du schickst einfach IP und Port als Message in dem Broadcast

[mjustin]

Zitat:

Zitat von hesch21 (Beitrag 1186322)

zu MJustin: Ja, das mit der Multicastgroup ist mir schon klar. Eine 'normale' IP geht auch gar nicht. Aber trotzdem muss das Ding zusammen mit dem Port fest verdrahtet sein wie in Deinem Beispiel in Deinem Blog oder irgendwo hinterlegt sein.

Ja, ich verstehe es auch so dass die Group ein frei definierter Filter ist, damit man nur die Nachrichten erhält die sich auf den eigenen Server beziehen. Es kann theoretisch zu Kollisionen kommen wenn im gleichen Netz mehrere Server sich selber ankündigen und zufällig die gleiche Group-ID verwenden.
ActiveMQ setzt in den UDP String daher noch einen Text (Broker/Version) an den Anfang anhand dessen man sicher sein kann, einen Message Broker unter der IP zu finden. Das ist auf jeden fall leichter (in der Wartung) als zum Beispiel bei Clients die zur Kommunikation mit dem Server vorübergehend auch einen Server-Port öffnen wollen, jeweils einen anderen Port zu konfigurieren falls der Standardport bereits belegt ist.