TClientsocket verbindet sich nur einmal

[k6n]

Hallo,

Ich experimentiere gerade ein bisschen mit dem TClientSocket rum und bin dabei auf ein Problem gestoßen.
Ich habe eine Listbox mit einigen Testhosts, die auf jeden Fall alle erreichbar sind. (google, ebay usw...)
Jetzt möchte ich mich zu jedem Host nacheinander einmal verbinden, beim ersten mal klappt es ohne Probleme, doch beim 2. Aufruf von sock.open passiert überhaupt nichts mehr.

Woran könnte das liegen, muss man den Socket nach dem ersten Open zurücksetzen oder so?
Habe vieles ausprobiert, aber es geht einfach nicht, wieso? :cry:
Es wird auch keine Exception o.Ä geworfen, es passiert ganz einfach nichts!
An den Hosts liegt es definitiv nicht.
Der onDisconnect() Event tritt auch jedesmal korrekt wieder auf, aber er öffnet das Socket beim 2. Mal nicht mehr. Ich verstehe nicht wieso. :wall:

Hier ein Beispiel:

Delphi-Quellcode:

var i: integer;

//ButtonClick
i := 0;
sock.host := listbox1.items[i];
sock.port := 80;
sock.open;

//onConnect()
socket.sendtext('GET / HTTP/1.1'+#13#10+'Host: 'socket.remotehost+#13#10#13#10);

//onDisconnect()
listbox1.items[i] := listbox1.items[i] + ' ok';
inc(i);
//sock.close;
sock.host := listbox1.items[i];
sock.port := 80;
sock.open; //ab hier passiert nix mehr, wieso?

Danke für jeden Tipp.

[nuclearping]

sock.close?

Und warum socket.sendtext und nicht sock.sendtext?

[SirThornberry]

socket ist wohl der Parameter der im OnConnect übergeben wird. Von daher ist es sicher richtig so.

[k6n]

sock.close hatte ich schon ausprobiert, das bringt auch nichts. Und socket.sendtext() ist schon richtig, wie SirThornberry schon gesagt hat.

Hat noch jemand eine Idee, woran das liegen könnte? :gruebel:

[k6n]

Ich habe nun endlich herausgefunden, woran es liegt, und zwar liegt es daran, dass man im OnDisconnect() den Socket nicht gleich wieder öffnen darf, da dieser dort noch nicht freigegeben bzw. resettet wurde, d.h man kann es erst wieder öffnen, nachdem das Event ausgelöst wurde.

Jetzt bleibt nur noch die Frage, wie man das am besten machen kann. Man könnte einen Timer nehmen oder geht es auch noch anders besser?

Danke!

[nuclearping]

Genereller Tipp: Ich würde dir empfehlen, die Indy TCP Komponenten zu nehmen und dich nicht erst an die TSockets von Delphi zu gewöhnen.

[k6n]

Zitat:

Zitat von nuclearping

Genereller Tipp: Ich würde dir empfehlen, die Indy TCP Komponenten zu nehmen und dich nicht erst an die TSockets von Delphi zu gewöhnen.

Und wieso? Was ist an den Indy TCP Kompos denn besser?

[SirThornberry]

Zitat:

Zitat von nuclearping

Genereller Tipp: Ich würde dir empfehlen, die Indy TCP Komponenten zu nehmen und dich nicht erst an die TSockets von Delphi zu gewöhnen.

Der Grund für Meinung würde mich ebenfalls interessieren. Ich nutze die Indies wenn dies angebracht ist und die Sockets wenn dies angebracht ist. Beides hat seine Daseinsberechtigung und immer gleich alles mit Indys (und somit Threads) aufzublähen finde ich nicht ganz so prickelnd.

[alzaimar]

Der Indy TCP-Client macht meines Wissens nach auch Probleme, wenn man vom Server etwas asynchron empfangen will: Es existiert also kein 'OnServerData' Ereignis o.ä. Man muss sich mit Polling behelfen, was auf einer Event-basierten Maschine (Windows) ziemlicher Blödsinn ist.

[mjustin]

Zitat:

Zitat von k6n

Zitat:

Zitat von nuclearping

Genereller Tipp: Ich würde dir empfehlen, die Indy TCP Komponenten zu nehmen und dich nicht erst an die TSockets von Delphi zu gewöhnen.

Und wieso? Was ist an den Indy TCP Kompos denn besser?

Dass sie blockierende Sockets verwenden. Ich habe mit asynchronem Nachrichtenempfang (ICS, TClientSocket) nicht die Möglichkeit, exakt solange Bytes vom Socket zu lesen, bis ich alle Daten zusammenhabe (gesteuert über eine Byteanzahl oder ein bestimmtes Zeichenmuster).
Stattdessen wird eine OnServerData o.ä. Methode aufgerufen und jedesmal nur ein Häppchen der Daten übergeben. Das heisst, ich muss bei jedem Häppchen analysieren, ob denn nun das Ende der Nachricht erreicht wurde, und ob im Häppchen eventuell schon der Anfang der nächsten Nachricht enthalten ist.

Bei Indy lese ich einfach bis zu einem bestimmten Kennzeichen einen Bytestrom aus, und diese Bytes sind dann meine Nachricht, fix & fertig zur Weiterverarbeitung.

Man kann ICS und TClientSocket zwar (soviel ich weiss) auch in blockierendem Modus betrieben, aber ClientSocket ist bereits deprecated und mit Indy und Synapse gibt es schon zwei mehr als brauchbare Lösungen.

Damit will ich jetzt natürlich nicht sagen, dass die Verwendung von ClientSocket irgendwie gefährlich oder antiquarisch ist :angel: