Quoting Jeroen Asselman <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel:
:Op 20-sep-04 om 8:17 heeft Raphael Manfredi het volgende geschreven:
:> Also perhaps PARQ should be re-implemented from scratch now that we
:> have
:> some experience with it. Like they say, "throw One away".
:>
:That
Op 19-sep-04 om 20:46 heeft Haxe het volgende geschreven:
And then this request would be answered with another 404.
I can see no possibility in this model how a peer can be persistently
listed as queued in the uploads gui table, if the file he requested
didn't exist for many hours. But I have seen
Op 20-sep-04 om 8:17 heeft Raphael Manfredi het volgende geschreven:
Also perhaps PARQ should be re-implemented from scratch now that we
have
some experience with it. Like they say, "throw One away".
That sounds almost as if you think my implementation is flawed ;)
- Jeroen
Quoting Jeroen Asselman <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel:
:GTK-Gnutella _does_ send a 404, (at least it should do so unless there
:is a bug), but the PARQ ID remains valid.
Which is OK.
:It isn't the HTTP error code that causes the 'trouble' it is the PARQ
:ID which remains
Quoting myself:
> 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.
This observation may be incorrect, but the solution stays the same.
h
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'
On Sunday 19 September 2004 19:25, Jeroen Asselman wrote:
> GTK-Gnutella _does_ send a 404, (at least it should do so unless
> there is a bug), but the PARQ ID remains valid.
To Christian:
This (quoted above from Jeroen) is exactly what we just talked about
(keep slot after 404). It's exactly wha
On Sunday 19 September 2004 19:25, Jeroen Asselman wrote:
> GTK-Gnutella _does_ send a 404, (at least it should do so unless
> there is a bug)
If that is true, and not only for the first request but for every single
re-request, than our whole discussion here _may_ be pointless.
> It isn't the HTT
On Sunday 19 September 2004 19:19, Jeroen Asselman wrote:
> > Does the "remanence" proposition of the PARQ spec currently also
> > apply to already active uploads?
>
> No, when you managed to get an upload slot you are not allowed to
> change your mind again.
Oh, I wasn't referring to the changing-
Op 19-sep-04 om 17:11 heeft Haxe het volgende geschreven:
Rethinking the queuing issue, I must say that I'm still not convinced.
If testing if the file exists on each queue re-try, and sending a 404
if appropriate breaks the current specs, then that's a no-no.
In the following, I want to give argum
Op 19-sep-04 om 18:54 heeft Haxe het volgende geschreven:
You could, in theory, keep the slot and allow further requests with
the same queue ID.
BTW, what happens to your queue ID once you get to a free slot?
Does the "remanence" proposition of the PARQ spec currently also apply
to already active u
> You could, in theory, keep the slot and allow further requests with
> the same queue ID.
BTW, what happens to your queue ID once you get to a free slot?
Does the "remanence" proposition of the PARQ spec currently also apply
to already active uploads? Or do I, as a client, have to wait the whole
On Sunday 19 September 2004 18:27, Christian Biere wrote:
> The chances that the queue ID is valid then are pretty close to zero.
That's right, of course. But that doesn't apply to the fist request,
when there's no ID at all. I think the server shouldn't make a
difference at all between the first
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
>
On Sunday 19 September 2004 17:33, Christian Biere wrote:
> If we're actually talking about the case in which a client is queued
> but the file appears to be absent when the transfer is supposed to
> start, I'd suggest to use "410 Gone" instead. This would help to
> differ between bugs which cause
Haxe wrote:
> Rethinking the queuing issue, I must say that I'm still not convinced.
> > If testing if the file exists on each queue re-try, and sending a 404
> > if appropriate breaks the current specs, then that's a no-no.
> In the following, I want to give arguments for three points:
> 1. Se
Rethinking the queuing issue, I must say that I'm still not convinced.
> If testing if the file exists on each queue re-try, and sending a 404
> if appropriate breaks the current specs, then that's a no-no.
In the following, I want to give arguments for three points:
1. Sending a 404 doesn't viol
> And this includes points 1-4:
> No, I won't break the PARQ specs. This is just an idea which I think
> could be the successor of the current version.
> No, it won't break older clients. Because we can determine by the
> queuing version if it can be done, even if we don't it won't break
> older gt
Fair enough, Haxe makes good points.
As long as a 404 is sent when a file no longer exists (to stop a client
fruitlessly re-queuing), that should be enough.
---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins
On Saturday 18 September 2004 02:05, Jeroen Asselman wrote:
> What I propose could be made
> transparant and nobody would notice
If that's true, and if it really leads to smooth uploads, I'd be OK with
that :-)
Haxe
---
This SF.Net email is sp
Op 17-sep-04 om 23:55 heeft Haxe het volgende geschreven:
On Thursday 16 September 2004 22:11, Jeroen Asselman wrote:
That is why I'd like to propose another implementation. Instead of
queueing per client, which is what PARQ actually tries to achive,
lets queue per file.
...
What do you think?
For
On Thursday 16 September 2004 22:11, Jeroen Asselman wrote:
> That is why I'd like to propose another implementation. Instead of
> queueing per client, which is what PARQ actually tries to achive,
> lets queue per file.
...
> What do you think?
For the following reasons, I don't think that this wo
Op 15-sep-04 om 21:57 heeft Jamie Jones het volgende geschreven:
In bish.lists.gtk-gnutella.devel, you wrote:
I think the feature of PARQ, that the clients can change their minds
before reaching a free slot, is indeed a good and necessary feature,
so
that the client can choose the _range_ of the f
In bish.lists.gtk-gnutella.devel, you wrote:
> I think the feature of PARQ, that the clients can change their minds
> before reaching a free slot, is indeed a good and necessary feature, so
> that the client can choose the _range_ of the file he wants to download
> in the last minute. But is th
On Tuesday 14 September 2004 08:25, Jeroen Asselman wrote:
> A PARQ ID is not associated with a file. A PARQ ID is associated with
> a servent. So a QUEUE callback will even be sent if the file is not
> shared anymore. The servent may choose another file to download.
Ok, right, a PARQ ID is not as
Op 14-sep-04 om 3:36 heeft Haxe het volgende geschreven:
On Monday 13 September 2004 20:20, Raphael Manfredi wrote:
: Or, for another example, that I was doing
: two uploads to one single host at the same time, although I set
: 'max uploads per host' to 1. I think there are more examles.
This last
On Monday 13 September 2004 20:20, Raphael Manfredi wrote:
> : Or, for another example, that I was doing
> : two uploads to one single host at the same time, although I set
> : 'max uploads per host' to 1. I think there are more examles.
>
> This last one is a bug, yes.
Oh, great timing, I right n
Quoting Haxe <[EMAIL PROTECTED]> from ml.softs.gtk-gnutella.devel:
:There are also other issues I have encountered with the queueing of
:uploads. For example, that one peer is queued although there was a free
:upload slot left. Or, for another example, that I was doing two uploads
:to one single
28 matches
Mail list logo
