Performance Concerns -------------------- kaosFTP is taking up more memory than I'd like it to. This is mostly do to the brevity I have taken when implementing the classes. For example, string fields in the classes are mostly of fixed (large) sizes. A better approach would be to use dynamic allocation for these strings. I chose fixed-length strings for simplicity only. This will be of higher concern once kaosFTP has been tested for bugs thoroughly. What it means to be Multithreaded --------------------------------- xmftp (my previous client) and many other network applications block on system calls (such as network operations). One solution to this is to use non-blocking IO, but as anyone can attest it becomes a nightmare when you have do such simple things as, for example, remembering what 'state' the program is in. You end up designing your own horribly complicated re-entrant interface. Another solution is to use multiple processes. However, some type of IPC (interprocess communication) must be used. You spend more time writing your own protocol to communicate between the processes than actually working on the application. The final solution (which I chose), is to use threads. Since all child threads share application data, IPC is simplified. It does require synchronization between the threads, but is much cleaner than the above methods. My FTP connection is composed of at most 3 threads. One is the control connection (the telnet connection by which FTP commands are sent, see the FTP RFC). Another thread is the interface between the application and the control connection. This allows the ability to 'queue' a command in the interface thread and return immediately. The control connection thread processes that command (and may block on the network operations). The final thread is a data transfer thread, and only exists during an transfer (such as upload, download, and filelist). It is to be noted that the kaosFTP application is not itself multithreaded! What is multithreaded is the FTP library. I chose not to go into the horror of doing multithreaded X GUI operations. However, to the user, the GUI should never block (unless the interface thread blocks, which I have tried to make sure it doesn't). Multithreaded Issues -------------------- Linux Threads implementation is a dance between the SIGUSR* signals. Whether this is good or bad, you can judge for yourself. If you plan to use the FTP library, you shouldn't use SIGUSR* in any way by your application. I've had some interesting problems with this when I originally used GTK. I believe that GTK uses the SIGUSR* signals in some way or other. I sincerely believe that Linux Threads is in its infancy, and requires much maturing. Anyone who has tried to debug threaded programs in Linux will agree. Though I have taken precautions in avoiding deadlock conditions, there are instances when this might occur. Program lockups should be very rare if ever. If you experience any, please inform me, and try to provide as much information as possible. Comparison with other FTP clients --------------------------------- There is some overhead in my design. This could be the compounding of many things like C++, multiple inheritance, mutex locks/unlocks, GUI, and pthreads in general. On very fast connections I noticed kaosFTP does not perform as great as commandline ftp. The difference is in my opinion negligible. I'd be interested in hearing your results. Difference between "Current Speed" and "Total Average Speed" ------------------------------------------------------------ Current Speed refers to the average transfer rate since the beginning of the current file. Total Average Speed is the average transfer rate since the start of the transfer, which really is only important during multiple file transfers. However, even during single file transfers, the two values may not necessarily be the same. If anything, the Total Average Speed will be lower. The reason for this is that the time frame used in calculating the Total Average Speed includes the time it takes for the server to even respond to the transfer command (e.g. RETR), whereas Current Speed starts its calculation upon receiving the first byte of actual file data. Using the FTP library --------------------- Currently the library is documented poorly. I plan to improve it as I continually test it. If you can figure out how to use it, by all means go ahead :). The test_app/ directory may help. The kaosFTP source, and ultimately the library source, is what you should look at. Keep in mind the library implements connections as event-driven entities. This makes it much harder to use, but hopefully will be ideal for event-driven applications.