正常，简体中文是没有截图的
不要乱改语言，人家豪华版默认繁体，你非要自己乱改成简体
话说我看了下注册表，，里面只有目录，没有具体到64位的exe进程
嗯，注册表里只有目录，选择32位或64位主程序的代码是在BitCometAgent.dll里面。新版已改进。
对比下utorrent就有1438字节一个包，utorrent的utp速度就稍微比比特彗星的UTP快一些，不知道qbittorrent是多少，，没去安装测试
个人觉得，，可以把包改成10KB一个？也就是10000字节？这样可以跑到5MB/s？
或者给个高级选项，，自定义该值，说不定可以获得更好的传输效果？
1個讚
UDP最大支持65535，也就是64KB，如果确定可以传输的话这个包是越大越好呢还是小点好？太大了运营商会丢包吗？
1.在链路层，由以太网的物理特性决定了数据帧的长度为(46＋18)－(1500＋18)，其中的18是数据帧的头和尾，也就是说数据帧的内容最大为1500(不包括帧头和帧尾)，即MTU(Maximum Transmission Unit)为1500；
2.在网络层，因为IP包的首部要占用20字节，所以这的MTU为1500－20＝1480；
3.在传输层，对于UDP包的首部要占用8字节，所以这的MTU为1480－8＝1472；
所以，在应用层，你的Data最大长度为1472。当我们的UDP包中的数据多于MTU(1472)时，发送方的IP层需要分片fragmentation进行传输，而在接收方IP层则需要进行数据报重组，由于UDP是不可靠的传输协议， 如果分片丢失导致重组失败，将导致UDP数据包被丢弃。
从上面的分析来看，在普通的局域网环境下，UDP的数据最大为1472字节最好(避免分片重组)。
但在网络编程中，Internet中的路由器可能有设置成不同的值(小于默认值)，Internet上的标准MTU值为576，所以Internet的UDP编程时数据长度最好在576－20－8＝548字节以内。
MSS的主要作用是限制另一端主机发送的数据的长度，同时，主机本身也控制自己发送数据报的长度，这将使以较小MTU连接到一个网络上的主机避免分段。
MTU的含义: MAC帧内的数据(Payload)字段的最大长度。
2個讚
UDP包大了丢包率会上升。libtorrent的uTP连接建立时有一个最合适的包大小检测过程，彗星还没来得及做。
感谢科普 
不是有一个20字节的握手包嘛？不会出问题的吧，丢包也就20字节，没握手成功也不会进行下面的数据传输，不方便做大的话要不然改成和utorrent一样的1438字节
话说不知道http下载时候有没有办法首次下载就能获取到长效，，，比如说计算头尾区块和文件大小，头尾区块快速sha1后判断打通长效。不过视乎这样要改掉长效种子服务器的数据库结构，因为现在没记录这部分快速sha1值吧，数据库里只有完整的sha1,看起来要大改挺麻烦的
就是现在http除非下载固定url的文件，，不然网盘这种每次下载url都不同的，只有下载完成成功一次，任务上右键，选择重新下载，第二次才能打通长效
1個讚
@zhuxiaoying85309 不是有一个20字节的握手包嘛？不会出问题的吧，丢包也就20字节，没握手成功也不会进行下面的数据传输，不方便做大的话要不然改成和utorrent一样的1438字节
可以参考一下上面说的mtu帧的概念，在不稳定网络环境中，比如丢包是10%，大多数情况下握手包20个字节都是正常的，但是数据包就不一样了，比如现有一个数据包长度548是刚好等于标准MTU帧的，但是如果数据包大于这个值就会就会分帧，一个包1kb就是两个帧，这其中任意一个丢了整个包就丢了，一个包10kb就是20帧，丢任意一个都会使得无法合并整个udp包导致丢包，导致需要重传全部的20帧。。。
改成1438字节就是1438/548=2.6 分三个帧极端情况丢包率就会上升3倍
1個讚
个人不认可
头尾区块和文件大小来做判断碰撞率太高了。。。MD5和sha全文摘要值都有碰撞何况是只计算头尾区块
Content not available in your region 开了vpn也不能下呀
判断的是本地的时区不是ip地址的
问下怎么保存旧版本的设置更新软件，直接覆盖安装吗
保留BitComet.xml文件，在你安装目录下，不要覆盖就行
这个客户端会做二次校验吧，，意图只是用作快速获取到长效种子镜像加速，包括可以同时实现到BT中，这样跨种子同文件首次下载可以更快获取到长效
所以说，，，做成这样的自动检测包大小，默认1438，如果检测到有丢包连续超过几次就降低到548更为科学
插件右键菜单有时候是英文有时候是中文来回跳。。。
1.84版本的速度很慢