SFTPServer Component

Properties   Methods   Events   Configuration Settings   Errors  

The SFTPServer component is used to create a SFTP Server.

Syntax

nsoftware.IPWorksSSH.Sftpserver

Remarks

The SFTPServer component provides a simple way to create a SFTP server. Any SFTP client will be able to connect and transfer files to and from the server.

To begin, first provide a valid certificate with private key in the SSHCert property.

Set the RootDirectory property to a valid local path. When clients connect they will see this as their initial directory.

To start the server set Listening to true.

When clients connect the SSHUserAuthRequest event is fired. This provides an opportunity to validate the client's credentials. Please see the help for SSHUserAuthRequest for more details.

This is all that is required to start the SFTP server and begin serving files.

During operation other events fire to provide further information and also to provide you an opportunity to override the default behavior and return errors if desired.

Threading in Server Applications

In .NET, all socket-based components perform all socket IO through asynchronous methods. Each call consumes a thread from the system's thread pool, and thus the number of concurrent calls is limited to the number of worker threads returned by System.Threading.ThreadPool.GetMaxThreads. When using several components that can each create a socket connection or a single component that can create multiple socket connections, the application may enter a state where all of the pool threads are in use for receiving. In a scenario such as this, the remote hosts may be waiting for data from the application before sending, but the application cannot send that data because all the threads are tied up waiting for inbound data. This is particularly important for server applications that use a daemon component.

For example, say a server application 'S' has a max thread pool size of three, and clients 'A' and 'B' connect to it and each client uploads a large file. After all uploads are complete, 'S' enqueues an asynchronous read request in the thread pool for each client. Since there is no work being done, the thread pool immediately consumes two threads which wait for any further data from 'A' and 'B'. While 'S' is still processing the first two files it has received, client 'C' connects and uploads a relatively small file. Similarly, once that upload has completed 'S' enqueues a third read request, and the thread pool immediately consumes the third and final thread to wait for further data from 'C'. Once 'S' completes processing any of the files it will enqueue a send request. However, since all three threads are in use and waiting for data from the clients, the send operation cannot be completed. The entire system becomes deadlocked because each of the clients is waiting for data from the server, which cannot send that data since all of its pool threads are in turn waiting for data from the clients.

To avoid a deadlock situation such as this, it is necessary to ensure that the maximum number of socket connections an application can make is always at least one less than the number of available worker threads. One method to achieve this is to call System.Threading.ThreadPool.SetMaxThreads during the application's startup to set the maximum number of threads to a value high enough to support the application for the duration of its execution. Another option is to trap an event such as ConnectionRequest and Disconnected from each component instance with logic to manage the max thread pool size according to the application's current needs.