dcdev mailing list

Hi,

Search system should have some kind of timestamp (it is to take into account in both binary protocol or text protocol). I have noticed weird things on hubs/bots when a client has an heavily loaded connection to the hub.

Let's say the client is configured to avoid sending search query too close (15s delay between each) and the hub is configured to do something (warn/kick or anything else) if the delay between 2 queries is smaller than 10s.
client events:
T(0) => search query 1 emitted.
T(0->6) => network congestion (the first value can be smaller than 0).
             or big packet loss creating lot of network packet emission.
T(15) => search query 2 emitted.

Technically, the client has waited 15 seconds but on the hub, you will have this:
T(x) => search query 1 received (x>=6 due to network problem)
T(15) => search query 2 received
For the hub, the delay between queries is 15-x (<= 9) seconds

I have experienced such cases on very big hubs and also on heavily loaded connections with traffic shapping or QoS support. My absolute "record" is a hub with a min delay of 15 seconds and a client min delay of 120 seconds.

Eric

On Sunday, December 7, 2003, 15:57:38, eric wrote:

I have experienced such cases on very big hubs and also on heavily loaded connections with traffic shapping or QoS support. My absolute "record" is a
hub with a min delay of 15 seconds and a client min delay of 120 seconds.

IMHO, a time stamp is not necessary, and even if it would be added, the hubs
should never rely on it - otherwise a client could just send faked
timestamps when searching...

-- 
Jernej Simoncic, [email protected]
http://www2.arnes.si/~sopjsimo/
http://deepthought.ena.si/

Nothing will be attempted if all possible objections must first be
overcome.
      -- Golden Principle

Jernej Simon?i? writes:
> On Sunday, December 7, 2003, 15:57:38, eric wrote:
> > > I have experienced such cases on very big hubs and also on heavily loaded > > connections with traffic shapping or QoS support. My absolute "record" is a
> > hub with a min delay of 15 seconds and a client min delay of 120 seconds.
> > IMHO, a time stamp is not necessary, and even if it would be added, the hubs
> should never rely on it - otherwise a client could just send faked
> timestamps when searching...

That was precisely what I was thinking.

However, I think the problem is rather easy to remedy. The hub should
simply ignore the second search request if it comes too early and send
an error back to the client. That way, the client can simply retry at
its convenience.

Also, like I said elsewhere, I think all commands should have an "OK"
return if they succeed. That way, the client will know when it can
start counting the seconds.

Fredrik Tolf

On Sunday, December 7, 2003, 19:39:22, Fredrik Tolf wrote:

However, I think the problem is rather easy to remedy. The hub should
simply ignore the second search request if it comes too early and send
an error back to the client. That way, the client can simply retry at
its convenience.

That's exactly what I was doing in my hub.

Also, like I said elsewhere, I think all commands should have an "OK"
return if they succeed. That way, the client will know when it can
start counting the seconds.

More wasted bandwidth? Upstream is very limited unfortunately...

-- 
Jernej Simoncic, [email protected]
http://www2.arnes.si/~sopjsimo/
http://deepthought.ena.si/

A bird in the hand is safer than one overhead.
      -- Avian Law

Jernej Simon?i? writes:
> On Sunday, December 7, 2003, 19:39:22, Fredrik Tolf wrote:
> > > Also, like I said elsewhere, I think all commands should have an "OK"
> > return if they succeed. That way, the client will know when it can
> > start counting the seconds.
> > More wasted bandwidth? Upstream is very limited unfortunately...

I have to admit that I have not run a hub myself. Now that you say it,
I'd imagine, though. It's just that it would be extremely useful to
get an acknowledgment on every command. Do you think that it's
completely unreasonable? Is a TCP packet wrapping 4 bytes really that
much in proportion to everything else? It would help a lot of things
in the protocol.

Fredrik Tolf

Jan Vidar Krey writes:
> On Sunday 07 December 2003 19:39, Fredrik Tolf wrote:
> > Also, like I said elsewhere, I think all commands should have an "OK"
> > return if they succeed. That way, the client will know when it can
> > start counting the seconds.
> > When you send a search it will be relayed back to the originating client. > Now combine that with a unique search ID, and you'll know the search was > accepted.

That's an interesting thought. I guess in that case, it should be
explicitly defined in the protocol spec that the search must be
relayed back, so that hub writers don't try to optimize it away.

Fredrik Tolf

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 07 December 2003 19:39, Fredrik Tolf wrote:

Also, like I said elsewhere, I think all commands should have an "OK"
return if they succeed. That way, the client will know when it can
start counting the seconds.

When you send a search it will be relayed back to the originating client. Now combine that with a unique search ID, and you'll know the search was accepted.

- -j-

- -- - -janvidar-

Dj Offset / QuickDC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/1C9NMLjmoUcyZAoRAv0KAKCH83aJ7ScY+MpO6IcGa5Kjkbx54QCgutam
7FNHFZI4qFri/Pt0aej9JY4=
=/ZZK
-----END PGP SIGNATURE-----

That was precisely what I was thinking.

However, I think the problem is rather easy to remedy. The hub should
simply ignore the second search request if it comes too early and send
an error back to the client. That way, the client can simply retry at
its convenience.

I must agree that any attempt to measure time intervals between two commands on
a heavily loaded hub is almost impossible even if the nagle algo. isn't used.
Without a kind of timestamping you can't do nothing reliable.
Any chance to use TCP timestamps? Anybody involved in such matter?

Also, like I said elsewhere, I think all commands should have an "OK"
return if they succeed. That way, the client will know when it can
start counting the seconds.

Hmm, why? Somebody here has said "Do not fix, what's not broken". I would vote
for search commands ACKs, but it's running you of sense unlees you know that
every search request is bounced back to the originator ;)
ACKing of other commands is not needed. Most commands used in login sequence are
context-depending, there is always a specific 'answer' to a specific 'question',
so you are getting acknowledgements in form of other commands from the client
(hub).

Fredrik Tolf

Zdenek.

Why would you actually want to include timestamps? IMHO, an error
return is better. There's no point in wanting to kick users who search
too often when you can just return an error instead.

I agree with you.

Also, I might agree that some commands might not need ACKing at all. I
can't think of such a command, though. I really do think that there
should be some kind of ACK for the search command, though. It would
be really useful to know when the search has been accepted.

command like public/private chat command may not need to have an ACK.
"Vote for Fredrik protocol" :-)

Eric

eric writes:
> > > Also, I might agree that some commands might not need ACKing at all. I
> > can't think of such a command, though. I really do think that there
> > should be some kind of ACK for the search command, though. It would
> > be really useful to know when the search has been accepted.
> > command like public/private chat command may not need to have an ACK.
Well, I was thinking that when the chat line gets bounced back, that
could serve more or less as an ACK. But other than that, you're right.

Fredrik Tolf

Zdenek Stangl writes:
> > That was precisely what I was thinking.
> >
> > However, I think the problem is rather easy to remedy. The hub should
> > simply ignore the second search request if it comes too early and send
> > an error back to the client. That way, the client can simply retry at
> > its convenience.
> >
> > I must agree that any attempt to measure time intervals between two
> commands on a heavily loaded hub is almost impossible even if the
> nagle algo. isn't used.  Without a kind of timestamping you can't
> do nothing reliable.  Any chance to use TCP timestamps? Anybody
> involved in such matter?

Why would you actually want to include timestamps? IMHO, an error
return is better. There's no point in wanting to kick users who search
too often when you can just return an error instead.

> > Also, like I said elsewhere, I think all commands should have an "OK"
> > return if they succeed. That way, the client will know when it can
> > start counting the seconds.
> > Hmm, why? Somebody here has said "Do not fix, what's not broken". I
> would vote for search commands ACKs, but it's running you of sense
> unlees you know that every search request is bounced back to the
> originator ;) ACKing of other commands is not needed. Most commands
> used in login sequence are context-depending, there is always a
> specific 'answer' to a specific 'question', so you are getting
> acknowledgements in form of other commands from the client (hub).

Well, that was what I was really referring to. I don't think that
there should necessarily be a return called "OK" to every command - I
just want some kind of ACK. If that ACK is called "NeedPass" instead
of "OK" for a certain command, I certainly don't mind.

Also, I might agree that some commands might not need ACKing at all. I
can't think of such a command, though. I really do think that there
should be some kind of ACK for the search command, though. It would
be really useful to know when the search has been accepted.

Fredrik Tolf