Client sendet an Server nicht übers Inet

127.0.0.1 ist locahlost d.h. : kein anderer Rechner kann connecten. Versuch mal

@IpAddress1

Wie schon oft und jede Woche von neuem erklärt:

Im Server: TCPListen auf @IPAddress1 - zB 192.168.2.5
Außerdem: Im Router des Servers Portforwarding einstellen - eingehende Verbindungen auf Port 4321 (bei deinem Beispiel) auf die Lan-Ip des Servers weiterleiten, in meinem Beispiel 192.168.2.5

Im Clienten musst du dann auf die Wan-Ip des Servers connecten.
Kannst du beim Server mit _GetIp() nachsehen.

Das ist alles.
Meistens scheitert es eben am Port-Forwarding oder 'ner überempfindlichen Firewall

Edit:
Das wären die Einstellungen für WAN - Wide Area Network. Also übers Internet.
Wenn beide Computer im Lan sind ist kein Port-Forwarding notwendig und der Client kann einfach auf die Lan-Ip des Servers connecten.

Du kannst mit TCPNameToIP den PC Namen zu einer IP auflösen.
Dann brauchst du dir keine Zahlen zu merken nur den Namen.

PS: Der PC Name ist in @Computername

Zitat von BadBunny

also fals der server auf einem andere computer ist , dann ist ja auch die ip anders und der client weiss die nicht von dem neuen computer. Wie mache ich das?

wenn du die nicht weisst, kannst du auch nichts senden. Frage also deinen Bekannten ob er dir sie gibt.
PS.: Übrigens werden IP's vom Provider (meistens) dynamisch vergeben, d.H. bei ersten Verbinden mit dem INet, üblicherweise wird nach spätesten 24 Stunden die Verbindung getrennt und reconnected was zur Folge hat, dass eine neue IP vergeben wird. Google einmal nach DynDns,

mfg (Auto)Bert

Und noch etwas:
Die Funktion _GetIP ist natürlich so geschrieben, dass sie bei jedem Funktioniert. Heißt: Sie arbeitet über https://autoit.de/www.whatismyip.com.

Legt man sich einen eigenes PHP Script auf einem Freehoster an, ist man in der Regel mit einem Geschwindigkeitsvorteil dabei. Auch der verbrauchte Traffic wird minimiert, was vor allem Modemnutzer (ja die gibt es immernoch), oder Leuten mit UMTS-Verbindungen auffallen wird.

Auch wenn die Unterschiede minimal sind : Die Summe macht's

So ein PHP Script ist nichtmal lang oder unnötig kompliziert

<? echo getenv('REMOTE_ADDR'); ?>

Copy 'n' Paste und es funktioniert. Eine Arbeit von 5 Minuten - der User wirds einem danken.

Also denn sowas

HttpSetUserAgent("Firefox")
$IP = InetRead("### Webpfad zur PHP Datei###")
ConsoleWrite(BinaryToString($IP) & @CRLF)

<?php
echo $_SERVER['REMOTE_ADDR'];
?>

Einfach den Inhalt von dem PHP Datei auf einen Webspace platzieren und dann den Pfad bei ### Webpfad zur PHP Datei### eintragen dann müsste das Funzen

Zitat von SEuBo

oder Leuten mit UMTS-Verbindungen auffallen wird.

UMTS wäre schön, bekomme nur Verbindungen mit GPRS (derzeit ca. 12 KB/s down)

Zitat von SEuBo

Und noch etwas:
Die Funktion _GetIP ist natürlich so geschrieben, dass sie bei jedem Funktioniert. Heißt: Sie arbeitet über https://autoit.de/www.whatismyip.com.

_GetIp liefert mir meine Ip-Adresse zurück, wie sie auch von IpConfig zurückgegeben wird. https://autoit.de/www.whatismyip.com liefert eine IP eine völlig andere zurück (warscheins die von TMobile) aber nicht aus dem Nr.-Kreis meines Standardgateways,

mfg (Auto)Bert

Wozu gibt es eigentlich eine Hilfedatei mit funktionierenden Beispielen zu Client/Server?
Dort gibts ein Clientscript und ein Serverscript, welche ohne Änderungen auf jedem Rechner im internen Netz lauffähig sein sollte.
Schritt für Schritt-Anleitung:
A) Beispielscript zu

TCPRecv()

(das ist der Server) zu einer EXE-Datei kompilieren und diese EXE starten! Ggf die Firewall anweisen, den Server zuzulassen oder ganz abschalten!
B) Beispielscript zu

TCPSend()

(das ist der Client) auf demselben Rechner starten.Text im Client eingeben, nach einem Enter sollte der eingegebene Text im Serverfenster erscheinen.
Wenn das NICHT so ist, dann ist entweder die Firewall das Problem (abschalten) oder die Netzwerkverbindung. Wenn I-net geht, ist das ein Layer-8-Problem, da hilft dann ab und zu, mehrmals heftigst den Kopf gegen die Türzarge zu schlagen, danach noch mal bei A) anfangen....

Sollte die Client/Serververbindung auf dem eigenen Rechner funktionieren, dann kann man anfangen im internen Netz zu testen. Ich gehe davon aus, daß eine funktionierende Netzwerkverbindung besteht, d.h. jeder der Rechner kann den anderen im Netz "sehen" und Daten austauschen.
Dazu die kompilierte SERVER.EXE auf einem anderen Rechner im internen Netzwerk starten, ggf Firewall deaktivieren.
Im Rahmen des Serverfensters erscheint eine IP-Adresse, z.B. 192.168.100.105.
Diese Adresse nun im CLIENT-Script (auf dem lokalen Rechner) in Zeile 18 eintragen:

Local $szIPADDRESS = "192.168.100.105"

und Script starten.
Sollte eine Fehlermeldung erscheinen....die Türzarge einige Male heftig mit dem Kopf, ihr wisst schon...das macht wach!
Falls keine Fehlermeldung erscheint, sondern der im Client eingegebene Text im Serverfenster erscheint, gehts weiter, Test im Internet.

Dazu ist es zunächst sinnvoll, sich bei einem der DNS-Service-Provider (z.B. DynDNS) eine kostenlose, "personalisierte URL" (z.B. Hoppelhase.dyndns.org) zu besorgen, unter der man dann auch bei wechselnder IP erreichbar ist. Das muss für die ersten Tests nicht unbedingt sein, erleichtert später aber vieles. Diese URL wird z.B. im Router eingetragen und dieser meldet eine vom Internetprovider neu vergebene IP an den DNS Provider. Wenn jetzt jemand eine Verbindung zu eurem Rechner aufbauen möchte, muß er nicht jeden Tag eine andere IP mitgeteilt bekommen, sondern merkt sich nur die URL Hoppelhase.dyndns.org. Diese wird bei einer (automatischen) Anfrage an einen Nameserver dann zu eurer zur Zeit aktuellen IP aufgelöst.

Weiter zum Thema Client/Server-Test im Internet:
Das kompilierte SERVER-Script auf dem lokalen Rechner starten. WICHTIG! Bei Verwendung eines Routers muß dem Router mitgeteilt werden, an welchen Server er die Datenpakete im internen Netz weiterleiten soll! Ist dem Router das Ziel unbekannt, so verwirft er die Daten einfach, und unser Server wartet ewig....
Damit der Router unseren Server "kennt", muß dieser mit (lokaler) IP und dem entsprechenden PORT in eine Liste eingetragen werden. Hat man so etwas noch nie gemacht, ist ein Blick ins Handbuch des Routers angesagt.In der Routerkonfiguration wird man u.U. bei "Port Forwarding" fündig und trägt dort die benötigten Daten ein. Bei meinem Router heißt der Menüpunkt für das forwarding "Firewall Rule".
ACHTUNG! Bei den meisten wird im Router ein DHCP-Serverdienst laufen, welcher den neu angemeldeten Rechnern im internen Netz eine mehr oder weniger zufällige IP-Adresse zuteilt! Daher sollte man, wenn man Serverdienste (HTTP/FTP/AutoIt-Server) im Internet bereistellt, dem Rechner, auf dem dieser Serverdienst läuft, eine FESTE IP-Adresse zuteilen. Ansonsten muß man u.U. täglich mehrmals seinen Router umkonfigurieren, damit dieser immer die aktuelle IP des Server-Rechners hat, und wer will das schon....
Für das "Port forwarding" gibt es jede Menge Anleitungen, falls es nicht klappt....Kopf....Türzarge....BÄÄÄÄM....das klärt den Blick!

Damit der Client sich mit dem Server verbinden kann, muss man die IP-Adresse des Servers (bzw. des Routers auf der Serverseite) herausfinden. Am einfachsten geht das, indem man VOM SERVER AUS eine Seite im Internet, wie z.B. https://autoit.de/www.wieistmeineip.de aufruft. Die dort angezeigte IP ist idR die IP, unter der der Router des Servers erreicht wird. Diese IP wird dann im CLIENT-Script in Zeile 18 eingetragen. Wie die dorthinkommt? Na per Email, SMS, Telefon, Briefpost, Aufschreiben und hintragen oder wie auch immer.....
Das ist der Grund für das Einrichten einer URL (Hoppelhase.dyndns.org) bei einem DNS-Service-Provider. Dann muss man ins Clientscript statt der ServerIP nur Hoppelhase.dyndns.org eintragen, und bei einer Verbindung wird (nach automatischer Anfrage an den DNS) die "richtige", d.h zzt. aktuelle IP des Routers auf der Serverseite genutzt.
Der Client muss den Router NICHT umkonfigurieren! In der Regel lässt ein Router alles von drinnen nach draussen durch! Eine Firewall blockiert auch (normalerweise) diesen Weg, daher im Zweifelsfall ausschalten.

Wenn nun Serverseitig richtig "geforwardet" ist, sämtliche IP-Adressen stimmen und die Türzarge endlich aus Kleinholz besteht, dann sendet auch der Client fleissig seine Daten ohne Probleme an den Server!
Wenn das alles funktioniert, DANN und erst DANN werden Scripte um/neu-geschrieben und auf eigene Bedürfnisse angepasst....und wenn die dann nicht funktionieren, dann liegt das nicht an der Technik, sondern am Unvermögen des Coders oder dessen Lernresistenz! In der Hilfe steht alles wichtige, weiterhin gibts massig funktionierende Scriptbeispiele. Somit gibt es keinen Grund mehr, "TCPIP funktioniert nicht"-Threads aufzumachen!

Zitat

das wichtigste daran ist eigentlich, die firewall weg zu machen

Ahh, da bluten mir die Augen, relavante wichtige Ports öffnen verstehe ich ja, aber ganz aus.
Wohl eher nicht. Hast Du ne Ahnung was Dich der Spass kostet wenn dein Server gehackt wird und damit Blödsinn anghestellt wird.
Da sind Mailbots noch mit harmlos und das kann auch schon weh tun. Immer nur soviel öffnen wie nötig.
Und auch telnet via Inet ohne VPN halte ich für keine gute Idee. ssh gibt es schliesslich auch für Windows.

An sonsten, schöne Erklärung, wie es geht.