Lots of more stuff about queuing, including my solution.
On Sunday 19 September 2004 19:25, Jeroen Asselman wrote:
> It isn't the HTTP error code that causes the 'trouble' it is the PARQ
> ID which remains valid which is causing the problem. A QUEUE is sent
> to the requesting client if it didnt' request 'in time'.
As I said in a previous mail, I think this isn't really the problem,
because the following request should be answered with another 404. But
you are still right that a callback will be sent given that the ID
remains valid. I think this can also be solved, even if the ID does
indeed remains valid, which I think is good.
I have a solution in mind, and I would LOVE to code it myself, but I
still lack the competence to do that (although I, for a beginning,
successfully solved the two "code 101" questions on the homepage :-)),
so I will instead describe it here.
But first another thing: I've done a little more research. I've
downloaded a file, and later deleted it. Note that, when I'm talking
about deleting a shared file, I was always talking about deleting a
just downloaded file, not one in my shared folder.
After several hours, I still saw peers listed as queued in the upload
pane persistently, not only for a few seconds, so it looked like active
queuing to me (not particularly synchronous queuing, I think, since
there was a "lifetime" mentioned, which is only sent on asynchronous
connections, and since the remote clients were not gtkg).
Then I triggered the "rescan files" button in the uploads config. After
doing that, lots of 404s were sent, and the actively queued peers
disappeared after short time! My first thought was "oh, it's all only a
caching problem". But that was not completely correct. I still saw
messages saying "queued" for that file, but that were apparently only
the passive queues left. Now my impression is the following:
1. For active-queue requests, the file is being checked, but only
against an internal cached list.
2. For passive-queue requests, the file is not being checked at all.
3. The "rescan files" button does something that it seems not to be
supposed to: It also has to do with files that are not in the shared
folder.
Now my solution to the whole discussion would be the following:
(comments please)
---------------------------------------------------------------------------------------
- Whenever a GET request comes in, regardless of active/passive or if it
is already queued at all, always check if the requested file exists.
Really check against the filesystem, not only against a cached internal
list of gtkg.
- If the file exists, do the usual things: either 503 or 200.
- If the file does NOT exist, do the following: {
- Check if the file is listed in the internal cached list. If it is, {
- Remove that file from the cached list, so that it is no longer being
advertised as shared
- Send a 410 gone
} else {
- Send a 404 not found
}
}
- After a reply is sent (503, 200, 404, 410 or whatever), remember this
last return code associated with this queue ID, so that you can later
check which return code was the last sent to this queue ID
- Whenever you want to send a QUEUE callback, first check what was the
last return code you sent to the respective queue ID. If it begins with
a 4 (i.e. 410 or 404), just skip the QUEUE callback.
------------------------------------------------------------------------------------
Note that I DIDN'T write:
- Whenever you want to send a QUEUE callback, first check if the file
last requested by that ID still exists. If it doesn't, just skip the
QUEUE callback.
I didn't write this because a client should know that a file doesn't
exist on the server any longer. If you'd just skip the callback when
the file is gone, the client could merely guess that. By remembering
the last return code, the client will receive at least one definitive
4**.
BTW: When a file is completely downloaded, it is still being
automatically shared, although it is neither in my shared folder nor
still being downloaded. Of course, this is good, and a purposeful
behaviour. But what happens when I then press the "rescan files"
button? Will the completely downloaded file be suddenly unshared?
Haxe
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Gtk-gnutella-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
