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.