====================================================================== R E A D M E doc: Fri Mar 6 16:04:58 1992 dlm: Fri Jul 3 12:20:30 1992 (c) 1992 ant@ips.id.ethz.ch uE-Info: 58 8 T 0 0 72 3 2 8 ofnI ====================================================================== Whatis Inetray -------------- Inetray is an application allowing you to raytrace an image using a lot of machines. The task is dynamically distributed to all machines offering this service. Requirements ------------ You need the following software libraries to run Inetray: - BSD-style sockets - SUN rpc-library (at least version 4.0) - SUN xdr-library (at least version 4.0) - rayshade 4.0.6 The only thing you probably need to check is if you have the SUN rpc-library since this uses the other two communications libraries. On all machines where you want to run servers, you need to have a local portmapper running. Documentation ------------- README This file POO Principles of operation; some internals INSTALLATION compilation & installation manual SUPPORT supported machines and quirks FAQ Frequently asked questions HISTORY A short program history (patches, releases, ...) TODO Things to do (Todo que nunca voy a hacer...) Examples -------- Any rayshade examples work, but I included an image which uses lots of CPU time to calculate. It's called mole.ray. Copyright --------- Feel free to copy the software for non-commercial purposes. Note, however, that this software is not GNU; this means that it was never intended to be a monster and I will not allow it to become one. Author ------ Andreas Thurnherr (ant@ips.id.ethz.ch), working at the IPS (Interdisziplinaeres Projektzentrum fuer Supercomputing) at the ETH in Zurich, Switzerland. Support ------- I will try to give limited support to people trying to port Inetray to new machines; you can mail me to the address given above. Please read the docs before mailing me. Credits ------- I'd like to thank the people of IPS for allowing me to use their machines for the development of Inetray - parts of it was also developed during work hours. Furthermore, I'd like to thank the team of active beta-testers (David DeBry, Marvin Landis, Michael Graff, Benny Yih and Rick Braumoeller - I sure hope I didn't forget anybody) for sticking with me thru all the 0.X.X versions, bugs and features. Special thanks to Nikolaos Fotis from Greece who wanted everything, refused to read the docu and really influenced the user friendliness a lot. Components ---------- Inetray consists of the following executables: inetray the frontend dispatcher; the client rpc.inetrayd the worker; the server inetray.ping pinger to check response of servers inetray.kill killer; kills all running servers inetray.start startup daemon for rpc.inetrayd rpc.dereg deregister utility for SUNRPC netinfo prints all network addresses of local host Terminology ----------- The terms worker and server both refer to rpc.inetrayd. The server is the parent, servicing RPC requests; the worker is the child doing the actual work. The terms dispatcher and client both refer to inetray. Runtime Errors -------------- All runtime errors of the workers (servers) are logged to the syslog. If they seem to crash unexpectedly (or don't respond at all), check the syslog first. If you set NOASYNCIO_QUIRK while compiling, the error messages go to temp-files. See SUPPORT for details. Weird Behaviour --------------- Sometimes, inetray seems to behave weirdly (e.g. it worked yesterday, but today a server on a machine doesn't seem to terminate). I had those problems only on SUNs (but then again, I use more SUNs than other machines). The usual solution to the problem is rebooting the machine. This is highly unnice, but sometimes necessary. Random Numbers -------------- On different architectures, the random generator used by rayshade 4.0 may generate different sequences. This problem has to be fixed in rayshade since I won't change any code in those libs. I think it will be fixed in the next release. inetray [params] ---------------- is supposed to be compatible with ``rayshade''. You can, however, not use it in a pipe. When you start it up, it replies by giving a Session Key (see POO for details), followed by the list of servers which replied. The list has the following form: inet# host[pid] username working_directory After that the total number of workers is given followed by scheduling information. After the trace has been completed a sorted statistics is printed. You can get to this statistic any time during the trace by interrupting (SIGINT) the program. Interrupting it again while nothing has changed, gives you the option to abort the program orderly. If you terminate inetray without a shutdown, you'll probably have to issue an inetray.kill to kill all workers and servers. If you don't do that, the servers will shut themselves down after approximately 1 minute. rpc.inetrayd ------------ is the server-daemon. It is started either by inetd or by inetray.start. On receiving a request, it forks a worker and continues waiting. There can, however only be one request outstanding any one time. Roughly once every minute the server checks if the dispatcher is still running. If that's not the case, it kills its worker (if it exists) and exits with an error message in the syslog. NOTE: you never start this program from the command-line (see INSTALLATION to find out how you DO start it) inetray.ping [Use List] ----------------------- is a pinger utility. It checks if servers are ready to run for you. To find out, if a specific server is ready to run, you just write ``inetray.ping hostname'', if you want to check which workers are ready to run, you run inetray.ping without any arguments. The argument list can be arbitrarily complicated. Example: ``inetray.ping foo UID=12, bar, 124.130.34.0 N=2 UID=13, \ local N=0, multi N=16'' See Appendix B in INSTALL for details about the Use List. Note: If you install workers using Inetd, you may get warnings when running inetray.ping for those hosts. inetray.kill [key] ------------------ kills all running servers even if they're currently computing. Since killing works only with the correct session key, inetray.kill needs to have this key. Usually it takes it from .inetray.key in the current directory. This file is written by inetray. You can, however, supply your own key (to override .inetray.key) by supplying it on the command line. inetray.start [path of rpc.inetrayd] ------------------------------------ starts rpc.inetrayd (one or more) on request. Another method is to have them started by inetd. See INSTALLATION for details. rpc.dereg [prognum versnum] --------------------------- deregisters the indicated program/version with the local portmapper. Note that the same functionality is offered by rpcinfo(8) but it requires root privileges (another great show of SUN security) netinfo ------- prints a list of all network interfaces, local addresses and broadcast addresses installed on the local host. If the host is set up correctly, it should react to all addresses given. Actually only the inet interfaces which listen to broadcasts are printed! Note that if netinfo shows more than one interface, the machine is a gateway; you should not run inetray (the dispatcher) on a gateway since it produces lots of traffic on both networks!