1.85测试版

嗯,注册表里只有目录,选择32位或64位主程序的代码是在BitCometAgent.dll里面。新版已改进。

UTP我看了下,一个包文在20字节或者548字节,不知道组合放大包来传输后有没有改善

1KB=1024字节,0.5KB一个包。。包太小了所以传不动吧,然后导致UDP下载或者上传速度很慢

对比下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连接建立时有一个最合适的包大小检测过程,彗星还没来得及做。

感谢科普 :grinning:

不是有一个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更为科学

image
插件右键菜单有时候是英文有时候是中文来回跳。。。

1.84版本的速度很慢

我是說真的…什麼時候才能改進一下上載爆速問題…

下載了150MB之後速度降為37KB/S…上載封頂 4MB/S
感覺可以實錘是優先上載 :see_no_evil:

把迅雷和其他客戶端封掉…然後又解封…速度更高了…還連上了長效種子…
是什麼神奇BUG :rofl:

另外磁碟快取是不是過於進激
種子繼續下載…上載才用200MB…內存已用14GB
上載鎖2MB/S但磁碟讀取70-220MB/S(80-90%使用率)…

磁碟讀取統計: 要求: 8484592 (頻率: 202.0/s),實際磁碟讀取: 695599 (頻率: 6.1/s),命中率: 91.8%
讀取頻率才6-7…但平均每一下讀30MB?

CPU爆炸…硬盤150MB/S…上載/下載才33MBPS…

補充一下…設定成無限制上載



種子下載完後…鎖死上載2MB/S…硬盤照樣讀取33MB-150MB/S…同時快取已滿32GB

看来只有提供上传窗口设置才能拯救你了,,,


上传窗口数量,默认不勾选,勾选后最小值30,最大值9999
该值仅针对每任务,而不是同时全局最大值。
不然有人设置成0,BT网络就被搞坏了,人人都不上传,,话说我根本不希望出这种选项设置值,因为这才是比特彗星的一大特色,上传快,所以大家用比特彗星来下载,也才发现下载速度也很快,因为大家都在上传
众生平等不会对任何一个人不产生上传流量,不像qbittorrent,默认只给4个人上传,太吸血了

要不然楼上,你把每任务连接数改成30,别开这么大,,,你都连接141/505个用户了,连接到的人多上传自然也多了

2個讚