TCP "Chat" | Anfänger

Zitat

Wenn man auf einem PC zuerst den Server startet und dann den Client funktioniert es natürlich. Aber wie funktioniert das Ganze, wenn man es über 2 verschiedene PCs machen will?

Dann funktioniert es genauso, du musst halt nur die IP bei TCPListen vom Server verändern. Ich selber kann auch nur vermuten, warum man dies tun muss, aber ich habe dazu schonmal ein endlos langen Monolog geschrieben. Ah, ich habs über Google gefunden. Wie gesagt: Das ist nur eine Vermutung, aber als Modellvorstellung funktioniert es bis jetzt ganz gut:

Zitat von @night@

Über das Internet (nicht zu verwechseln mit dem Intranet - dem internen Netzwerk) musst du allerdings auf folgendes achten:
a) du musst beim Client die IP deines Routers angeben (http://www.wieistmeineip.de/). Im Intranet verwendet man die interne IP des Computers (z.B. 192.168.x.x).
b) du musst den entsprechenden Port beim Router freischalten (Stichwort: Port Forwarding. Google hat da ne ganze Meeennngge)

Bei mir ist die Funktion TCPListen generell die Fehlerquelle. Mit TCPListen wird dem Socket mitgeteilt, zu welcher IP er gehört. In den IP-Headern der Pakete ist immer eine Destination-IP angegeben. Diese Destination-IP wird beim Empfangen mit der IP von TCPListen überprüft. Das führt öfters zu merkwürdigem Verhalten bei mir, da es mehrere IP's gibt um einen Computer zu erreichen. Im Normalfall wäre dies 127.0.0.1 und die interne IP-Adresse.
Folgendes Beispiel:
Server führt aus: TCPListen("192.168.3.44") ;wartet auf interne IP
Client (auf deinem PC zum Testen) connected sich zu 127.0.0.1
Server: vergleiche 127.0.0.1 mit 192.168.3.44. Da die beiden IP's ungleich sind verwirft er das Paket.
Richtig:
CLient connected sich zu 92.168.3.44
Server nimmt Paket an, weil IP gleich

Alles anzeigen

Wenn du also im Intranet eine Verbindung herstellen willst, musst du als IP deine interne Verwenden (192.168.x.x). Wenn du über das Internet (achtung, da steht dein Router im Weg) verbinden willst, musst du auf jeden Fall die globale IP deines Routers beim Client angeben und AFAIK die interne IP beim Server. (Musst du halt Rumprobieren)
Hoffe es hilft, @night@

PS: Ich habe es mir nicht komplett angeguckt, aber die Tutorials von blog4it sind eigentlich immer gut. Klick

Zitat

eben nicht... Die IP bei TCPListen beim Server kannst du eigentlich immer auf @IPAddress1 lassen, egal ob intern oder öffentlich.

eben nicht... Wenn du bei TCPListen 127.0.0.1 angibst, dann wird es keinem anderen PC innerhalb deines Netzwerkes möglich sein zu dir zu connecten. Der zweite Teil deiner Aussage stimmt jedenfalls. Ich wollte nur mal versuchen das zu erklären. Vielleicht melden sich ja noch Andy oder Bugfix und lösen das Problem auf

€dit:

Zitat

Zu deinem Problem: Du musst natürlich einheitlich arbeiten. Entweder du connectest zum localhost und hörst den dann auch ab, oder du nimmst die intere IP im lokalen Netzwerk, aber das sind zwei verschiedene Dinge. Ich würde aber immer die Addresse im Intranet bei Server nehmen, da auch dein Router an diese Addresse weiterleitest und so kannst du den Server eigentlich unverändert lassen egal ob er im Intranet oder im Internet läuft

Genau das wollte ich ja auch sagen. Ich wollte halt nur mal wissen, ob meine Vermutung mit der Destination-IP im IP-Paket richtig ist. Mit der Aussage "Du musst halt nur dei IP ändern", wollte ich ihm darauf aufmerksam machen, dass man nicht die IP "127.0.0.1" für 2 verschiedene Rechner benutzen kann.

Zitat

Also ich hab das eben so verstanden, dass wenn du 127.0.0.1, was ja nichts anderes als localhost ist, abhörst dann kann ja auch nichts empfangen werden, dass für die lokale IP-Addresse bestimmt ist. Da ist daann deine Vermutung mit der Destination-IP gar nicht so falsch. Aber wie gesagt, dass Problem hat man erst gar nicht, wenn man nicht mit localhost sonder mit der NetzwerkIP arbeitet.

Jetzt haben wir uns glaub ich gedanklich getroffen Ich wollte halt nur mal wissen, warum das so ist und ob meine Vermutung stimmt.

Zitat

Im Prinzip ist der Server jetzt ja der Empfänger und der Client der Sender... also geht das dann so? Oder muss ich noch irgendwo was freischalten?

Server (to serve = zustellen): Nimmt Verbindungen an.
Client (client=Kunde): Fragt Verbindungen an

Was die danach miteinander machen ist egal Dein Server wartet per TCPListen und TCPAccept auf Clients, die sich verbinden wollen.
Dein Client fragt per TCPConnect eine Verbingung an.

Benutze bei der IP von TCPListen einfach immer @IPAddress1:

TCPListen(@IPAddress1, 1234)

@IPAddress1 beinhaltet immer deine interne IP (z.B. 192.168.x.x)

Die IPAdresse 127.0.0.1 bezeichnet immer deinen eigenen PC. Da gab es schon ein paar sehr interessante Verwechselungen.

Zitat

was soll ich eig. dann als Port angeben?

Eigentlich alle, aber alle Ports von 0-1023 sind standartisiert. Du kannst dort zwar auch deine Programme laufen lassen, aber es wäre unüblich.
Sinnvoller Kram zum Lesen

Zitat von Allwissendes Wikipedia

Ports sind 16-Bit-Zahlen (Portnummern) und reichen von 0 bis 65535. Ports von 0 bis 1023 sind reserviert[1] und werden von der IANA vergeben, z. B. ist Port 80 für das im WWW verwendete HTTP reserviert. Das Benutzen der vordefinierten Ports ist nicht bindend. So kann jeder Administrator beispielsweise einen FTP-Server (normalerweise Port 21) auch auf einem beliebigen anderen Port laufen lassen.

Wei schon gesagt: Es steht dir frei zur Wahl die Ports von 0 bis 65535 zu benutzen, aber es wurden zur Übersicht Standards festgelegt. (FTP-Server = Port 21; HTTP-Server = Port 80 => Allgemeinbildung FTW)
mfg @night@

Servous, habe mal vor ein Paar Wochen meinen kleinen Chat hier gepostet schau dir dass einfach mal an ist eigentlich relativ einfach geschrieben und gut zu verstehen Gruß Marvin

https://autoit.de/index.php?page=Thread&threadID=30088

Hallo life2play, dein Code ist nach meiner Meinung nicht gerade sehr gut programmiert, sollte aber funktionieren:
Server:

Client:

Wenn du beim Server die IP @IPAddress1 angibst, musst du sie auch beim Client ändern.
Ich benutze zum Debuggen oftmals Telnet, das ist ein mitgeliefertes Programm von Microsoft mit dem du TCP-Verbindungen aufbauen kannst. Es ist sehr simpel und schlicht, aber zum Testen reicht es mir meist.
Unter Windows 7 musst du es erst aktivieren. Dort wirst du auch das Problem erkennen. Da die Funktion TCPRecv() nicht wartet, wird dein Server direkt nach dem Verbindungsaufbau eine leere MsgBox ausgeben. Eine häufig verwendete Lösung ist eine Schleife:

Dies ist schonmal eine relativ gute Lösung. Wenn wir nun aber Telnet verwenden, werden wir sehen, dass absolut jeder getippte Buchstabe sofort versendet wird. Wenn wir Enter drücken, wird ein @crlf an deinen Server gesendet.
Lösung: Wir empfangen solange, bis ein @crlf im Paket enthalten ist.

Ich persönlich finde es gut, wenn jedes Paket mir @crlf abgeschlossen wird, weil so nicht mehrere Pakete in eine Variable kommen können. (Musst du nicht verstehen, aber irgendwann wirst du so komische Bugs bemerken die nicht umbedingt angenehm sind )
DEshalb ändern wir im Client:

Die zweite Lösung finde ich eleganter, aber das ist deine Sache. Nimm lieber das, was du verstehst.

€dit: Wie bin ich eigentlich von der Frage auf Telenet gekommen ? Egal, ich lass das mal hier stehen.