X-Git-Url: http://git.indexdata.com/?a=blobdiff_plain;f=doc%2Fusing.xml;fp=doc%2Fusing.xml;h=f6106f8aa71cfceb6166b3db83cfd8d653041d6e;hb=101d9c2ca072f3cd7fb6cb89c67573318b14b8c1;hp=0000000000000000000000000000000000000000;hpb=05d22caabccd8dba7ae2b6405bb42e6dc0641ed8;p=yazproxy-moved-to-github.git diff --git a/doc/using.xml b/doc/using.xml new file mode 100644 index 0000000..f6106f8 --- /dev/null +++ b/doc/using.xml @@ -0,0 +1,145 @@ + + Using YAZ proxy + + As mentioned in the introduction the YAZ proxy has many uses. + This chapter includes a few examples. + + + -- All config directives -- + -- SRW/SRU .. + -- Example config + -- Mention XSLT conversion + + + The YAZ Proxy is useful for debugging SRW/SRU/Z39.50 software, logging + APDUs, redirecting Z39.50 packages through firewalls, etc. + Furthermore, it offers facilities that often + boost performance for connectionless Z39.50 clients such + as web gateways. + + + Unlike most other server software, the proxy runs single-threaded, + single-process. Every I/O operation + is non-blocking so it is very lightweight and extremely fast. + It does not store any state information on the hard drive, + except any log files you ask for. + + + + Using the Proxy to Log APDUs + + Suppose you use a commercial Z39.50 client for which you do not + have source code, and it's not behaving how you think it should + when running against some specific server that you have no control + over. One way to diagnose the problem is to find out what packets + (APDUs) are being sent and received, but not all client + applications have facilities to do APDU logging. + + + No problem. Run the proxy on a friendly machine, get it to log + APDUs, and point the errant client at the proxy instead of + directly at the server that's causing it problems. + + + Suppose the server is running on foo.bar.com, + port 18398. Run the proxy on the machine of your choice, say + your.company.com like this: + + + yazproxy -a - -t tcp:foo.bar.com:18398 tcp:@:9000 + + + (The -a - option requests APDU logging on + standard output, -t tcp:foo.bar.com:18398 + specifies where the backend target is, and + tcp:@:9000 tells the proxy to listen on port + 9000 and accept connections from any machine.) + + + Now change your client application's configuration so that instead + of connecting to foo.bar.com port 18398, it + connects to your.company.com port 9000, and + start it up. It will work exactly as usual, but all the packets + will be sent via the proxy, which will generate a log like this: + + + + + + + +