使用“断头档”实现端口开放检测的设想

比特彗星(BitComet)
1

目前BC主要依靠外置的端口检测服务器来测试客户端的端口开放情况
但有些地区和运营商的用户无法连接的到端口检测服务器
导致无法正常检测端口状态

除了端口检测服务器外BC还可以通过 任务中是否有传入的用户来判断
即正在运行的任务中是否有 被动 发起的用户 若有则表示端口可被连接
也是就端口是开放的

但用户可能不总是在运行任务或正在运行的任务并不总是有活跃用户
这就导致检测的不稳定 即需要稳定的保存连接的用户

我们其实可以利用之前的“断头档”来解决这个问题
“断头档”应该最早起源于emule 是用来使用户之间保持连接 方便加好友用的

后来论坛的用户发现使用类似的方法可以使BC客户之间保持连接
方便交换种子市场种的他人共享内容

虽然原贴已经失效但 其发布的“断头档”已经积累了较多的用户
非常适合用于端口检测

2842c50d66d646d0068fb1e1a01296c25365408e
aa7eac0b6df2e41721069ec3f20601128abc7d97
5331c860e74a31566c229ee41f5d9137eefebb6b
602736d1501598b167ff93d79170b4c47beda038
26a781766531789936b8d80db85c533b6837f11f
bdf2d9605affc81cc4a5a6389d47a76ba3b70d15
e1c9ef19ba10bd3f47c9945176236440869e67a8
3ee539de4a4d0341ddcc1d9ec4cd1464c947b9f1
7d6162162c83624d9f3a16b2d3ec7d770c52e846
391e6fa68fb721ad70e82d2717ae8e21edd752c8
18688f6d06ed58b79179307bab3bf1f247a57998

而且其泛用性是更强的 他人共享功能是BC的专有功能
但是通过传入用户 来检测端口状态的功能其他客户端也有实现
这就意味着不同的客户端之间可以通过一个或多个相同的 “断头档”
来互相探测端口

但考虑到任务的不同也许应该发布专用的“断头档”
用于完成端口检测功能 其中应包含解释和说明文件

2

这是我制作的断头档，特点是不包含任何有效信息，目前任意时间都有大概二十几个人在使用。

magnet:?xt=urn:btih:QL4X7SYHZ6SWKMVP3EC73UEOHYS2Q2XM

种子体积2MB，分块为1MB，所以一共两个分块。
分块1：1MB的文件分块，二进制全是0，所有人都能获取。
分块2：1MB的文件分块，分块哈希全是0，哈希碰撞到宇宙末日也不可能搞到这个分块。

因其不包含任何信息，所以可以在互联网随意发送。
因其绝无可能被下载，所以这是物理意义上的永久断头档。

3

全是1不行吗？

4

两种情况的信息熵都为 0，理论上是一样的。
在自然语言上，一般来说，0对应 “无”，1对应 “有”，用0能更直观地体现 “物理断档、无内容” 的初衷。

5

Windows的NTFS机制可以压缩全0，也可以快速创建这种文件
fsutil file createnew D:\1GB.test 1073741824

他这个方法有个不好的地方是，一定要完整上传1MB的真实数据给其他人
应当和楼主的方案一样，创建2个文件并且分块对齐，第一个文件byte设置1字节填0即可，第二个文件在写入分块哈希值全0
这样在发生区块上传过程的时候，只会产生1字节网络流量，客户端会自动完成后续填0操作

甚至可以使用v2格式的种子，进一步降低磁力转种子产生的元数据大小
比如一个64MB的文件，v1格式元数据大小是10KB，v2元数据大小是41byte

6

不过除了BC外其他的客户大多没有特别明显的端口状态提示 qb算是有比较明显的提示
也许对其他客户端来说 对检查端口状态的需要可能不是非常迫切