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