Ian Clarke wrote:
Brandon Low wrote:
On Tue, 11/11/03 at 00:44:38 +, Ian Clarke wrote:
Node A wants something from Node B.
A sends a request to B
A replies and says "wait X"
B says to itself "OK, I'll wait X"
No, A sends a request to B. B eventually send a response which,
along with the data
Ed Tomlinson wrote:
On November 11, 2003 05:55 am, Ian Clarke wrote:
It is free to send another request after X seconds, if A doesn't know
what X is yet then it assumes X is 0 and is free to send another request
immediately.
And X is 0 after anything other than a QR?
No, a DataReply can set X to be
On November 11, 2003 05:55 am, Ian Clarke wrote:
> Ed Tomlinson wrote:
> > On November 10, 2003 08:13 pm, Brandon Low wrote:
> >>Absolutely NOT, if node A waits for it's next request until it gets a
> >>response to it's first request, we have just gone to a protocol with
> >>worse problems than TCP
Ed Tomlinson wrote:
On November 10, 2003 08:13 pm, Brandon Low wrote:
Absolutely NOT, if node A waits for it's next request until it gets a
response to it's first request, we have just gone to a protocol with
worse problems than TCP w/o tcp transmit windows. This would cause
nodes like mine or th
Brandon Low wrote:
On Tue, 11/11/03 at 00:44:38 +, Ian Clarke wrote:
Node A wants something from Node B.
A sends a request to B
A replies and says "wait X"
B says to itself "OK, I'll wait X"
No, A sends a request to B. B eventually send a response which, along
with the data, or a QR, or a DNF
Yeah, it could be accounted for... meh...
On Mon, 11/10/03 at 20:49:59 -0500, Ken Corson wrote:
> Brandon Low wrote:
> >On Mon, 11/10/03 at 20:25:50 -0500, Ken Corson wrote:
> >
> >>Brandon Low wrote:
> >>
> >>>Absolutely NOT, if node A waits for it's next request until it gets a
> >>>response to
On November 10, 2003 08:13 pm, Brandon Low wrote:
> On Tue, 11/11/03 at 00:44:38 +, Ian Clarke wrote:
>
> > Brandon Low wrote:
> >
> > > Freenet
> > >doesn't work this way, watch this:
> > >
> > >Node A wants something from Node B.
> > >A sends a request to B
> > >A replies and says "wait X"
>
Brandon Low wrote:
On Mon, 11/10/03 at 20:25:50 -0500, Ken Corson wrote:
Brandon Low wrote:
Absolutely NOT, if node A waits for it's next request until it gets a
response to it's first request, we have just gone to a protocol with
worse problems than TCP w/o tcp transmit windows. This would caus
On Mon, 11/10/03 at 20:25:50 -0500, Ken Corson wrote:
> Brandon Low wrote:
> >Absolutely NOT, if node A waits for it's next request until it gets a
> >response to it's first request, we have just gone to a protocol with
> >worse problems than TCP w/o tcp transmit windows. This would cause
> >nodes
Brandon Low wrote:
On Tue, 11/11/03 at 00:44:38 +, Ian Clarke wrote:
Brandon Low wrote:
Freenet
doesn't work this way, watch this:
Node A wants something from Node B.
A sends a request to B
A replies and says "wait X"
B says to itself "OK, I'll wait X"
No, A sends a request to B. B eventually
Ian Clarke wrote:
Ed Tomlinson wrote:
What Ken suggested is that B remember what it told A and should not
respond to A at all if it routes early - this forces A to wait for a
timeout... It also helps to perserve the outgoing bandwidth.
Well, I think that is too forgiving. If A routes early the
On Tue, 11/11/03 at 00:44:38 +, Ian Clarke wrote:
> Brandon Low wrote:
> > Freenet
> >doesn't work this way, watch this:
> >
> >Node A wants something from Node B.
> >A sends a request to B
> >A replies and says "wait X"
> >B says to itself "OK, I'll wait X"
>
> No, A sends a request to B. B
Ed Tomlinson wrote:
What Ken suggested is that B remember what it told A and
should not respond to A at all if it routes early - this forces A
to wait for a timeout... It also helps to perserve the outgoing
bandwidth.
Well, I think that is too forgiving. If A routes early then it is
knowingly
Brandon Low wrote:
How? Any node which sends another request before X has elapsed gets
banned?
Well, X is node specific, so any node which sends a request before *its*
X has elapsed is clearly not following the rules and should be banned.
Any node which sends more than 2 before X has elapsed?
We
You and edt win. If we just drop requests on the floor that go over
what we are allowing from another node, it only hurts the requesting
node ont to listen.
The synchronization/network latency issues would be pretty hard to
overcome, how for instance would a timing based approach like this
handle
Brandon Low wrote:
How? Any node which sends another request before X has elapsed gets
banned? Any node which sends more than 2 before X has elapsed? Freenet
Any solution which you find to this will rely on properly behaving other
nodes, and cannot be solved by banning misbehavers.
I respectful
Actually Ken mentioned a good idea. Try this for size
Node A want something from B
A send request to B
B QRs to A saying wait for X
at this point several things can happen
A waits for X before routing to B again
or
A ignores the wait and routes to B when it wants to
What Ken suggested is that B
Ian Clarke wrote:
Ok, we forget about quotas, nice, but overcomplicated.
We add a "don't send a request to me more often than X milliseconds"
field to a few messages sent in response to requests.
Two options about how to calculate X:
1) Empirical
We calculate X to be ((60*60*1000) / M) / T
2) E
How? Any node which sends another request before X has elapsed gets
banned? Any node which sends more than 2 before X has elapsed? Freenet
doesn't work this way, watch this:
Node A wants something from Node B.
A sends a request to B
A replies and says "wait X"
B says to itself "OK, I'll wait X"
Brandon Low wrote:
Thought: It would be easy for some asstard (me) to write a client that
completely disregards these "wait" messages and therefore gets
performance, and market it as 'Freenet-Xtreme' or some damned thing.
We have already been through this a thousand times.
If someone did do this
Thought: It would be easy for some asstard (me) to write a client that
completely disregards these "wait" messages and therefore gets
performance, and market it as 'Freenet-Xtreme' or some damned thing.
--B
On Mon, 11/10/03 at 19:44:47 +, Ian Clarke wrote:
> Ok, we forget about quotas, nice,
Ok, we forget about quotas, nice, but overcomplicated.
We add a "don't send a request to me more often than X milliseconds"
field to a few messages sent in response to requests.
Two options about how to calculate X:
1) Empirical
We calculate X to be ((60*60*1000) / M) / T
2) Experimental
We sta
22 matches
Mail list logo
