[Yazlist] Z39.50 operating situations

Mike Taylor mike at indexdata.com
Thu Feb 14 12:26:09 CET 2008


$,1(7(P(e(P(`(^(R(B $,1(0(](T(`(U(Y(B writes:
 > hello, i am interesting in such questions:

Hi, Andrey.  Intreresting questions.

 > 1)As we know Z39.50 server can forward search requests to another Z39.50 
 > servers)) and request path can be very long
 >  Server1 -> Server2 -> Server3 -> ... ->ServerN
 > Is their some kind of timeout or smth, or may be request depth can be 
 > tuned up somehow?

Although what you're describing is possible, I've never heard of it
being done: the longest chain I've seen is a client talking through a
proxy to a server.  So all my answers are hypotheticals.  In general,
it's up to the proxies to decide on and implement a policy for
timeouts and suchlike; unlike the situation with web proxies, there
are not enough Z39.50 proxy implementations or deployments for a set
of best-practice guidelines to have grown up.

 > 2)and we can imagine situation that request path will be rounded
 >  Server1 -> Server2 -> Server3 -> Server1
 > Clarify this to me, please. how can we solve such kind of problem?

I believe that, at present, there is no way to avoid this except by
having the human configurer know what the sequence of delegations is.
It would be possible for Z39.50 APDUs (protocol packets) to carry an
otherInfo package listing the servers that it's already been through,
so that looks can be detected, but to the best of my knowledge that's
never been proposed or implemented.

 > 3) z39.50 server can make search in different places simultaneously
 >                   / server1.db
 > server1 -> |  server2
 >                   \ server3

Well, the proxy that you're calling server2 here is more than just a
server: it's doing something pretty sophisticated, and believe me _a
lot_ of issues emerge when you do this.  As far as I know, there is
only one program that does this -- our own Metaproxy
	http://indexdata.com/metaproxy/

Anyway --

 > imagine situation that first request is completed in 0.1 sec and 5 
 > records found, second  2  sec and 20 records found, and third 20 sec 
 > (for example) and 3000000 records found.
 > 3.1) Does it mean, that request operation time equals 20 sec?
 > 3.2) Can server1 return data partially, as its subrequests are complited? 
 > 3.3) How does server1 make multiplexing for such great data volume, as 
 > request result need to be sorted?
 > 3.4) what if one of the referenced servers is down? how server1 can find 
 > it out?

These are entirely matters for the fanout proxy to decide: there is no
established best-practice, and what is "best" will be different in
various situations (e.g. are the back-end servers local or remote, do
they hold similar or different kinds of data).  Specifically:

 > 3.1) Does it mean, that request operation time equals 20 sec?

If the proxy chooses to wait that long, yes; or it might be configured
just to go with what it has after ten seconds.

 > 3.2) Can server1 return data partially, as its subrequests are
 > complited?

It wouldn't be able to have an accurate hit-count, which may be a
problem.  Also most (all?) Z39.50 clients are written in such a way
that they don't start requesting records until the search is complete.
A while back I started writing an Implementor Agreement whereby a
server could report partial results and subsequently update them, but
I never even finished writing the specification for that, let alone
code :-)  For it to be useful, you'd also need to dramatically change
the way your client works.

 > 3.3) How does server1 make multiplexing for such great data volume,
 > as request result need to be sorted?

Implementation-defined.

 > 3.4) what if one of the referenced servers is down? how server1 can
 > find it out?

It finds out when its subrequest fails!  Then it's matter of
implementation or configuration whether the top-level request fails,
or does the best it can with the servers that are working.

 > Any useful help will be highly appreciated. Thanks
 > 
 > Andrey
 > PS sorry my english

Your English is fine!

 _/|_	 ___________________________________________________________________
/o ) \/  Mike Taylor    <mike at indexdata.com>    http://www.miketaylor.org.uk
)_v__/\  "It is the job of the critic to tell people what they ought to
	 like and it must be pretty galling when they don't do as they're
	 told" -- Andrew Rilstone.




More information about the Yazlist mailing list