IdTCPClient <> IdTCPServer: Verbindungsproblem

[DataCool]

@Z4ppy:
Die Frage von "inherited" ist berechtigt, die Vorgehensweise die Du beschreibst würde 2 Server vorraussetzen
und wie ich oben schon beschrieben habe ist das "flüssiger als Wasser".
Es reicht von Du eine Verbindung vom Client zum Server aufbaust.
Wenn jetzt der Server was an den Client senden will machst Du das über die schon bestehende Connection,
d.h. der Server MUSS NICHT nochmal irgentwohin verbinden, die Verbindung zum Client steht ja schon.
Im Lan sollte das ganze von allein funktionieren, geht die Verbindungs übers Inet dann liegt der Server zu 99,9% hinter einem Router und in diesem muss per Port-Forwarding Dein Port freigeschaltet werden. Oder Du versucht via UPNP automatisch einen Port im Router zu Öffen,
falls jemand dazu eine Lösung hat lasst Sie mich wissen ;-)

@Muhkuh:
Alleinherrscher hat recht alle Aktionen innerhalb des OnExecute des TIdTcpServer laufen in seperaten Threads,
in Indy9 pro Verbindung ein seperater Thread, in Indy10 etwas eleganter aber immer noch Threads.
Deshalb müssen alle Zugriffe auf die VCL/GUI syncronisiert werden.
Klar geht es auch ohne syncronize, aber nur 90 mal von 100 Versuchen ;-)
Tendenz steigend umso mehr Verbindungen/Clients es werden.

Greetz Data

[Z4ppy]

Jaja, ich weiss jetzt, dass es geht, trotzdem würde ich gern wissen, warum mein Code net geht ;) (Auch wenn ichs wohl so lösen werde, wie du gesagt hast)

MfG Z4ppy

PS.: wäre dir noch dankbar, wenn du mir nen Link wegen String von IdTCPServer => IdTCPClient geben könntest... Ich find immer nur das, was mir allerdings net viel weiterhilft :(

[EDIT] Ich hab noch ein Argument für die Sache mit Client auf beiden Seiten... Wenn ich nämlich auf der einen Seite nur den Server laufen hab, muss ich beim Senden der Nachrichten/Dateien immer überprüfen, ob der User nun auf der Seite des Clients oder auf der des Servers ist. Das wirkt sich vermutlich nicht gerade positiv auf die Perfomance aus... Wenn ich das mit 2 Clients mache, kann ich einfach mit den Funktionen von TIdTCPClient die Strings/Streams verschicken ;)

[DataCool]

Hi,

Dein Code geht nicht weil dieser kompletter Schwachsinn ist.
Ich verstehe die Idee von Deiner Beschreibung her :

- Client A verbindet sich zu Server B
- Server B liesst IP aus und ClientB verbindet sich zu Server A

Bei dem Szenario sind aber 2 Server und 2 Clients notwendig.
Über Sinn und Unsinn dieser Methode will ich mich ned äußern.
Für diese Methode übers Internet müßten beide Clients einen offenen Port in der Firewall haben.

Dein genauer Fehler liegt darin das Du innerhalb des TcpServer im OnExecute,
versucht den client der gerade mit deinem server verbunden ist,
erneut zu verbinden, so wie Du es machst würde er theoretisch versuchen
sich mit dem selben Server zu verbinden mit dem er gerade verbunden war :shock:
Logikfehler Deinerseits.
Das Hauptproblem ist aber das Indy mit "Blocking-Sockets" arbeitet,
ich persönlich finde das sehr gut, aber wenn man das nicht weiß
kann es zu Missverständissen kommen.

Deine Procedure OnExecute des Servers läuft innerhalb eines Threads ab
und tritt solange die Verbindung besteht immer und immer wieder ein.
Jetzt versuchst Du innerhalb dieser Procedure den Client "neu zu verbinden".
Theoretisch sollte/müßte dadurch für die erste Verbindung des Client das OnDisconnect
ausgelöst werden und für die neue Verbindung das OnConnect, allerdings wird bei
Dir wahrscheinlich gar nichts passieren, weil der Rechner im OnExecute "festhängt".
Das Problem kann sich unterm Strich auch anders äußern,
trotzdem kann das so nicht funktionieren.

Zitat:

Ich hab noch ein Argument für die Sache mit Client auf beiden Seiten... Wenn ich nämlich auf der einen Seite nur den Server laufen hab, muss ich beim Senden der Nachrichten/Dateien immer überprüfen, ob der User nun auf der Seite des Clients oder auf der des Servers ist. Das wirkt sich vermutlich nicht gerade positiv auf die Perfomance aus... Wenn ich das mit 2 Clients mache, kann ich einfach mit den Funktionen von TIdTCPClient die Strings/Streams verschicken

^^ Schwachsinn, mit Performance hat das nichts zu tuen. Hab jetzt keinen Bock das auch noch breit zu erläutern, glaub mir einfach

Greetz Data

[DataCool]

Zitat:

PS.: wäre dir noch dankbar, wenn du mir nen Link wegen String von IdTCPServer => IdTCPClient geben könntest... Ich find immer nur das, was mir allerdings net viel weiterhilft Sad

Steht eigentlich alles drin was Du zum Denkansatz brauchst.
Aber damit Du nicht weiter auf dem Schlauch stehst:

Indy9:
Innerhalb des Onexecute des Servers:
Athread.connection.readln / writeln

Willst Du nicht direkt auf eine Nachricht des Clients reagieren und
eigenständig etwas an einen Client schicken:
dann must du dir die connection des Clients raussuchen bei indy10 ist es glaube ich
IdTCPServer1.Contexts ist eine TThreadlist in der alle Context-Objekte drin stehen.
bei Indy9: IdTCPServer1.Threads ^^^

Das sollte jetzt aber als Denkansatz reichen,

Greetz Data

P.S.: Was willst Du eigentlich erreichen einen 1:1 chat oder einen 1:n chat ?

[Z4ppy]

Zitat:

Dein genauer Fehler liegt darin das Du innerhalb des TcpServer im OnExecute,
versucht den client der gerade mit deinem server verbunden ist,
erneut zu verbinden, so wie Du es machst würde er theoretisch versuchen
sich mit dem selben Server zu verbinden mit dem er gerade verbunden war
Logikfehler Deinerseits.

Diesen Teil versteh ich iwie net...
ClientA verbindet sich zu ServerB... Der kriegt eine Nachricht vom ClientA (mitm Nick) und veranlasst ClientB dazu, sich zu ServerA zu verbinden... Wo sollte es da denn ne Kollision geben?!

Zitat:

P.S.: Was willst Du eigentlich erreichen einen 1:1 chat oder einen 1:n chat ?

1:1

MfG Z4ppy

[DataCool]

Zitat:

Diesen Teil versteh ich iwie net...
ClientA verbindet sich zu ServerB... Der kriegt eine Nachricht vom ClientA (mitm Nick) und veranlasst ClientB dazu, sich zu ServerA zu verbinden... Wo sollte es da denn ne Kollision geben?!

Weil es in Dein Bsp. keinen ClientB gibt, sondern Du verbindet Client A neu!

Greetz Data

[Z4ppy]

Nee, eigentlich net, aber ich präzisier ja gern nochma :D

Hier ma n Ablauf (bzw. wies ablaufen sollte :D)
1. Auf beiden PCs wird das Proggie gestartet
2. Aufm PC 1 wird die IP von PC 2 (bzw. dessen Router) eingegeben
3. Der IdTCPClient vom PC 1 verbindet sich zum IdTCPServer vom PC 2 und schickt ihm eine Nachricht mitm Nick
4. Der IdTCPServer vom PC 2 erhält diese Nachricht, übergibt die IP vom PC 1/dessen Router an den IdTCPClient vom PC 2
5. Der IdTCPClient vom PC 2 verbindet sich zum IdTCPServer vom PC 1 und schickt diesem ebenso den Nick
6. Der IdTCPServer vom Pc 1 erhält diese Nachricht, speichert den Nick ab
Danach werden noch einige weitere Sachen ausgetauscht, was aber hier net von Bedeutung ist, da der Fehler ja bei 5. entsteht...

MfG Z4ppy

[DataCool]

Hi,

das es so Laufen soll wie Du beschrieben hast war mir schon klar.

Aber Du hast geschrieben :

Zitat:

Ich entwickle gerade ein Chatprogramm, das ohne Server auskommen soll.
Allerdings hab ich keine Lust, 2 unterschiedliche Programme zu machen, die dann jeder besitzen muss... Also mach ich eins, das einen IdTCPClient und einen IdTCPServer enthält.

Kein Server und keine 2 unterschiedlichen Programme.
Das bedeutet für mich das Du mit einem Programm arbeitest das entweder Client oder Server sein kann.
Somit hast Du TcpClient und TcpServer in einem Programm untergebracht.
Und bei Deinem Source Demo ist es im

Klick auf "Connect Button" : IdTCPClient1.Host:=IPEdit.Text;

Innerhalb des Servers OnExecute verwendest Du :
IdTCPClient1.Host:=AThread.Connection.Socket.Bindi ng.PeerIP; //IP auslesen
IdTCPClient1.Connect();

Wenn Du das Programm jetzt mit Dir selbst testet knallt es wie ich beschrieben habe,
mit 2 unterschiedlichen PC's sollte es sogar gehen, wenn Du im OnConnect den Server des Clients auch auf active = true setzt.

Greetz Data

[Z4ppy]

Es geht ja um die Verbindung zwischen 2 PCs :wall: Dass es mit 127.0.0.1 net geht ist ja (wie ich scho auf Seite 1 geschrieben hab) logisch ;)
Und IdTCPServer.Active wird im TForm1.OnCreate auf True gesetzt ;) Der Server is also bei beiden an...

MfG Z4ppy

[Z4ppy]

*bump*
(Ich weiss, ist evtl. etwas zu früh zum bumpen, aber ich fahr am Sonntag früh in die Ferien und würd dieses Prob gern vorher lösen ;))

MfG Z4ppy