/* SETI UPDATE SERVICE(caddy) 1.4 */ 1.4 Released: 12/29/2002 by David Koenig -=Sections=- 1. Intro(foreword) 2. Installation a) Server b) Client 3. Additional Notes 4. Change Log 5. Planned features 6. Disclaimer 7. Licensing(GPL) 8. Contact info ** FULL SOURCE IS INCLUDED FOR ALL JAVA APPS AND PERL SCRIPTS ** **You should be using seti@home version 3** INTRODUCTION 1. First off, the Seti Update Service(caddy) was created to allow me to post the current status of my seti workunits from several of my computers to my webpage. (http://www.rancidmeat.com/) It does this by using a client/server application suite. This was written in Java to allow me to run the app on any of my machines. I use a combination of Linux and Windows stations. Java made my task quite easy. Both the client and the server should run on any platform supporting the Java 1.1.x runtime environment. You have these components: Client, Server, PERL script(on web server), text file(on webserver) ,and webpage(html). 1. You run the server app on any machine that has TCP/IP access to your webserver. 2. You place the PERL script on your webserver and change the file permissions to "755". The PERL script writes out to the text file. 3. Place the text file on the webserver and give it a permission of "666". 4. You have to use some sort of scripting to read that text file in and display it on the webpage. (PHP3, SSI, ASP, Javascript, etc..) Look in the web directory for a php3 example. 5. Run the client on each machine that is running the seti process. If you have a client that has multiple sessions running, then you have to run a separate client app for each one (for the 1.1 version of the client) The client must be placed in the same directory as the state.sah file for seti@home is stored (for the 1.1 version of the client) *Each client MUST be configured with a different homename. (this is explained in the installation section) The server must be accessible to the client via TCP/IP. (the PORT and IP is configurable) INSTALLATION Linux vs. Windows client/servers. You will have to use the .class file for unix and Mac(etc..) client/servers. This document assumes that you know the basics of running java applications. a) Server The server has the ability to run seti and report on it's own seti status as well with out having to run a client on it as well. 1. There is one file you will need to modify in order to customize your server app. "startup.txt" There are many options in this file you will also need to modify. -name contains the hostname of the server. You can name it whatever you want. -port contains the TCP port number that you want the server to use. note: You should choose a number greater than 1024 as the security restrictions on most server-class operating systems(ie. UNIX) only allow non-root/admin processes to bind ports higher than 1024. The default port is 7051. -node add as many of these as you have seti processes running on the server machine. Note: the server does not have to have a seti process running. So, it does not require a "node" entry if seti@home is not running is this machine. usage: node=$DIR ex: node=c:\program Files\seti@home\ or node=/usr/local/seti/ -statusfile usage: statusfile=filename ex: statusfile=state.sah -userinfofile usage: userinfofile=filename ex: userinfofile=user_info.sah -updatedelay usage: updatedelay=miliseconds ex: updatedelay=300000 <- 5 minutes -reportunitscomplete is used to set whether you want the server to report the total number of units completed. *Use this only if all you're processes are using the same seti account(same email) usage: reportunitscomplete=0 for no or 1 for yes b) Client 1. There is one file you will need to modify in order to customize your client app. "startup.txt" There are many options in this file you will also need to modify. -name contains the hostname of the client. You can name it whatever you want. usage: ex:name=TestNode -ip the ip address of the server. usage: ex: ip=127.0.0.1 -port contains the TCP port number that the server is operating on. The default port is 7051. usage: ex: port=7051 -node add as many of these as you have seti processes running on the client machine. usage: node=$DIR ex: node=c:\program Files\seti@home\ or node=/usr/local/seti/ -statusfile usage: statusfile=filename ex: statusfile=state.sah -userinfofile usage: userinfofile=filename ex: userinfofile=user_info.sah Client command line options -nogui = will run not invoke the gui interface and will run completely on the command line. Usefull if your machine does not have a gui desktop. 1. There are currently 3 files you will need to modify in order to customize your client app. "name.txt", "IP.txt" , and "PORT.txt" These really need no explaination. Just make sure name.txt contains a unique name. This will be changing in the next version. You will only need to modify one file then, just like the server. ADDITIONAL NOTES * none for now CHANGE LOG 12/29/2002 -> fixed bug on the server which caused it's result count to always be zero. 2/17/2002 -> fixed gui bug in client. The gui version of the client failed to start when clicking "start". -> added "delay" keyword to client -> 2/09/2002 -> Client is now able to report on multiple sessions of seti@home -> Client and Server protocol was changed to allow for the above 9/21/2001 ->first release PLANNED FEATURES --Encryption keys for clients, right now the results are sent from the client over a TCP stream as plain text in a similar manner as a telnet session. This is very unsecure and easily hacked, allowing anyone with a telnet client to mess with the server app, sending invalid information. So to combat this, I may be setting it up to have the server send the client a random alphanumeric sequence, in which the client the runs through an algorithm which it then sends to the server with the seti update status of that work unit. The server then checks the validity of the result. If it matches what the servers result for that key, then the work unit result is reported, otherwise It would be ignored. One way around this is to open an ssh connection to the server and tunnel through that. --Logging to file. DISCLAIMER Of course the usual disclaimers still apply. I am not responsible for anything at all. Nothing. So there. If Java goes wild and hoses up your hard drive, take that up with SUN Microsystems. I have been using this application for months with no problems what so ever, and java for years.. LICENSING (GPL) This software package is released under the GNU General Public License (GPL) license, and MUST be treated as so. Goto http://www.gnu.org to read up on this license. Basically the main thing to remember is that if you modify and release a variation of thispackage, you MUST include the source code to your modifications. I also request that you give me credit for developing the base package. CONTACT INFO If you find this package useful, I'd love to hear from you. David Koenig dave@rancidmeat.com http://www.rancidmeat.com/