Wann und wie lange bleibt eine TidTCPServer-Verbindung offen ?

[AnyH]

Hallo,

ich habe eine IOS App als Client und eine Delphianwendung als Server. Die Verbindung haut hin und ich kann auch Daten senden. Dann wird es problematisch ...

Das OnConnect und OnExecute des Servers wird einwandfrei abgearbeitet. Sende ich etwas an den Client im OnExecute, wird es vom Client allerdings nicht registriert. Erst wenn der Server die Verbindung zumacht (Disconnect), wird der Client das Gewahr. Leider ist der Empfangspuffer des Client leer.
Beende ich den Client, bekommt der Server das mit, denn dann wird die OnDisconnect Routine aufgerufen.

Ich dachte, dass die Connection so lange erhalten bleibt, bis sich entweder der Client oder der Server aus der Kommunikation verabschiedet. Es sieht für mich aber so aus, als ob für jedes Verbinden vom Client zum Server ein Connect, Execute und Disconnect gemacht werden muss. Ist das richtig ?

Die von mir gesendeten Daten versende ich mit folgender Befehlssequenz:

Code:

function TForm1.SendResponse (AContext: TIdContext; cResponse: string): boolean;
var
  lines: TStringlist;
  crPos, i: integer;
  line: string;
begin
  lines := TStringlist.Create;
  try
    while length (cResponse) > 0 do begin
      crPos := pos (#13+#10, cResponse);
      if crPos = 0 then begin
        Line      := cResponse;
        cResponse := '';
      end else begin
        Line      := copy (cResponse, 1, crPos-1);
        cResponse := copy (cResponse, crPos+2);
      end;
      Log (C_SENT, format ('[%s]', [line]));
      lines.Add(line);
    end;
    AContext.Connection.Socket.Write (lines, TRUE, TEncoding.ANSI);
    AContext.Connection.Socket.WriteBufferFlush;
  finally
    lines.Free;
  end;
end;

Leider ist der Empfangspuffer des Client immer leer.

Danke,

Andree

[Zacherl]

Hallo AnyH und herzlich willkommen im Forum!

Du hast vollkommen Recht: Die Verbindung sollte erst dann abbrechen, wenn entweder der Client oder der Server das Socket schließt. Ich vermute das Problem hier eher auf der Clientseite (iOS).

Wie genau wartest du denn auf eingehende Daten beim Client? Bei den Windows Sockets wird zwischen blocking und non-blocking unterschieden. Die blocking Sockets müssen eigenständig (z.b. in einem Thread) auf eingehende Daten warten, während bei den non-blocking Sockets Windows Messages im Zusammenhang mit Events eingesetzt werden, um auf eingehende Daten zu reagieren.

[AnyH]

Danke erst mal für die Antwort.

Ich arbeite auf der Clientseite mit dem RESTFUL RestKit. Damit sendet man einen Request und wartet dann auf das Ereignis des Eingangs der Antwort. Das ist ein sogenannter RKRequest als Anforderung und eine sogenannte RKResponse, die als Antwort ausgewertet werden kann. Da ich die Antwort immer nur erhalte wenn ich den Server schließe oder die Connection disconnecte, habe ich das Problem eigentlich auf der Serverseite vermutet. Ich werde mich aber mehr mit der Doku beschäftigen müssen, um da richtig durchzublicken.

Wenn ich mein Problem konkreter darlegen kann, melde ich mich noch mal.

Danke,

Andree

[Zacherl]

Oh okay, wenn du so eine Request-Response Klasse verwendest, kann es durchaus auch an der Serverseite liegen. Ich kenne mich mit iOS Entwicklung und den dazugehörigen Klassen nicht wirklich aus, aber irgendwie muss die Klasse ja erkennen, wenn die Antwort vom Server vollständig angekommen ist. Wenn das nicht über ein definiertes Protokoll passiert, kann ich mir nur einen Disconnect als Trigger vorstellen.

Versuch mal in deinem OnExecute Event es Servers den Client direkt nach Schicken der Antwort zu disconnecten.

Wenn du eine dauerhafte Verbindung etablieren willst, musst du wohl auf Clientseite einiges ändern.

[mjustin]

Zitat:

Zitat von AnyH (Beitrag 1186521)

Ich arbeite auf der Clientseite mit dem RESTFUL RestKit. Damit sendet man einen Request und wartet dann auf das Ereignis des Eingangs der Antwort.

REST basiert normalerweise auf HTTP und daher ist eher eine TIdHTTPServer Komponente passend, wenn man die HTTP Protokollprogrammierung vermeiden will. Vermutlich wartet der Client einfach nur auf eine vollständige HTTP Response vom Server, bevor er sie aus dem RestKit an die Anwendung weitergibt?

[Zacherl]

Zitat:

Zitat von mjustin (Beitrag 1186525)

Zitat:

Zitat von AnyH (Beitrag 1186521)

Ich arbeite auf der Clientseite mit dem RESTFUL RestKit. Damit sendet man einen Request und wartet dann auf das Ereignis des Eingangs der Antwort.

REST basiert normalerweise auf HTTP und daher ist eher eine TIdHTTPServer Komponente passend, wenn man die HTTP Protokollprogrammierung vermeiden will. Vermutlich wartet der Client einfach nur auf eine vollständige HTTP Response vom Server, bevor er sie aus dem RestKit an die Anwendung weitergibt?

Das würde zumindest einiges erklären. HTTP ist für sowas dann natürlich als "nativ" Request/Response basiertes Protokoll sowieso ideal.

[AnyH]

Danke,

ich werde es mal mit der HTTP-Komponente probieren.

Andree