Server mit GUI

[Eichelhäer]

Hallo,

ich habe das grundsätzliche Prinzip eines Server Client Aufbaus verstanden und kann mit der Kommunikation der beiden umgehen.
Bisher hatte ich meinen Server ohne eine GUI implementiert und das lief auch gut wie gesagt.

Nun möchte ich eine GUI für den Server erstellen, aber diese wird (sehr vereinfacht) nur angezeigt, wenn ein Client sich verbinden möchte.

Ich habe es sowohl mit der TCP-Variante mit server.accept als auch mit der UDP Variante mit server.receive versucht. Die beiden Varianten befinden sich jeweils in einer while-Schleife und warten auf einen Client.

Es geht mir hauptsächlich um so etwas wie einen Handshake, also client fragt "darf ich mich verbinden", daraufhin antwortet der server "ja" und die Verbindung wird von der clientseite aus mit client.connect aufgebaut (also nicht von server Seite!!!!).

Ich habe mir auch überlegt mit der sotimeout methode zu arbeiten und durch regelmäßiges neustarten des timers immerwieder zu prüfen (also auf server seite), ob sich ein neuer client verbinden möchte, allerding lässt sich diese methode meines wissens nicht wieder neustarten, um bei ablauf des timers auf clientmessages reagieren zu können.

Die Methoiden des DatagrammSockets und des serversockets sind zwar hilfreich, wie z.B. isClosed oder isConnected aber helfen mir nicht immer wirklich weiter.

Also um meine Frage nochmals zusammenzufassen, wie baut man die "handshakes" mit vielen möglichen clients auf, sodass auf client gehorcht und meine GUI angezeigt wird.?

 

[LimDul]

Ich bin mir nicht sicher, ob man das verbinden auf TCP/IP Ebene abfragen kann. Das erfolgt auf einer tiefen Ebene, wo man vermutlich nicht direkt eingreifen kann.

Sprich, was du machen müsstest:

• Jeden Client per accept akzeptieren.
• Einen eigenen Thread dafür starten, die GUI informieren
• Die GUI sagt Ja/Nein
• Bei Ja den Socket entsprechend weitergeben an den eigenen Business-Code
• Bei Nein den Socket schließen.

 

[Eichelhäer]

Ja, aber was mach ich, wenn der Server läuft und noch kein Client akzeptiert wurde? Oder kann die Server GUI nur dann aufploppen wenn mindestens einClient sich verbinden möchte?

 

[KonradN]

Ich verstehe das genaue Szenario so noch nicht wirklich.

Deine Server Applikation läuft also mit einem angemeldeten User, z.B. mit einem Icon im Systray.
Wenn Du ein Verbindungsversuch kommt, dann soll ein Fenster aufgehen? Wo ist das Problem? Du kannst mit Swing ein JFrame erstellen und sichtbar machen. Das öffnen eines Fensters macht also doch kein Problem, oder?

Wozu der "Handshake" für den Verbindungsaufbau? Was willst erreichen? Du kannst auch einfach eine tcp/ip Verbindung aufbauen und dann ist alles Bestandteil des Protokolls, das danach kommt. Das ist doch das, was üblich ist, z.B.:

• Es wird eine Tcp/Ip Verbindung geöffnet und dann findet ein SSL oder TLS Handshake statt.
• Es wird eine Verbindung geöffnet und dann findet eine x-beliebige Sache statt, die erwartet wird. Das kann dann ein Login sein oder irgend etwas spezielles, das ein Protokoll vorsieht.

Also was versprichst Du Dir davon, dass Du da irgendwas mit UDP Paketen machst, ehe Du eine tcp/ip Verbindung aufbaust?
Das klingt für mich erst einmal alles relativ wenig durchdacht.

Informationen auswerten, ehe man die Verbindung annimmt:
Java bietet hier nur relativ "high level" Sockets. Da ist eine Auswertung von Daten (z.B. IP Adresse des Clients) nicht direkt möglich. Nach dem Aufruf von accept() bekommst Du aber ein Socket dessen Endpunkt Du prüfen kannst. Wenn die Verbindung von einer IP kommt, mit der Du keine Verbindung willst, dann kannst Du die Verbindung z.B. wieder schließen.

Wenn es Dir hier um eine Sicherheit gehen sollte um den Server z.B. vor Portscans zu verstecken, dann ist die erste Frage: Gehört dies in die Anwendung selbst rein? Da gibt es dann für Betriebssysteme eigene Lösungen, die über eine Firewall Verbindungen verhindert und dann nach z.B. speziellen UDP Paketen einen Port gezielt freischalten. Das ginge sogar mit Java - da würde man dann nur auf den udp Port hören um dann z.B. gezielt Befehle auszuführen um die Firewall zu schalten. Da würde man aber unter dem Strich auf eine Firewall vertrauen. Aber da passt dann irgendwie nicht, dass Du einen Client mit GUI haben willst...

Server und GUI: Hier macht es evtl. Sinn, das alles etwas zu trennen. Du kannst eine Server Anwendung machen, die halt irgendwelche Server Dinge anbietet. Du hast dann zusätzlich einen Client mit GUI, mit dem der Nutzer den Server auch steuern kann. Das kann dann sowas wie ein Admin Client sein. Der Server könnte auf der ip 127.0.0.1 auf Admin Client Verbindungen hören und so ... Dann kann der User sich auch mal abmelden, ohne dass der Server offline wäre. Der Server selbst könnte als Service beim Start des Systems direkt gestartet werden ... Das nur um mal ein paar Ideen in den Raum zu werfen....

Vielleicht kannst Du einfach einmal ausführen, was denn das eigentliche Ziel ist? Teilweise habe ich das Gefühl, dass wir hier ein xy Problem haben. Du hast Problem x, hast dafür y als Lösung erkoren und hast nun mit y Probleme. Evtl. können wir bei x deutlich besser helfen um eine vernünftige Lösung zu bekommen?

 

[mihe7]

Ich würde auch sagen, dass das protokollmäßig getrennt sein sollte. D. h. es wird eine TCP/UDP/sonstwas-Verbindung aufgebaut und dann findet ein "Handshake" in Deiner Anwendung statt, z. B.:

Server erwartet als erstes mal eine "CONNECT"-Nachricht vom Client. Ist die eingegangen, kann der Server die Verbindung akzeptieren (antwortet z. B. mit "OK") oder ablehnen (anwortet z. B. mit "REJECTED <cause>") und beendet dann die Verbindung.

Wie auf der serverseite die Entscheidung getroffen wird, spielt dabei keine Rolle. Sprich: ob das nun per Zufall läuft, der Server erstmal seinen Namen tanzt oder per GUI den Anwender fragt bzw. den Verbindungsaufbau abbrechen lässt, ist völlig egal.