我希望了解文件传输如何在 VNC/TightVNC/RFB 中工作。
在https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#serverinit中，我看到提到了某些客户端消息，如果使用严格的安全类型，这些消息看起来很相关，例如
132 "TGHT" "FTC_UPRQ" File Upload Request
133 "TGHT" "FTC_UPDT" File Upload Data
但我没有看到有关这些消息如何在协议中使用的详细信息
在https://www.tightvnc.com/上有很多关于使用的信息，但到目前为止还没有找到任何关于协议本身的信息。
文件传输如何工作？例如，双向发送的消息的低级细节是什么，以启动和完成从客户端到服务器的上传？
（最终我希望实现这一点，比如在NoVNC中，但此时我距离任何编码都只有几步之遥）
查看 UltraVNC的源代码，还有另一个协议，基于消息类型 7 来启动文件传输。这是RFB 规范的一部分，尽管除了包括与“FileTransfer”相关的 7 类消息之外没有给出详细信息
查看 TightVNC的源代码，看起来（令人困惑的是）TightVNC 本身似乎不支持 132 "TGHT" / 133 "TGHT" 消息。
相反，它有一个基于 252 (0xFC) 类型消息的子协议。在此子协议中，消息类型为 4 字节整数：第一个字节为 252，然后是 3 个，根据 FTMessage.h 中的注释
读取第一个字节 (UINT8) 作为消息 ID，但如果第一个字节等于 0xFC，则它是 TightVNC 扩展消息，必须读取接下来的 3 个字节并创建 UINT32 消息 ID 以进行处理。
乍一看，它与libvnc中的类似，但似乎包含更多服务器确认。例如，为了响应开始上传的请求，服务器会回复一条消息，输入 0xFC000107 说“是的，没关系”（我认为）
这是查看代码的一个非常部分的答案
我认为来自客户端的上传是由客户端发起的：
客户端 -> 服务器，1 字节 = 132：文件上传请求的消息类型
client -> server, 1 byte: 压缩级别，其中 0 未压缩，我认为 libvnc 不支持除 0 以外的任何内容（？）
client -> server, 2 bytes big endian integer: 文件名长度
客户端->服务器，4字节大端：“位置”-不确定这是什么，但我怀疑libvnc要么忽略它，要么libvnc中有一个错误，在小端系统（例如intel）上这可能会中断如果这不是零的情况，因为似乎有一些代码假定它是 2 个字节https://github.com/LibVNC/libvncserver/blob/5deb43e2837e05e5e24bd2bfb458ae6ba930bdaa/libvncserver/tightvnc-filetransfer/handlefiletransferrequest.c#L401。
上传时，TightVNC 的“旧版”代码似乎也将其设置为零https://github.com/TurboVNC/tightvnc/blob/a235bae328c12fd1c3aed6f3f034a37a6ffbbd22/vnc_winsrc/vncviewer/FileTransfer.cpp#L552
客户端->服务器，“文件名长度”字节：文件名本身
我不确定服务器如何回应说“是的，没关系”。请参阅下文，了解服务器如何说“那不好”并中止
然后我认为上传是在最大 64k 块中完成的（字节数限制为 16 位）。所以每个块是：
client -> server, 1 byte = 133: 文件上传数据请求的消息类型
client -> server, 1 byte: 压缩级别，其中 0 未压缩，我认为 libvnc 不支持除 0 以外的任何内容（？）
client -> server, 2 bytes big endian：上传数据的未压缩（？）大小
client -> server, 2 bytes big endian：上传数据的压缩大小。我认为对于 libvnc，因为不支持压缩，所以它必须等于未压缩的大小
客户端->服务器，“压缩大小”字节：当前块的数据文件本身
不确定服务器如何确认这一切都很好
然后，一旦所有数据都上传完毕，最后会有一个空块，后面是文件的修改/访问时间：
client -> server, 1 byte = 133: 文件上传数据请求的消息类型
client -> server, 1 byte: 压缩级别，其中 0 未压缩，我认为 libvnc 不支持除 0 以外的任何内容（？）
客户端 -> 服务器，2 字节 = 0：上传数据的未压缩（？）大小
client -> server, 2 bytes = 0：上传数据的压缩大小
client -> server，4字节：文件的修改和访问时间。libvnc 将两者设置为相同，有趣的是，似乎没有从消息的字节序转换为系统的字节序。
并且根据上传的其他部分，不确定服务器如何确认这已经成功
如果客户端想取消上传：
client -> server, 1 byte = 135: 文件上传失败的消息类型
客户端 -> 服务器，1 个字节：未使用（？）
客户端 -> 服务器，1 字节：原因长度
客户端->服务器，“原因长度”字节：上传被取消的人类可读原因
如果服务器想要上传失败：
服务器 -> 客户端，1 字节 = 132：文件上传取消的消息类型
服务器 -> 客户端，1 个字节：未使用（？）
服务器 -> 客户端，1 字节：原因长度
服务器 -> 客户端，“原因长度”字节：上传失败的人类可读原因
服务器似乎没有办法承认任何形式的成功，这似乎很奇怪，所以客户端不能真正给用户一个“是的，它成功了！” 符号。至少，没有人对一切确实奏效充满信心。
看起来一次最多只能上传 1 个文件：没有 ID 或类似的东西来区分同时上传的多个文件。尽管考虑到这将全部通过同一个 TCP 连接（通常），但这可能不会带来任何速度优势。