Indy, Events & IOS wer liegt falsch?

[Mavarik]

Hallo Zusammen.

Mir stellt sich gerade die Frage ob Indy, IOS, FM3 den Fehler macht oder
ich...

gegeben sei:

Delphi-Quellcode:

procedure TMyForm.IdTCPClient1Connected(Sender: TObject);
begin
  repeat
    // Mache viel!
  until raushier;
  IdUDPServer1.disconnect;
end;

procedure TMyForm.IdUDPServer1UDPRead(AThread: TIdUDPListenerThread;
  const AData: TIdBytes; ABinding: TIdSocketHandle);
begin
  // Mache so einiges
  IdTCPClient1.Connect;
  Memo1.Lines.Add('Raus hier');
end;

Was ich erwartet habe:
Der UDPServer startet den TCPClienten...
Im Memo steht "Raus hier"
und wenn der OnConnect des Clients kommt wird alles "verarbeitet" und der UDP Server
diskonnected.


Was passiert ist aber:
Der Client Onconnect kommt SOFORT
Der Server Disconnect am ende kann nicht aufgerufen werden, da der Connectcall innerhalb
des UDP Server Threads ist.
Nach einer netten Exception (abgefangen) steht dann im Memo "Raus hier"...

Hättet Ihr es gewusst? Mein Fehler?

Grüsse Mavarik

[mjustin]

Was ist das eigentlich?

[DELPHI]IdUDPServer1.Disconnect;[DELPHI]

Das man auf einem Server ein Disconnect ausführt, setzt normalerweise eine Verbindung voraus. Bei UDP gibt es keine Verbindung ...

[DataCool]

@Mavarik:
Ich habe zwar den Indy-UDP-Server noch nicht so oft eingesetzt, aber ich bin mir ziemlich sicher das das OnUDPRead
immer wieder von Indy-Listener-Thread aufgerufen wird.
Genauso läuft es beim IdTcpServer und dem "OnExecute" Event.
In der Doku steht dazu auch, das der Code Thread-Safe sein muss und/bzw. Interaktion mit der Gui synchronisiert werden müssen.

Dein Code ist so nicht richtig strukturiert/aufgebaut,
was ist wenn das OnUDPRead-Event ein zweites/xyz mal eintritt bevor der TcpClient seine Arbeit verrichten kann ?
Bei Deinem Code würde der TcpClient nochmals versuchen zu connecten, obwohl er gerade verbunden ist und brav arbeitet.

und anstatt IdUdpServer1.disconnect aufzurufen, wäre es mit IdUdpServer1.Active := false;
Bei einem verbindungslosen Protokoll "besser zu lesen".

Greetz Data

[Mavarik]

Ja stimmt...

Hab das aus dem Kopf geschrieben...

idudpServer1.Active := false;

Natürlich...

Es geht hier auf überhaupt nicht um Thread-Save...

Es geht darum, dass idClient1.Connect die Verarbeitung anhält... Und erst wieder kommt, wenn die OnConnected abgearbeitet ist...
Und nicht das der Event Connect ausgeführt wird und irgendwann später kommt...

Das macht Indy scheinbar schon immer so...

Mavarik

[arnof]

Also ich hatte mal mit den Indy Sachen und IOS experimentiert, und da ging was ich wollte ohne Probleme!

Sogar das Bilder versenden:

Server auf Active:

IdTCPServer1.Active:=True;

der wartet auf die Dinge die dann zu Ihm kommen ....


Der Client:

IdTCPClient.Conntect

-----

was machen (senden)

-----

IdTCPClient.DisConntect

[Mavarik]

Zitat von arnof:

Also ich hatte mal mit den Indy Sachen und IOS experimentiert, und da ging was ich wollte ohne Probleme!

Hast Du eigentlich meine Frage gelesen?

[arnof]

na dann ein zweites mal:

das solltest Du in einen Timer auslagern, sonst kann er mit den Theads durcheinander kommen:

procedure TMyForm.IdUDPServer1UDPRead(AThread: TIdUDPListenerThread;
const AData: TIdBytes; ABinding: TIdSocketHandle);
begin
// Mache so einiges nicht

Timer1.enabled:=True;
end;


procedure TMyForm.Timer1ontimer(Sender ...);
begin
Timer1.enabled:=false; // nur einmal machen
// jetzt bin ich ein eigender thead .....
// Mache so einiges
IdTCPClient1.Connect;
Memo1.Lines.Add('Raus hier');
end;

[Mavarik]

Zitat von arnof:

na dann ein zweites mal:

OK Vergiss einfach diesen Thread!

[romber]

Der Thread liegt schon lange zurück, aber das Problem habe ich ebenfalls. Bei TCP-Verbindung (TIdTCPClient) in einer Firemonkey iOS-App wird OnConnect sofort ausgelöst, noch bevor der Socket verbunden ist. Konnten Sie damals die Lösung für dieses Problem finden?