übers Internet "anklingeln" - dynamische IP - Client Server

AutoMit

Hallo,

wie kann ich am einfachsten folgende Idee umsetzen.

Ein Fenster, welches keinen Focus erhält, wenn es in den Vordergrund kommt, hat einen Button namnens "Klingel" und einen "Ende-Button".

Dieses Programm läuft auf beiden Windows 8 PCs.

Da die beiden Rechner eine dynamische IP haben, soll ein dyndns-Dienst wie test_mal_an.ddns.net verwendet werden.
Die Rechner verfügen jeweils über einen Router und eine Firewall.

Beim Mausklick auf den Button "Klingel" soll beim jeweils anderen Rechner über das Internet das AutoIt-Programmfenster in den Vordergrund topmost kommen.

Wie kann ich das erreichen?

Wie stelle ich sicher, dass die beim dyndns-Dienst hinterlegte IP die IP des Zielrechners ist und nicht eine, die bereits einem anderen PC zugeordnet ist? Wobei - wahrscheinlich würde die Anfrage nur ins Leere laufen, wenn der Zielrechner offline ist und ein anderer PC die IP hätte.

Ich suche eine Umsetzung, die so einfach wie möglich gehalten ist.

Habt Ihr dafür einen Programmschnipsel? Ich habe im Forum was zu Client / Server gefunden, allerdings waren die Dateien nicht downloadbar.

Danke

**alpines**

Hol dir nen Webspace oder such dir einen Dienst wo du Dateien hinterlegen kannst mit der aktuellen IP oder zwing deinen DNS Service dazu alle 5 Minuten die DNS zu refreshen um die aktuellste IP zu garantieren.
Das Problem beim direkten Anwählen ist das du die entsprechenden Ports im Router freigeben müsstest, wenn du aber das ganze auf einen externen Server auslagerst (z.B. auf einen Daten FTP-Server oder den vorhin angesprochenen Webdienst) kannst du eine Datei hinterlegen wo der Client in regelmäßigen Abständen prüft ob sich etwas getan hat.

AutoMit

DynDNS und Portforwarding sind auf beiden PCs eingerichtet und funktionieren bereits für andere Sachen.
Der Router sorgt dafür, dass die IP bei DynDNS aktualisiert wird.

(PS - ansonsten ist Deine Idee interessant, wenn man nichts in Firewall und Router freischalten möchte. Danke.)

Was mir fehlt, ist das Wissen, wie ich mit AutoIt eine Verbindung zwischen beiden PCs herstelle.

Also - Verbindung zu einem DynDNS-PC unter Berücksichtigung von Router (Port + Weiterleitung sind hardwareseitig drin) und einen Befehl schicken, der das AutoIt-Fenster in den Vordergrund holt, so dass der Anwender das "Klingeln" sieht / ggf. hört (Sounddatei abspielen).

**alpines**

Das sind die Grundlagen von Client / Server Kommunikationen, such einfach mal nach "autoit tcp client server". In der Hilfe ist sogar ein Beispiel vorhanden wie man einen Server erstellt und Nachrichten empfängt.
Socket erstellen, auf Clients warten, Clients verwalten und Clientsocket wieder sauber schließen, mehr ist das nicht.

AutoMit

Danke, ich schaue mir gerade die Befehle TCPSend() / TCPRecv() an. Hoffe - ich bin auf der richtigen Spur.

**alpines**

Hier haste du ein kleines Beispiel wie sowas aufgebaut sein kann, du kannst über den selben Socket auch an den Client Daten zurückschicken.

AutoMit

Das hilft! Danke! Selbst die Auflösung der DynDNS IP funktionierte auf Anhieb. Da steckt einiges in AutoItt

**alpines**

Hast du TCPNameToIp() genutzt oder einfach die DNS direkt angegeben? Wenn du es nicht verwendet hast solltest du es unbedingt nehmen da er bei hostnames meistens einknickt ohne TCPNameToIp().

BinDannMalWeg

Ich möchte an dieser Stelle anmerken, dass die Rückgabeparameter (speziell die Error/Extended Werte) der TCPSend/-Recv Funktionen von Autoit seit geraumer Zeit verbuggt sind. Genauer: Es lässt sich nicht richtig feststellen ob eine Verbindung abgebrochen bzw. unterbrochen wurde. Die Funktionen liefern einfach nicht das zurück was in der Hilfe dokumentiert ist. Dieses Verhalten ist in der Stable sowie in der Beta vorhanden und besteht auch schon seit einigen Versionen, obwohl die Changelogs behaupten, dass die Fehler behoben worden wären.

**alpines**

Zitat von Christoph54

Ich möchte an dieser Stelle anmerken, dass die Rückgabeparameter (speziell die Error/Extended Werte) der TCPSend/-Recv Funktionen von Autoit seit geraumer Zeit verbuggt sind. Genauer: Es lässt sich nicht richtig feststellen ob eine Verbindung abgebrochen bzw. unterbrochen wurde. Die Funktionen liefern einfach nicht das zurück was in der Hilfe dokumentiert ist. Dieses Verhalten ist in der Stable sowie in der Beta vorhanden und besteht auch schon seit einigen Versionen, obwohl die Changelogs behaupten, dass die Fehler behoben worden wären.

Da gibt seinen kleinen Trick, man sendet umgekehrte Heartbeats. In Java hab ich momentan das Problem das man vom BufferedReader nicht feststellen kann ob der Client die Verbindung "sanft" oder "gekillt" hat und deswegen nutze ich da einen kleinen Trick indem ich in regelmäßigen Abständen an den Clienten einen bestimmten String sende. Sollte der String erfolgreich versendet werden ist die Verbindung noch da, sollte der String nicht gesendet werden wurde die Verbindung auf der anderen Seite beendet.

**autoBert**

Zitat von Christoph54

Ich möchte an dieser Stelle anmerken, dass die Rückgabeparameter (speziell die Error/Extended Werte) der TCPSend/-Recv Funktionen von Autoit seit geraumer Zeit verbuggt sind. Genauer: Es lässt sich nicht richtig feststellen ob eine Verbindung abgebrochen bzw. unterbrochen wurde. Die Funktionen liefern einfach nicht das zurück was in der Hilfe dokumentiert ist. Dieses Verhalten ist in der Stable sowie in der Beta vorhanden und besteht auch schon seit einigen Versionen, obwohl die Changelogs behaupten, dass die Fehler behoben worden wären.

dann mach ein Bugticket auf.

BinDannMalWeg

Zitat von alpines

Das ist leider nicht übertragbar, da auch TCPSend() bei einem TCPCloseSocket() nicht bemerkt, dass die Verbindung tot ist. Da müsste man dann schon einen Ping hin und her senden.

Zitat von autoBert

dann mach ein Bugticket auf.

Danke, dass ich da nicht selbst drauf gekommen bin ist beschämend. Ich erstelle mal eins...

Tut mir leid, dass ich diesen Thread verwüstet habe.

**alpines**

Zitat von Christoph54

Das ist leider nicht übertragbar, da auch TCPSend() bei einem TCPCloseSocket() nicht bemerkt, dass die Verbindung tot ist. Da müsste man dann schon einen Ping hin und her senden.

Ein Ping entscheidet nicht ob die Verbindung tot ist oder nicht, ich kann ja die Verbindung "killen" und dennoch bleibt der Ping unverändert.
Ich hatte komischerweise bisher nie Probleme mit den Rückgabewerten der Funktionen. Hast du ein Beispiel wo du das reproduzieren kannst?

BinDannMalWeg

Zitat von alpines

Ein Ping entscheidet nicht ob die Verbindung tot ist oder nicht, ich kann ja die Verbindung "killen" und dennoch bleibt der Ping unverändert.Ich hatte komischerweise bisher nie Probleme mit den Rückgabewerten der Funktionen. Hast du ein Beispiel wo du das reproduzieren kannst?

Was ich mit Ping meine ist kein normaler "Ping" sondern das hin und hersenden eines Pakets über die zu testende Verbindung. Dies ist der einzige Weg wie man momentan testen kann ob die Verbindung noch besteht. Mit den angehängten Testscripts solltest du das Problem reproduzieren können. Starte zunächst die Server.au3 und anschließend die Client.au3. Wenn die Client.au3 durchgelaufen ist, kannst du die Server.au3 auch abschießen. In der erstellten log.txt sollte dann (sofern beim Schreiben keine Kollisionen aufgetreten sind) am zeitlichen Ablauf erkennbar sein, dass TCPRecv() Mist zurückgibt.
Schließt man das Socket auf der Seite des Clients normal, so geht beim Server @extended auf den Wert 1 (völliger Quatsch). Schließt man das Socket nicht und schießt direkt TCP ab, geht @error auf den Wert 10054.

Homer J. S.

BinDannMalWeg:
Ich habe dein Testskript mal getestet mit Version 3.3.14.2. Im Anhang findest du das Logfiles. Ich sehe da auch die von dir beschribenen Probleme.
Allerdings hatte auch einige schwirgkeiten seit Version 3.3.14.2 (vorher 3.3.12.0).

Hier ein Auszug eines Skriptes von mir mit der Version 3.3.12.0:

AutoIt

...
$TCP_ACCEPT=-1
Do
	$TCP_ACCEPT=TCPAccept($TCP_LISTEN)
Until $TCP_ACCEPT<>-1
Sleep(50)
$TCP_RECEIVE=''
While 1
	$TCP_RECEIVE&=TCPRecv($TCP_ACCEPT, 2048)
	If (@error) Then ExitLoop
WEnd
If ($TCP_RECEIVE<>'') Then
	ConsoleWrite('RECEIVE: ' &$TCP_RECEIVE &@CRLF)
...

Alles anzeigen

...hier der Auszug des Skriptes mit der selben funktion unter Version 3.3.14.2:

AutoIt

....
$TCP_ACCEPT=-1
Do
	$TCP_ACCEPT=TCPAccept($TCP_LISTEN)
Until $TCP_ACCEPT<>-1
Sleep(50)
$TCP_RECEIVE=''
While 1
	$TCP_RECEIVE&=TCPRecv($TCP_ACCEPT, 2048)
	If ((@error) Or (@extended=1) OR StringInStr($TCP_RECEIVE, @CRLF&@CRLF)) Then ExitLoop
WEnd
If ($TCP_RECEIVE<>'') Then
	ConsoleWrite('RECEIVE: ' &$TCP_RECEIVE &@CRLF)
...

Alles anzeigen

Mit dem @CRLF&@CRLF erkenne ich das Ende der gesendeten Daten.

Vieleicht hilft dir das ja weiter?!

Gruß
Homer J. S.

AutoMit

vielen Dank für Eure zahlreichen Ideen und Vorschläge und Vorschläge. Ich habe das Thema auf „grün“ gesetzt, und bin beim ausprobieren

So richtig kann ich erst weiter testen, wenn mein "Gegenüber" wieder aus dem Urlaub zurück und an seinem PC ist.

**alpines**

Zitat von AutoMit

vielen Dank für Eure zahlreichen Ideen und Vorschläge und Vorschläge. Ich habe das Thema auf „grün“ gesetzt, und bin beim ausprobieren

So richtig kann ich erst weiter testen, wenn mein "Gegenüber" wieder aus dem Urlaub zurück und an seinem PC ist.

Wieso denn? Wenn du unbedingt einen anderen Rechner brauchst nimm eine VM dafür. Da kannst du vom Host auf die VM und andersherum zugreifen, oder das ganze global (klappt auch mit VM.)

AutoMit

Ein interessanter Gedanke - VM. Ich sehe die meisten Hürden beim Router und der Portweiterleitung und hier weiß ich nicht, wie ich das in einer VM virtualisieren kann. Gibt es sowas?

**alpines**

Router und Portmapping sind Sachen wo du dich zwei Minuten in das Webinterface vom Router einloggst, die Ports freigibst und fertig, mehr musst du von dort aus nichts machen.