weixin_39611043
weixin_39611043
2021-01-07 18:25

Making a client seed without any choking or upload limits

Please provide the following information

libtorrent version (or branch): 1.1.2

I would like to write a client using libtorrent which will seed the data without any choking or any limits. I have already gone through other issues and already implemented a simple client using


    sett.set_int(settings_pack::choking_algorithm, settings_pack::fixed_slots_choker); 
    sett.set_int(settings_pack::unchoke_slots_limit, -1); 

But even after doing this the client seems to stop seeding after some time and then starts again. I want to write a client which will keep on seeding as long as there is a demand. How can I do it?

该提问来源于开源项目:arvidn/libtorrent

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

11条回答

  • weixin_39923110 weixin_39923110 4月前

    you configure it to do so. which configuration option to set depends on what undesirable behavior you see. "stops seeding" is not a precise enough description of what's happening.

    does it stop the torrent and start it back up again? are your torrents auto-managed? does it disconnect peers? are the number of peer connections close to the limit? does it choke peers?

    点赞 评论 复制链接分享
  • weixin_39611043 weixin_39611043 4月前

    All torrents are auto-managed. Data collected from torrent_handle::status() shows 0 peers. There is only 1 peer downloading the data so peer connections are not close to the limit. Also seeder client shows the incoming piece requests of the leecher. I am not sure how to see if it is choking any peers (I could not see that information in alerts) but I have used above mentioned settings for choking. Sometimes it transfers one or two pieces and then stops sending any data while sometimes it does not transfer anything at all. The leecher is another client which is also auto managed but it tries to download only the pieces that are currently needed (by setting highest priority for those pieces).

    Can you please tell me how to get all debugging information (I am already printing all the alerts without filtering) and how to interpret that information? (For example the reason codes in alerts)

    点赞 评论 复制链接分享
  • weixin_39923110 weixin_39923110 4月前

    you probably want to look at peer_info on the seeding client. What happens in the flags field may be especially interesting. You can query peer info via get_peer_info.

    点赞 评论 复制链接分享
  • weixin_39923110 weixin_39923110 4月前

    if you enable peer-level logging, you should get a log alert every time a peer is choked and unchoked.

    点赞 评论 复制链接分享
  • weixin_39611043 weixin_39611043 4月前

    Thanks for your help. I printed all peer_log messages. It looks like my seeder client has choked my leecher client and my leecher client has also choked my seeder client. Further they also disconnect the connection after transferring some pieces (since I found multiple handshake messages in the log). They do transfer few pieces (I am guessing after some time interval they unchoke each other). How can I make seeder and leecher make work without any choking. They should start transferring pieces as soon as request arrives. In this regard can below setting help?

    
     sett.set_int(settings_pack::unchoke_interval, 1);                                                                                                 
     sett.set_int(settings_pack::optimistic_unchoke_interval, 1);
    

    I also tried changing torrent mode to NOT auto-managed but then it doesn't download anything at all (probably because at first I set piece_priority as 0 for all pieces and then set it to 7 for the pieces that I need)

    I am new to these concepts and having hard time in figuring out what is happening.

    点赞 评论 复制链接分享
  • weixin_39923110 weixin_39923110 4月前

    you should probably understand the basic protocol specification. A peer is never unchoked unless it's interested. An as soon as a peer is no longer interested, it's choked. You're saying that you set piece priorities to 0, I would expect then that the downloader will sometimes become not-interested and hence be choked.

    点赞 评论 复制链接分享
  • weixin_39611043 weixin_39611043 4月前

    You are correct, since I am setting the piece priority to 0 it becomes not-interested sometimes and hence chokes the peer but what I want is whenever I set piece priority back to 7 (for a particular piece) then it should change status to interested and then unchoked as soon as possible. I want to know what settings will have to be done in seeder client and leecher client to achieve that?

    点赞 评论 复制链接分享
  • weixin_39923110 weixin_39923110 4月前

    I would expect that to be the default behavior, except you loose at least one round-trip each time it happens (to send the interested message and get the unchoke message back) before you can request another piece.

    What to do about it depends on which step of this chain fails to happen immediately. The traditional behavior of a bittorrent client is to only consider peers to unchoke every 15 seconds. The ability to unchoke a peer that becomes interested immediately is a libtorrent feature that only kicks in if there are enough unused unchoke slots.

    点赞 评论 复制链接分享
  • weixin_39611043 weixin_39611043 4月前

    I already tried setting those values using below functions but that didn't help.

    
    sett.set_int(settings_pack::unchoke_interval, 1);                                                                                                 
    sett.set_int(settings_pack::optimistic_unchoke_interval, 1);
    

    That is why I wanted to know if I need to do any other configuration changes along with this to make it work.

    点赞 评论 复制链接分享
  • weixin_39923110 weixin_39923110 4月前

    You have to look at your log to figure out what the specific behavior you don't want is.

    点赞 评论 复制链接分享
  • weixin_39875842 weixin_39875842 4月前

    This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

    点赞 评论 复制链接分享

相关推荐