Zitat von
Assertor:
Hi,
noch eine Überlegung: Warum drehst Du das ganze nicht einfach um? Die Software auf den Clients sendet solange einen UDP Broadcast, bis der Server sich verbindet. Der Server braucht dann nicht mit einem Broadcast zu antworten, sondern kann sich direkt z.B. per
TCP zum Client verbinden - ohne jemals einen eigenen Broadcast senden zu müssen.
Das schaut für mich irgendwie schöner und effektiver aus.
Zusätzlich:
- Das ganze natürlich mit Fehlerbehandlung bei C/S
- Einer Client-Liste, die Du auf der Serverseite verwaltest (mit automatischer Entfernung, wenn über Zeitraum x der Client nicht erreichbar war und limitiert auf y Einträge)
- Die Broadcasts in Intervallen (resourcenschonender), am Anfang z.B. alle 5 Sekunden, dann imme größere Abstände
- Damit der Benutzer nicht ewig warten muß noch ein Start Broadcast vom Server, damit die Clients Ihr Broadcast-Sendeintervall wieder auf 5 Sekunden setzen
Ich glaube, so würde ich das machen. Keine Konfiguration wegen der Multi-Interface-Geschichte.
Gruß Assertor
Also entweder hast du jetzt einen Denkfehler oder ich hab dich nicht richtig verstanden.
Es gibt keinen wirklichen Server, alles ist dezentralisiert!
Aktuell läuft das ganze so ab:
Client1 startet und sendet somit einen Broadcast "Ich bin Client1, gibt es noch andere Clients?"
Client2 empfängt diesen und sendet direkt zu Client1 das Antwortpacket (UDP) "Ja mich gibt es auch, ich heiße Client2"
Genau bei dem Antwortpacket von Client2 ist jetzt das Problem. Auf welche
IP soll er dieses nämlich hinschicken? Da er nur die Soure-
IP von dem Client über den Broadcast kennt muss er das Packet auf diese senden.
(Solche zusätze das es in einem bestimmten Intervall den Boradcast sendet habe ich schon implementiert)