我正在编写一个小应用程序来测试torrent p2p的工作方式,我创建了一个示例torrent并从我的Deluge客户端播种它。从我的应用程序中,我尝试连接到Deluge并下载文件。
有问题的torrent是单文件torrent(文件名为 A - 没有任何扩展名),其数据是ASCII字符串 测试
参考this我能够提交初始握手并获得有效回复。
之后,Deluge立即发送更多数据。从第5个字节看,它似乎是一个位域消息,但我不知道该怎么做。我读过,torrent客户端可能会发送 Bitfield 和 Have 消息的混合信息,以显示他们拥有的torrent的哪些部分。 (我的客户不发送任何位域,因为它假设没有相关文件的任何部分)。
如果我的理解是正确的,它会说明消息大小是2:一个用于标识符+有效负载。如果是这样的话,为什么它会发送更多的数据,以及它应该是什么?
在我的应用发送感兴趣的命令后,会发生同样的事情。 Deluge使用 unchoke 的1字节消息进行响应(但随后再添加更多数据)。
最后,当它实际提交件时,我不知道该如何制作数据。第一个带下划线的字节是84,对应于字母 T ,正如预期的那样,但我无法更好地了解其余数据。
请注意,有问题的链接并未真正指定客户端在初始握手完成后如何按顺序提供消息。我只是假设根据对我来说有意义的事情发送感兴趣的和请求,但我可能完全不在。
答案 0 :(得分:2)
我认为Deluge不会发送您正在看到的额外字节。
如果你看一下它们,你会注意到所有额外字节都是握手消息中已经存在的字节,这应该是你目前收到的最长的消息。
我认为您正在将新消息读入同一个缓冲区,而不会将其清零或任何内容,因此您会再次看到先前消息中的字节,跟随您读取的最新消息的字节。
考虑检查您正在使用的网络API是否有办法检查实际接收的字节数,并且只查看缓冲区的那个片段,而不是整个事件。