indy10 / TCPServer /TCPClient ->Datei versenden

[DataCool]

Hi Cherry,

Du hast recht ich habe ^den^ Source mal eben von Indy9 auf Indy10 portiert,
damit Du was damit anfangen kannst.

Hier eben die kleinen Portierbugs behoben:

Delphi-Quellcode:

  // Client-Daten zu auslesen
  try
    tmpClient := TClientData(AContext.Data);
  except
    AContext.Connection.Disconnect;
    exit;
  end;

Delphi-Quellcode:

  try

    // Settings.CmdReadTimeOut <-- meine Einstellungsklasse der WErt des ReadlnTimeOutsfür Kommandos
    // Settings.CmdMaxLength <-- meine Einstellungsklasse der Wert der maximalen Zeichenlänge mein ReadLn

    // Daten im Buffer ? 5000 ms = 5 Sekunden ReadLn-Timeout, maximal 1024 lesen
    // die Parameter beim ReadLn sind optional und müssen nicht zwingend verwendet werden
    tmpClient.LastCmd := AContext.Connection.Socket.ReadLn(#$A,5000,1024);
  except
    tmpClient.LastCmd := '';
  end;

Zum Senden einer Datei via Stream; Ich kann Dir jetzt nicht mit 100% Sicherheit sagen wie's gemacht wird,
weil ich meine akztuellen Projekte alle noch in Indy9 habe und bald erst mit dem portieren anfange.
Was ich aber festgestellt habe ist das es in Indy10 kein "WriteStream" mehr gibt, obwohl ein "ReadStream"
gibt. Ich habe aber auch gesehen das es bei Indy10 jetzt ein WriteFile gibt und wenn man sich den Source dazu anschaut :

Delphi-Quellcode:

function TIdIOHandler.WriteFile(const AFile: String; AEnableTransferFile: Boolean): Int64;
var
//TODO: There is a way in linux to dump a file to a socket as well. use it.
  LStream: TIdStream;
begin
  EIdFileNotFound.IfFalse(Sys.FileExists(AFile), Sys.Format(RSFileNotFound, [AFile]));
  LStream := TReadFileExclusiveStream.Create(AFile); try
      Write(LStream);
      Result := LStream.Size;
  finally Sys.FreeAndNil(LStream); end;
end;

^^ Da könntest Du Dir die Vorgehensweise abschauen.

Jetzt nochmal zu der Frage warum ich keine GUI verwenden würde :

Wenn es nachher ein produktiver Server ist, soll er vor allem eins : Laufen ohne abzustürzen
Eine hohe Ausfallsicherheit erreichst man unter anderem auch, indem man die Fehlerquellen minimiert,
wenn Du mit einer GUI in einem Multi-Threaded Server arbeitest, solltest alle Änderungen an der GUI
nur syncronisiert vorgenommen werden, ansonsten könne recht "unschöne" Sachen passieren und Du denkst
Dein Server läuft noch obwohl er nicht mehr richtig arbeitet.
Klar kannst Du, wenn Du sauber programmierst das ganze auch mit GUI machen, ich wollte Dich nur auf die Gefahren hinweisen

Versteh mich nicht falsch ich habe zu meinen "Servern" auch eine GUI aber das ganze läuft bei mir so :
- Server wird als Dienst geschrieben, hat keine Gui und keine Interaktion mit dem Desktop
- Im Server wird ein zusätzlicher Port nur lokal geöffnet
- Dann schreibe ich meine "GUI zum Server" als eigene Anwendung, die dann über den lokalen Port sich
die Infos die sie braucht holt und anzeigt.
- die lokale Kommunikation zwischen Server-GUI und Server-Dienst ist natürlich verschlüsselt und die GUI
muss sich natürlich erst beim connecten verifizieren.

^^ Aber das must Du jetzt nicht alles machen, man muss ja auch nicht mit Kanonen auf Spatzen schiessen

Alles nur Denkanstösse,

Greetz DataCool