我希望了解文件传输在 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 中，但此时我距离任何编码都还差几步）
【问题讨论】：
标签： vnc vnc-server tightvnc novnc rfb-protocol
在source for UltraVNC 中寻找另一个协议，基于消息类型 7 来启动文件传输。这是RFB specification 的一部分，但除了包括与“FileTransfer”相关的第 7 类消息之外，没有提供详细信息
【讨论】：
这是查看代码的一个非常部分的答案
我认为来自客户端的上传是由客户端发起的：
client -> server, 1 byte = 132: 文件上传请求的消息类型
client -> server, 1 byte: 压缩级别，这里0是不压缩的，我觉得libvnc不支持0以外的东西(?)
client -> server, 2 bytes big endian integer: 文件名长度
client -> server, 4 bytes big endian: “位置” - 不确定这是什么，但我怀疑 libvnc 要么忽略它，要么 libvnc 中存在 bug，在 little endian 系统（例如 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, "compressed size" bytes: 当前块的数据文件本身
不确定服务器如何确认这一切都很好
然后，一旦所有数据都上传完毕，最后会有一个空块，后面是文件的修改/访问时间：
client -> server, 1 byte = 133: 文件上传数据请求的消息类型
client -> server, 1 byte: 压缩级别，这里0是不压缩的，我觉得libvnc不支持0以外的东西(?)
client -> server, 2 bytes = 0: 上传数据的未压缩（？）大小
client -> server, 2 bytes = 0: 上传数据的压缩大小
client -> server，4字节：文件的修改和访问时间。 libvnc 将两者设置为相同，有趣的是似乎没有从消息的字节序转换为系统的字节序。
根据上传的其他部分，不确定服务器如何确认这已成功
如果客户端想取消上传：
client -> server, 1 byte = 135: 文件上传失败的消息类型
客户端 -> 服务器，1 字节：未使用（？）
客户端->服务器，1字节：原因长度
客户端 -> 服务器，“原因长度”字节：上传被取消的人类可读原因
如果服务器想上传失败：
服务器->客户端，1字节=132：文件上传取消的消息类型
服务器 -> 客户端，1 字节：未使用（？）
服务器->客户端，1字节：原因长度
服务器 -> 客户端，“原因长度”字节：上传失败的人类可读原因
似乎很奇怪，服务器似乎没有办法确认任何形式的成功，因此客户端不能真正给用户“是的，它成功了！”符号。至少，没有人对一切确实有效。
看起来一次最多只能上传 1 个文件：没有 ID 或类似的东西来区分同时上传的多个文件。尽管考虑到这将全部通过同一个 TCP 连接（通常），但这可能不会带来任何速度优势。
【讨论】：
查看source for TightVNC，看起来（令人困惑）TightVNC 本身似乎不支持 132 "TGHT" / 133 "TGHT" 消息。
相反，它有一个基于类型 252 (0xFC) 消息的子协议。在这个子协议中，消息类型是 4 字节整数：第一个字节为 252，然后是 3 个，根据 FTMessage.h 中的注释
读取第一个字节 (UINT8) 作为消息 ID，但如果第一个字节等于 0xFC，则它是 TightVNC 扩展消息，必须读取接下来的 3 个字节并创建 UINT32 消息 ID 进行处理。
乍一看，它与libvnc 中的类似，但似乎包含更多服务器确认。例如，为了响应开始上传的请求，服务器会回复一条消息，输入 0xFC000107 说“是的，没关系”（我认为）
【讨论】：