Client Behavior questions
"Jeff R. Allen" <jallen@muddcs.cs.hmc.edu> Thu, 20 October 1994 08:32 UTC
Received: from ietf.nri.reston.va.us 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 ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa01344; 20 Oct 94 4:32 EDT
Received: by ucdavis.ucdavis.edu (8.6.9/UCD2.50) id BAA09665; Thu, 20 Oct 1994 01:22:31 -0700
X-Orig-Sender: ietf-wnils-request@ucdavis.edu
Received: from muddcs.cs.hmc.edu by ucdavis.ucdavis.edu (8.6.9/UCD2.50) id BAA09661; Thu, 20 Oct 1994 01:22:30 -0700
Received: by muddcs.cs.hmc.edu (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" <jallen@muddcs.cs.hmc.edu>
Message-Id: <9410200821.AA20997@muddcs.cs.hmc.edu>
To: ietf-wnils@ucdavis.edu, elecia@muddcs.cs.hmc.edu, dbethune@hmc.edu, dwelling@hmc.edu, jeff@hmc.edu, tclinton@hmc.edu
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 hmc.edu server(s)? Right now the only way I can think of doing it would be to hit the "root" server being run at info.sunet.se in Sweeden, asking it: Harvey:format=handle:hold Mudd:format=handle:hold Jeff:format=handle:hold Allen:format=handle (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."
- Client Behavior questions Jeff R. Allen