Home/ Questions/Q 188501
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T16:01:44+00:00

I need to have as part of a desktop application a file server which

  • 0

I need to have as part of a desktop application a file server which should respond as fast as possible to file transfer requests (from remote clients, usually located on the same LAN). There will be many file requests for small sized files. The server should be able to provide both upload and download services.

I am not tight to any particual technology so I am open to any programming language, toolkits, libraries as long as they can run on Windows.

My initial take is to go with a C/C++ implementation using Windows Sockets or use the services provided by libraries such as Boost (asio or such). I have also thought of Erlang but that I’ll have to learn and so the performance benefits should justify the increased development time due to having to learn the language.

LATER EDIT: I appreciate the answers that say use FTP or HTTP or basically anything that has been already created but considering you still want to write one from scratch, what would you do?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    For frequent uploads of small files, the fastest way would be to implement your own proprietary protocol, but that would require a considerable amount of work – and also it would be non-standard, meaning future integration would be difficult unless you are able to implement your protocol in any client you’ll support. If you choose to do it anyway, this is my suggestion for a simple protocol:

    1. Command: 1 byte to identify what’ll be done: (0x01 for upload request, 0x02 for download request, 0x11 for upload response, 0x12 for download response, etc).
    2. File name: can be fixed-size or prefixed with a byte for the length (assuming the name is less than 255 bytes)
    3. Checksum, MD5 for instance (if upload request or download response)
    4. File size (if upload request or download response)
    5. payload (if upload request or download response)

    This could be implemented on top of a simple TCP socket. You can also use UDP, avoiding the cost of establishing a connection but in this case you have to deal with retransmission control.

    Before deciding to implement your own protocol, take a look at HTTP libraries like libcurl, you could make your server use standard HTTP commands like GET for download and POST for upload. This would save a lot of work and you’ll be able to test the download with any web browser.

    Another suggestion to improve performance is to use as the file repository not the filesystem, but something like SQLite. You can create a single table containing one char column for the file name and one blob column for the file contents. Since SQLite is lightweight and does an efficient caching, you’ll most of the time avoid the disk access overhead.

    I’m assuming you don’t need client authentication.

    Finally: although C++ is your preference to give you raw native code speed, rarely this is the major bottleneck in this kind of application. Most probably will be disk access and network bandwidth. I’m mentioning this because in Java you’ll probably be able to make a servlet to do exactly the same thing (using HTTP GET for download and POST for upload) with less than 100 lines of code. Use Derby instead of SQLite in this case, put that servlet in any container (Tomcat, Glassfish, etc) and it’s done.

    • 0