[twsocket] FTP Server

Bjorn, Fastservice bjorn@fastservice.com
Wed, 28 Jun 2000 11:38:17 +0100

Hi guys,

   I am finalizing a complete FTP Server using ICS FTP Server component as
the core.

   Excellent design of a component, by the way!

   You can read about the server (Broker) and download it here:

   But because I go to great extent to finalize a complete server with
everything you can imgine, I was forced to change the code in the component
itself - which is a bit annoying.

   There are a few pointers to Piette. If he finds the time he might
add/change them.

     1: The Validation Events need to allow the programmer to control the
"Answer" variable. F.ex. I want to be able to check the disk quota in
"ValidatePut" and reply with "501 Quota Exceeded. Permission denied" or a
similar message.

     2: The property "ClientCount" is made public but not the "FClientList".
By making it public you don't not need to keep the list of clients in local
objects, but simply access it from the component. I made it public and it
made everything easier and more consistent.
        I am f.ex. using a thread which, on a fixed interval, checks if
there are clients which have been idle for more than x minutes and then
closes the socket. This thread loops using ClientCount and uses FClientList
which I made a public property "ClientList".

     3: The message constants should be made global so the whole application
is able to access them in f.ex. overriding methods and events.

   There are a few other issues, which are more difficult to handle, like
f.ex. the ability to have "Virtual paths" (by means .lnk files) and "Virtual
files" (also by means .lnk files). The reason is that I am making this
completely transparent to the End user. He does not realize that he is going
through paths, even deep hierarchy of them, that do not exist at all.

   Also, the component displays the actual paths and names of files in a
DOS/Windows format in all error messages. This is bad when you are trying to
keep the server completely UNIX like or at least trying to make the actual,
underlying OS invisible to the user. Displaying paths is a security issue
because it reveals things that you don't want the user to know - the
directory structure on your disk. This might be fixed with an event which is
called just prior to displaying the filename and path - allowing the
programmer to change the display. I needed to override all these methods to
make them act this way.

   In any case - Thanks Piette for your marvellous products !

   -- Bjorn Heidarr,
      TransSoft Ltd