Client Behavior questions

"Jeff R. Allen" <> Thu, 20 October 1994 08:32 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa00548; 20 Oct 94 4:32 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa00536; 20 Oct 94 4:32 EDT
Received: from by CNRI.Reston.VA.US id aa01344; 20 Oct 94 4:32 EDT
Received: by (8.6.9/UCD2.50) id BAA09665; Thu, 20 Oct 1994 01:22:31 -0700
Received: from by (8.6.9/UCD2.50) id BAA09661; Thu, 20 Oct 1994 01:22:30 -0700
Received: by (5.0/SMI-SVR4) id AA20997; Thu, 20 Oct 1994 01:21:24 -0700
Date: Thu, 20 Oct 1994 01:21:24 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Jeff R. Allen" <>
Message-Id: <>
Subject: Client Behavior questions
content-length: 2057

Remeber me? The guy writing a Whois++ Client Library? I'm baaack. :)

I have read over the mesh document, and understand the algorithm that
clients will follow (including loop detection). I just can't really
figure out how a client would resolve a query like this:

"I know his name is Jeff Allen, and that he goes to someplace named
Harvey Mudd."

Where does OriginalServers come from? How will the client know to
expand the search to make it wide enough to hit the server(s)?

Right now the only way I can think of doing it would be to hit the
"root" server being run at in Sweeden, asking it:


	(Multiple searches are required since KTH whoisd doesn't seem
	to do and's and or's yet. BTW: HMC is not yet listed since we
	have no public servers yet.)

Using the results here, hopefully I'd be able to find a template of
type DIRECTORY from which to gather a hostname and port for the next
connection. (The client has no reason to suspect "Jeff" and "Allen" of
being any less likely to be server names, so it has to look them up
with the root server too.)

Anyway, from the handles I get back (which I then convert to
hostnames/ports by expanding the handles of type directory) I can
setup OriginalServers and then run the algorithm in the Mesh document.

This seems non-optimal to me. I am doing a fair number of expensive
operations on the _single_ root server (and introducing a single point
of failure and inconsistency) just whistling in the dark trying to
find a server likely to have info I am interested in. And, for some
queries, it could happen that OriginalServers will grow to an
unreasonable size. How do we intend to solve the initial server
discovery problem?

Thanks for reading along and forwarding comments. Perhaps one of the
protocol architects can help me out here.

Jeff R. Allen  |  semi-Senior CS major  |    "No, sir, that's a fish.
(fnord)        |    South 351d, x4940   |     A catfish, to be certain."