Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

ABC_OKC peer_id

2007-08-20
2013-04-16
  • Open Sesamo
    Open Sesamo
    2007-08-20

    In Some trackers is banned the abc (OKC too)
    Then we use the peer_id and the user agent to despiste.
    As usually i use the BitTornado (The cliente that really is)
    But the peer_id is always the same, do not change, it's fixed for 'all' the torrents.
    Must be a way to make the end of the peer_id, less than 20 characters, be filled with aleatory numbers and letters.
    Per Torrent.

    An example.
    I start seeding a torrent. peer_id = xxx
    After 20 hours i reboot the computer. (Or crash)
    I return to seed, and then the amount of uploaded data = 0 (Zero), because the peer_id is the same.
    The tracker finish banning me. When i seed 120%. And i can't explain nothing because then they ban me too.

    Thanks by the development of the greatest client of the history.

     
    • kratoak5
      kratoak5
      2007-08-20

      It's sometimes hard to guess what trackers really do, especially when they start banning a client without any good reason...
      Maybe your tracker doesn't like simultaneous connections from the same client ID. But I can't see anything in the BitTorrent protocol that forbids this. The client ID is used to identify a client and the same client may simultaneously download/upload several torrents.
      I've tried to change user agent and client id with several trackers and several simultaneous running torrents and I've had no problem and never got banned.

      Are you sure your tracker is not also banning BitTornado ?
      Also user agent and client id must be formated exactly as original clients send them.

      Have you tried to use user agent and client id from another client like MuTorrent ?

      If this doesn't work for you, I could think of a way of formatting the client id to allow the user to specify parts of them as fixed patterns and other parts as random numbers or letters generated for each torrent.

      If you could send me the link of the tracker in a private email via the forum (click on my name in one of my messages and then on "Send this user a message"), this could also help me to find what's wrong.

       
    • Open Sesamo
      Open Sesamo
      2007-08-21

      Thanks by the answer.
      The tracker track the peer_id as a session to acumulate the amount of down/up of the user.

      Start Uploading = peer_id, uploaded=0, downloaded=0, left=0, event=started
      Uploaded = 0
      1st announce = peer_id, uploaded=1000000, downloaded=0, left=0
      Uploaded = 1000000-0 = +1000000
      2nd announce = peer_id, uploaded=2000000, downloaded=0, left=0
      Uploaded = 2000000-1000000 = +1000000

      Then i restart the computer, without send the event=stopped.
      This is for me usually, because i restart the server once a day, automatically at 08.00 AM

      ABC start automatically, and send.
      Start Uploading = peer_id, uploaded=0, downloaded=0, left=0, event=started
      Uploaded = 0-2000000 = -2000000
      Because the event started is ignored, because there are not previously an event=stopped
      My ratio is down by the total amount of the uploaded.

      Thanks in advance

       
    • Open Sesamo
      Open Sesamo
      2007-08-21

      Really it's a dangerous feature.
      I do it too.
      And with very important trackers.
      This feature in hands of a lamm3r is very dangerous.

      If not per torrent, but for season may be different the peer_id. (Random is not equal to diferent, but is asummed)
      There are no problem if you have many torrents, because the identification is torrent_id (hash) & peer_id

       
    • kratoak5
      kratoak5
      2007-08-21

      I think your problem is not linked with the peer id but because you don't properly stop torrents and close ABC_OKC before restarting your computer.
      The amount of uploaded and downloaded bytes are updated in the torrent structure when the torrent is stopped and saved to disk every 10 minutes by default or when ABC_OKC is closed. If you restart your computer without stopping any torrent or close ABC_OKC, data on disk stay to 0 and so they are restored when you start again ABC_OKC after rebooting your computer.
      You should close ABC_OKC for instance with the command "ABC.exe -c quit", wait a little and only then restart your computer. You can also more safely use the command scheduler of ABC_OKC to do this for instance 5 minutes before each computer restart.

       
    • kratoak5
      kratoak5
      2007-08-21

      In fact the amount of uploaded and downloaded bytes are also of course updated before each cyclical saving to disk.
      But they may be a problem from one session to the next one. I keep on checking the code...

       
    • Open Sesamo
      Open Sesamo
      2007-08-21

      Thanks by all, that command is now introduced 1 minute before the restart. (07:59 a.m.)
      One time i observe that i stopped the torrent, but in the tracker was active.
      Analizing, the result was that if there was an announce in a minimum time, the tracker don't accept the announce.

      As you can see i tested all the cases.
      In all the cases, if the peer_id is diferent (Manualy changed) the total of the tracker and the mine is fine.

      Best Regards and a great job ;)

       
    • kratoak5
      kratoak5
      2007-08-21

      After checking there's no problem in ABC_OKC.
      You simply must correctly stop your torrents (or ABC_OKC) as I said 2 posts above so that the "stopped" event is sent to the tracker. Then when ABC_OKC is restarted, the started event is sent and the downloaded/uploaded number of bytes are consequently reset to zero.
      The client will not remember from a session to the next if the stopped event was correctly sent or not because the system was brusquely rebooted without stopping the torrents.

       
    • kratoak5
      kratoak5
      2007-08-21

      Hum, we wrote at the same time !

       
    • kratoak5
      kratoak5
      2007-08-21

      So, after correctly stopping torrents, the only problem that may occur when restarting ABC_OKC with the same id is a rejection from the tracker is the restart comes too soon after the closing of ABC_OKC, but if this happens this should work right at the next announce.

       
    • Open Sesamo
      Open Sesamo
      2007-08-21

      He... I return thinking in this.

      Of course, if i stop the torrent correctly, the tracker close the session hash+peer_id and to the next restart all is fine.
      But if the electricity is down, or i close quickly the computer because i need part (Press Off Button), then we have a problem.
      If i wait for the tracker shutdown my session, or i change the peer_id don't happen
      Usually is not a problem, except the first time that you don't know.
      If you are downloading there are no problems.
      But if you are seeding, recovering ratio and don't know the issue, for sure will have a problem.

      Good Night ;)

       
    • kratoak5
      kratoak5
      2007-08-21

      OK, the next build should have some way of designing custom IDs patterns with fixed parts and parts randomly generated for each torrent within some range (digit, uppercase or lowercase letters), to cover all known client ID patterns.

       
    • Open Sesamo
      Open Sesamo
      2007-08-21

      Really very apreciated... Thanks.
      The time i spent discovering the reason,
      the times i see the code to find a logical reason for the warning in the tracker.

      The best is the BitTornado, because in most of the tracker's is allowed.
      There are operating systems that do not accept other client.
      Is the best, do not exchange peers, do not open udp ports, do not have dht... Perfect.
      And the gui of the ABC is the best to resume torrents and control all the system.

      The uTorrent have a system to determine if the peer_id is own or not, and appears in the client as 'Fack'.
      The best don't try emulate this.
      The ABC users are Honored users.