TIdTCPServer (Indy) und TClientSocket

[Schwedenbitter]

Danke für die Antwort.

Zitat von Klaus01:

Firewall, seLinux.

Das ist immer das erste, was ich bei Tests mit dem Netzwerk deaktiviere, um "Irritationen" zu vermeiden
Aber daran liegt es nicht, weil dasselbe Problem auch auftritt, wenn ich das auf demselben oder anderen Windows-Rechnern mache. Es liegt also gar nicht an Linux...

Zitat von Klaus01:

Alternativ kannst Du auf dem Server mal nc -l <Dein Port> starten
und dann versuchen dich mit dem Client zu verbinden.

Siehe oben. Aber ich werde es mir merken, wenn es mal unter Windows läuft und es dann Probleme unter Linux geben sollte.

[EDIT]
Ich hatte schon verschiedene Strings (Ansi, Wide, Short) im Verdacht.
Aber das kann es nicht sein. Denn dann müsste zum einen ja das Ereignis zumindest ausgelöst werden und er müsste mir dann irgend welchen Datenmüll anzeigen. TClientSocket nutzt AnsiString und - wenn ich das richtig den Quellen entnommen habe - ist es bei den Indys auch AnsiString. Also theoretisch alles im grünen Bereich.
[/EDIT]

Gruß, Alex

[Schwedenbitter]

Offenbar hängt es schon an Delphi - oder meinen bescheidenen Programmierkünsten:

Ich habe mir zu Testzwecken die Mühe gemacht und auf einem Form "schnell" mal je Server und Client der Indys und einen TClientSocket platziert und mit Code unterlegt. Ich kann das auch anhängen, falls jemand Interesse hat.

Der Indy-Client kann etwas an den Indy-Server senden - hätte mich auch gewundert, wenn es nicht so gewesen wäre. Mit dem TClientSocket kann ich mich immerhin noch zum TIdTCPServer verbinden. Aber wenn ich mit ClientSocket.Socket.SendText('Hello World'); etwas absetze, kommt das aus mir unerfindlichen Gründen nicht an - genau wie bei den getrennten Programmen. Das Ereignis wird auch hier nicht ausgelöst

Jetzt wollte ich gern testen, ob es umgekehrt klappt, vom Server etwas an TClientSocket zu senden. Bedauerlicher Weise hängt sich folgender Code (den ich im www gefunden habe) ohne jedwede Fehlermeldung auf; selbst das Senden an den Indy-Client klappt somit nicht:

Delphi-Quellcode:

Procedure TForm1.BtnBrdcastClick(Sender: TObject);
Var
   CList            : TList;
   I               : Integer;
Begin
   CList:= IdTCPServer.Contexts.LockList;
   Try
      For I:= 0 To Pred(CList.Count) Do
      Try
         TIdContext(CList[I]).Connection.SendCmd(EDBrdCast.Text);
      Except End;
   Finally
      IdTCPServer.Contexts.UnlockList;
   End;
End;

Kann mit dazu jemand etwas sagen?

Ich würde wirkllich gern den Indy-Server und den Delphi-Client miteinander verbinden. So schnell will ich da nicht aufgeben. Aber ich finde schon jetzt, dass die Indys vergleichsweise unhandlich sind und merkwürdig reagieren...

Gruß, Alex

[Aviator]

Ich weiß nicht ob es richtig ist was ich jetzt sage, aber ich hatte so etwas auch mal testweise ausprobiert.

Beim Zugriff auf die LockList wird ein SperrFlag gesetzt welches mit UnlockList aufgehoben wird. Das Problem bei mir war allerdings, dann ich, egal ob ich mir die Instanz zwischengespeichert habe oder nicht, pro Zugriff auf die LockList ein UnlockList aufrufen musste.

Erst dann hat es funktioniert. Aber ich dachte mir damals schon, dass das nicht richtig sein kann. Eventuell findet sich ja jemand der das schon gemacht hat.

Stahli hat doch aktuell so ein Socket Framework gebaut wenn ich mich recht erinnere. Ob das allerdings etwas damit zu tun hat weiß ich nicht.

[Bambini]

http://stackoverflow.com/questions/3...texts-locklist

[Schwedenbitter]

Dank des Quellcodes in C++ (?) von Bambini habe ich es geschafft:

Delphi-Quellcode:

Procedure TForm1.BtnBrdcastClick(Sender: TObject);
Var
   CList         : TList;
   I            : Integer;
Begin
   CList:= IdTCPServer.Contexts.LockList;
   Try
      For I:= 0 To Pred(CList.Count) Do
      Try
         TIdContext(CList.Items[I]).Connection.IOHandler.WriteLn(EDBrdCast.Text);
         TIdContext(CList.Items[I]).Connection.IOHandler.WriteBufferFlush;
      Except End;
   Finally
      IdTCPServer.Contexts.UnlockList;
   End;
End;

Einen Fehler ("Items[I]" statt nur "[I]") und eine Unwissenheit (WriteBufferFlush fehlte ganz) habe ich ausgemerzt.

Besonders "lustig" ist nun, dass ich die Strings mittels Ereignis mit System.Win.ScktComp.TClientSocket erhalte. Empfangen funktioniert also, senden leider nicht - wie unpraktisch. Jetzt suche ich in IdTCPClient.TIdTCPClient eine Möglichkeit, die Daten abzurufen. Die Ereignisse habe ich alle durchprobiert. Da tut sich leider nichts. Es ist so unschön, dass ich irgendwie kein Tutorial finde, in dem einmal die Kommunikation vollständig aufgezeigt wird.

Ist es wirklich so, dass man die Daten "von Hand" über ein Polling auslesen muss? Ooch man!

Gruß, Alex

[stahli]

Ich hatte hier noch nichts beigetragen, weil ich nicht wusste, ob ich das Problem überhaupt richtig verstanden habe.
Da ich aber angesprochen wurde versuche ich mal was ins blaue...

Indy funktioniert immer blockierend.
Client fragt beim Server an und wartet auf Antwort.
Der Server startet Threads für die Verarbeitung der Anfrage.

Hierzu mal ein älterer Beitrag:
http://www.delphipraxis.net/171226-i...o-clients.html



Ich habe jetzt mal eine asynchrone Kommunikation getestet:
http://www.delphipraxis.net/190482-s...ockettest.html

Das funktioniert anscheinend richtig gut und ich bin dabei, mein echtes Projekt von Indy darauf umzustellen.
Die Sockets funktionieren aber m.E. in dieser Form nur unter Windows.

Falls das irgendwann doch Probleme macht, könnte ich dies auch wieder auf Indy oder etwas anderes umstellen, da Server und Clients im Grunde "Message-Objekte" austauschen, die mein Package automatisiert ordnet, zerlegt, überträgt, wieder herstellt und auf der Empfangsseite zur Verarbeitung bereitstellt.
Ob die Übertragung dabei über Sockets oder Indy bzw. asynchron oder blockierend erfolgt ist dann eher nebensächlich.

[Schwedenbitter]

Danke.

Ich hätte furchtbar gern die Sockets von Delphi genutzt. Aber ich habe das Problem, dass diese sich faktisch nicht aus der VCL lösen lassen und ich damit mit Linux/Wine scheitere. "Das funktioniert anscheinend richtig gut." kann ich nur bestätigten, nützt mir aber nichts
Ich wollte deshalb wenigstens auf der Client-Seite bei den Sockets bleiben, damit ich nicht alles neu programmieren muss. Aber irgendwie kommt vom TClientSocket nichts beim TIdTCPServer an.

Blockierend bedeutet, dass ich lesen kann, dann aber meine GUI hängt oder ich es in einen Thread auslagere, richtig? Ich habe mich für Letzteres entschieden und jetzt mal wieder Quellcode angehängt. Beteiligt an der Spielerei sind TClientSocket, TIdTCPClient und TIdTCPServer.

Nach meinem beschränkten Verständnis sollte doch beim Senden vom Server wenigstens irgend etwas ankommen - also zumindest das Ereignis ausgelöst werden. Ich bin immer noch nicht dahiner gestiegen, warum das so ist

[OT]
Ein weiteres lustiges Phänomen ist auch, dass der TIdTCPServer offenbar ein Problem damit hat, die richtige Anzahl der verbundenen Clients zu liefern. Auch hierzu habe ich mich eines Codes aus dem www bedient, der jedoch merkwürdige Werte liefert. Aber dazu mache ich ggf. ein anderes Thema auf ...
[/OT]