Force start and event key protocol question.

[mistaknly]

Firon, or whoever.....

First I tried to read the protocol spec, search the forums and also did a packet sniff but couldn't tell if there was any difference in the event key sent to the server on start vs force start. So I'd thought I'd ask the experts.

• Is there anyway a server can tell if you "did not" force start a 100% complete seed?
  Is there a different key sent to the server for start and force start?
  Any difference in regular tracker updates information or in tracker update timing schedule?
  Is there any other impact other than queue bypass if you're seeding multiple files to multiple trackers in addition to the "force start" tracker?
  

Sorry if the wording or vocabulary isn't correct.

Thanks

PS, couldn't get LIST to work correctly. What did I do wrong?

[ciaobaby]

Is there anyway a server can tell if you "did not" force start a 100% complete seed?

No. There is no server involved in peer to peer networking.

Is there a different key sent to the server for start and force start?

No,

Any difference in regular tracker updates information or in tracker update timing schedule?

No

Is there any other impact other than queue bypass if you're seeding multiple files to multiple trackers in addition to the "force start" tracker?

A torrent payload is 'seeded' to peers not trackers.

PS, couldn't get LIST to work correctly. What did I do wrong?

No idea, as we don't what you did or didn't, as the case maybe.

Forum BBCode

[mistaknly]

Is there anyway a server can tell if you "did not" force start a 100% complete seed?

No. There is no server involved in peer to peer networking.

Is there any other impact other than queue bypass if you're seeding multiple files to multiple trackers in addition to the "force start" tracker?

A torrent payload is 'seeded' to peers not trackers.

I'm specifically talking about tracker server to client seeder communication. Not P2P peer payload. From the spec:

Tracker GET requests have the following keys:

info_hash

• The 20 byte sha1 hash of the bencoded form of the info value from the metainfo file. Note that this is a substring of the metainfo file. The info-hash must be the hash of the encoded form as found in the .torrent file' date=' regardless of it being invalid. This value will almost certainly have to be escaped.
  [/list']
  peer_id

1. 
   
2. A string of length 20 which this downloader uses as its id. Each downloader generates its own id at random at the start of a new download. This value will also almost certainly have to be escaped.
   ip

• An optional parameter giving the IP (or dns name) which this peer is at. Generally used for the origin if it's on the same machine as the tracker.
  

port

• The port number this peer is listening on. Common behavior is for a downloader to try to listen on port 6881 and if that port is taken try 6882, then 6883, etc. and give up after 6889.
  

uploaded

• The total amount uploaded so far, encoded in base ten ascii.
  

downloaded

• The total amount downloaded so far, encoded in base ten ascii.
  

left

• The number of bytes this peer still has to download, encoded in base ten ascii. Note that this can't be computed from downloaded and the file length since it might be a resume, and there's a chance that some of the downloaded data failed an integrity check and had to be re-downloaded.
  

event

• This is an optional key which maps to started, completed, or stopped (or empty, which is the same as not being present). If not present, this is one of the announcements done at regular intervals. An announcement using started is sent when a download first begins, and one using completed is sent when the download is complete. No completed is sent if the file was complete when started. Downloaders send an announcement using stopped when they cease downloading.
  

So what I'm asking is there a slightly different "started" optional event key that informs the server if the client has "force started"? And if the key doesn't change for force start does the tracker have any other way of telling if you started or force started?

Like I said, maybe I'm getting the wording wrong....when I said server before I meant the "server" (aka torrent site) which also has some machine (same or different as the web site) being used as a torrent tracker at some server farm somewhere. I'm not trying to get into an architecture discussion, so I just said server generically to make it simple. I realize that some trackers do not record any of this information, but some do. This particular site does record the "Tracker GET" request information. I hope I've been more clear this time. If not, I'll keep trying. I'm bound to guess right eventually...;>

Thanks for your help. http://forum.utorrent.com/img/smilies/smile.png

PS, couldn't get LIST to work correctly. What did I do wrong?

No idea, as we don't what you did or didn't, as the case maybe.

Forum BBCode

Thank you for the link. I see my mistake and what I needed to add to get list to work correctly.

[ciaobaby]

So what I'm asking is there a slightly different "started" optional event key that informs the server if the client has "force started"? And if the key doesn't change for force start does the tracker have any other way of telling if you started or force started?

Nope, for the tracker "started" is "started" regardless of how the job was started, and "stopped" is "stopped" regardles of how it was stopped.

"Server" is not an appropriate terminology replacement for "tracker", trackers are simply 'relay points' to inform other peers where a particular job may be found, and of course, peers may also act as trackers.