Op vr 07-11-2003, om 16:25 schreef Jonas Sonntag: > 2. Fileinfo tab is not updated correctly: > > 2.1 available sources are not displayed correctly: a source is not added > to the available sources count in certain states (e.g. when the source > is in state 'Push sent' if i remeber it right)
As far as I understood, this also happens with the GTK1 frontend. > 4. maybe this is known allready: i can overwrite max_ultrapeers = 4 with > up_connections when in ultrapeer mode max-ultrapeers is a leaf setting only. Frontends should probably not display this setting when in non leaf mode. > 5. not a bug, but i noticed that _a lot_ of clients are removed from > parq again and again because they are re-requesting files too fast. it > looks like we are removing 90% of all parq slots because the clients > don't behave like they should. these are not only the usual suspects > lime/bear but also gtkg clients. now i'm sure this is meant as a good > thing in theory, but it makes it practically impossible for most of the > clients to get 10 files from my share. they get 2 upload slots, the > other 8 are queued and taken to the end of the queue over and over again > so they will never get the requested files. maybe gtkg is a bit too > conservative here? All clients which do not respect the Retry-After header (the delay after which a client may retry its download attempt) will most probably be banned. Unless the retry rate is high (20 minutes or more). Of course this can happen with GTK-G clients too: That is when a user manually forces a retry. GTKG is rather polite (I think) 1st attempt: You get queued 2nd (too early attempt): You get a warning, and not the full PARQ headers are sent, however you are still queued 3rd (too early attempt): Now you are removed from the PARQ (so you are back to the end of the queue) 4th (too early attempt): Then you have done it, you are banned for a while. All download requests are simply ignored. And it is treated as a hammering attempt. As you see, you can always retry 1 time to early, which has no consequences but a warning only. > 6. again parq: i noticed that even when there are slots available, all > download requests are queued first. sometimes they get something like > 'try again in 0s' reply. fact is i have never seen all of my 10 upload > slots occupied even when there are 20+ clients queued. i haven't thought > of a theory yet, but it definitly looks a bit strange. Depends on how you look at it. The logic in PARQ actually allows this behaviour (on purpose). For example, when the retry rate is 20 minutes, and no-one else before you wants that file anymore, you can assume you actually have a spare slot for 20 minutes until that client retries again. Unless they implement PARQ, because as soon as a position is available a signal is sent to the client that it may attempt to download immediatly. > 8. and finally a 'bug' that is more like user stupidity ;P .. but maybe > could be worked around: my temp directory is a subdirectory within one > of my shared directories. when i reshare and there are active downloads > gtkg will loop with 'file xxx has changed while calculating sha1' as > long as the download is active. maybe it could notice that this is a > partial file and skip it? it should be shared anyway by pfs i think? Well it won't share the file :), ok, so the warnings are anoying. However it detects that it is a PFS file and will only share it as such. -- Jeroen Asselman <[EMAIL PROTECTED]>
signature.asc
Description: Dit berichtdeel is digitaal ondertekend
