Haxe wrote: > I originally brought up the whole discussion because I deleted a > formerly shared file. But there are other reasons why this could occur. > We live in a world of dynamic IP addresses. One peer can close his > connection, and another peer can incidently get his IP address. So he > will then get requests for non-existent files.
The chances that the queue ID is valid then are pretty close to zero. Although Shareraza seems to use non-random IDs like "big files", "small files" etc. Maybe that wasn't PARQ but I've seen that. However, gtk-gnutella is not Shareaza and the PARQ specs are pretty clear that the IDs have to be random. > For those reasons, I know intuitionally that it is good to send a 404 > when a requested file didn't exist, and that queuing for a non-existent > file is bad. It's also bad because it makes the queue unnecessary long. This looks like you can easily DoS a servent by sending a couple PARQ requests which will significantly slow down transfers for each other. > Really. As I said before, I don't think that sending a 404 > would violate the PARQ specs at all. I second that. The specs do *suggest* that you can use the same queue ID for different files but this looks more like a premature feature especially because the specs do not discuss the necessary details i.e., error handling - the topic of this thread. If this was really a core feature, the specs had to be more elaborate and consequent i.e., not alternate between "slot" and "file" but stick to the former. I also doubt that this isn't on par with usual HTTP behaviour. You simply cannot determine whether the HTTP response code belongs to the queue ID or the request URI. This is an inacceptable ambiguity in my opinion. > But if you REALLY think that it > does violate the specs, then those specs are bad and have to be changed > to allow a 404. You could, in theory, keep the slot and allow further requests with the same queue ID. However, I consider much more complicated than useful. I honestly see no problem at all with returning a 404 and removing the slot. -- Christian
pgpTgPLMbYkEd.pgp
Description: PGP signature
