问您将使用什么来实现快速、轻量级的文件服务器？

EN

对于小文件的频繁上传，最快的方法是实现您自己的专有协议，但这将需要大量的工作-而且这将是非标准的，这意味着未来的集成将很困难，除非您能够在您支持的任何客户端中实现您的协议。如果你选择这样做，这是我对一个简单协议的建议：

1. 命令:1字节，用于标识将执行的操作：(0x01表示上传请求，0x02表示下载请求，0x11表示上传响应，0x12表示下载响应等)。
2. 文件名:可以是固定大小，也可以以字节作为长度前缀(假设名称小于255 bytes)
3. Checksum，)例如(如果是上传请求或下载响应)
4. 文件大小(如果是上传请求或下载响应)

(如果是上传请求或下载响应)

这可以在简单的TCP套接字之上实现。您也可以使用UDP，以避免建立连接的成本，但在这种情况下，您必须处理重新传输控制。

在决定实现您自己的协议之前，先看一下像libcurl这样的HTTP库，您可以让您的服务器使用标准的HTTP命令，比如GET用于下载，POST用于上传。这将节省大量的工作，您将能够在任何web浏览器上测试下载。

另一个提高性能的建议是不使用文件系统作为文件存储库，而是使用类似SQLite的东西。您可以创建一个表，其中包含一个用于文件名的char列和一个用于文件内容的blob列。由于SQLite是轻量级的，并且执行高效的缓存，因此您将在大多数情况下避免磁盘访问开销。

我假设您不需要客户端身份验证。

最后:尽管您更喜欢使用C++来提高原始本机代码的速度，但这很少成为此类应用程序的主要瓶颈。最有可能的是磁盘访问和网络带宽。我之所以提到这一点，是因为在Java中，您可能只需不到100行代码就可以创建一个servlet来做完全相同的事情(使用HTTP GET进行下载，使用POST进行上传)。在本例中，使用Derby而不是SQLite，将该servlet放入任何容器(Tomcat、Glassfish等)中，就完成了。

为什么不直接使用FTP呢？您应该能够找到任何语言的适当服务器实现，也可以找到客户端访问库。

这听起来像是很多轮子的再创造。诚然，FTP并不理想，并且有一些奇怪的地方，但是...它就在那里，它是标准的，广为人知的，并且已经被广泛实现了。

如果所有的机器都在同一个LAN上的Windows上运行，那么为什么还需要一台服务器呢？为什么不直接使用Windows文件共享呢？