V2 Chapter 13

This chapter marks the start of the Remote SETI Client/Server development.  In it the first prototype is released and Dave Ames was the first to use it.  Then I went through a *long* process of trade off's to decide on the architecture to be used in the finished project and yet another rotor failure.

Additional Content

63. Continued Development of a  Remote SETI Station (2005-04-26 to present)

2005-04-16 Test Day - Well If you participated in the test you know the results.  The software worked for a few users and blew up on installation on a couple of others.  David Ocam reported that it installed and worked but Greg said it would not install.  That was the good news.

The bad news was that the antenna rotor is broken.  Its now stuck in the full down  position and I cannot raise it.  The azimuth motor seems to work but I can't run the elevation motor.  This means that I'll have to pull the whole thing down and open it up again.  It looks like the remote SETI project will be sidelined while I work on the rotor.  Damn.

The rotor doesn't look too bad.   I managed to get the thing down from the pole this morning and its on my work bench now.  So far I can't see any damage.  The problem appears that the elevation motor slipped from its mount and jammed the gears.  I think the whole thing started when my limit switch - didn't.  Since the software couldn't find the full  down position it kept driving the dish until if froze at its mechanical stop  point.  That caused the motor to jump its mount and really jam the thing up.

2005-04-15 (Tax Day - gasp) -  This day was spent working on moving the code from a bunch of loose ideas and half baked prototypes to something that is a little less fragile.  I now have a client with two gauges, one for Az the other for El and they do follow the current antenna settings.  Now I am working on allowing a client to request a specific Az or El angle from the remote end.  I hope to have a prototype of this running in the morning for a test.  Watch the SETI Net Chat room if you want to participating in this ground breaking test. 

RemoteServerObject.ASP

 2005-04-14 - http://66.27.116.71  This is getting annoying.  I have just spent three days going up and down the technology ladder trying to find a combination of programming abilities that I have,  tools that will do the job that I have or can buy, and the needs of the project. 

Problems | Solutions so far:

1. I need to Write the client myself rather than depend on web browsers.  I want control over the look and feel of the software on the user desktop and coercing Internet Explorer into doing what I want it to do is to much of a hassle.  Solution - Delphi Client.

2 The client needs to bust through firewalls, routers, crazy network supervisors at work etc.  The solution seems to be to use HTTP out of  the box.  That means the the client needs to have a web browser built into it.  Solution HTTP and a hand coded browser specifically for this purpose.

3. I need a HTTP server to field the clients as they check in.  I tried my own home brew server but it quickly became obvious that it couldn't cut it.  Solution was to install Internet Information Server (IIS).  I would rather have used Apache but it couldn't manage Active Server Pages (ASP) so it was out.  IIS does the trick and it will also allow me (someday) to stream the audio to the clients.

4. ASP allows me to build an Active Server Page Object that ties into the server and wakes up every time a client sends a message.   The major problem with that is that the ASP Object runs in a thread of the IIS server application.  Each new client out there that sends a message starts a new thread each with its own ASP Object.    How do I move that request for data to the Remote SETI Server?  Solution - A socket system.  Another new technology to understand but it will also allow the IIS /ASP Object combination to be on a different machine than the Remote Server.  This will be helpful during debugging .

5. Since the ASP Object is in its own thread for each client request it must be instantiated, send the command downstream to the SETI Server wait for the return data, send that back upstream and then destroy its self.  Solution is Indy sockets and a lot of screwing around to make them work.

6. Once the command reaches the Remote SETI Server and is validated the server must go out and pick up the data for the client (the Antenna Az/El, the receiver settings etc.).  The problem is that the Antenna, Radio, SML Generator, Repository etc are all separate applications running on the machine and Windows goes to great pains so that applications can't disturbed each other.  Sill I have to move data between the Remote SETI Server and those other application.  The solution seems to be an obscure way that you can pass data between applications using the windows messaging system.  I  will be working on that tomorrow.

So it seems like it can be done and needs a lot of bit pushing and scrambling around for answers.  I can do that stuff.  Stay tuned.

2005-04-12 - Building the actual [ RemoteServerObject.ASP?Argus_ID=DM12jb ] you can hit this to test at any time (I have no idea what might happen when you do).

This is what I know so far:

  • I know how to invoke GET and POST methods in an ASP Object
  • I know how to create and then kill a socket client in each thread
  • I  know how to pass requests down to a Remote-SETI server and back to the http client.

The next step is to decide what to pass...

Back Office Business Rules (thinking out loud) :

  1. Remote Client sends GET with Argus station ID, password and client version number.
  2. If the SETI Net Remote computer (Zeke) is off line the Remote Client will receive "page not availed" error message.  This will cause a message to appear on the client.
  3. IIS fields the GET and passes it to the ASP Object.  Object passes it down through the socket set and to the Remote-SETI Server.  If the server is unreachable the ASP Object will send a message back to the client saying so.
  4. When the Remote-SETI Sever receives the GET it validates the Argus ID and password and then checks to see if any other client is controlling the system.  This will be done by looking for a lock file.
  5. If the system is not locked by another client the new Remote Client is offered access to the antenna position and the receiver tuning.  This is done by sending a cookie to that client. The Remote Server also returns the current antenna and receiver parameters.
  6. If the system is being controlled by another Remote Client the system returns the current antenna  and receiver parameters only.
  7. The Remote Client then brings up  the Sky Map  and the Az/El gauges based on the antenna parameters.  It then sets up the remote receiver user interface, based on the receiver parameters.    The client operator now sees the current setup on his client user interface.
  8. If the Remote Client operator wants full control he will push a button on the client which will cause the cookie to be sent back to the Remote Server.  This cookie will time out after say Ten minutes.
  9. The Remote Server will attempt to refresh the cookie every 5 minutes by sending a command to the Remote Client.  If the client is still on line it will reflect the cookie back to the server.  This will allow the system to continue if a cookie client goes off line.
  10. The Remote Clients will all contain a refresh timer (1 second) that will send a GET command for new Antenna and Receiver parameters.  This will be use to update the Remote Client user interface.
  11. If the operator of the cookie holding Remote Client wishes to change any Antenna or Receiver parameter he will do so in the user interface (pull one of the Az/El gauge needles or change the receiver frequency etc.) and that will be sent along with the cookie to the Remote Server.  The server will validate the received cookie with the locked cookie and if they match it will change the station setup accordingly.

This will be the minimum operation of the Remote SETI Server.  The next generation will:

  • Allow the Remote Client (with the cookie) to track a position in the sky
  • Cause the Remote Server to move the collected WAV file to SETI.Net for archival storage
  • Stream MP3 data to all the clients

2005-04-10 (Sunday) - I still hard at work attempting to connect a client (runs on your machine) to a server (runs on the Remote-SETI Server) so that you can control my antenna.  Its complex. 

Say [ Hello.ASP ] To Zeke  or Remote-SETI which ever is fielding HTTP at the time.

Try [  GetObject.ASP  To send the GET with 'first_ name' parameters to the Remote-Server.

Should return 'James'.

This is a test of the ability to pick up POST data from the web page.  Enter first and last.  It should welcome you - nothing more.

First name: 
Last name: 

 TryTo Zeke  or Remote-SETI which ever is fielding HTTP at the time.

I am using the Internet Information Server (IIS) from Microsoft.  One of the biggest problems when testing with IIS is that once IIS loads a DLL, it never releases it. Therefore, the only way to test your changes is to restart IIS so that it will use the new version of your code.

There are 3 basic ways to shutdown and restart IIS

  • Reboot the computer - a bit drastic, and very slow, but when you don't know any other way, it works.
  • Run a program from the command line iisreset.exe - this works the best on IIS version 4 but still takes 15 seconds per restart.
  • Kill dllhost.exe
  • Reset and restart from Delphi

The Best Way
in the command line put "Run IISRESET/Stop" - Do this before you recompile your object
In Delphi's Run | run put:   "C:\WINNT\system32\IISRESET.EXE"  in the host application and in the parameters put "/START"
This method stops IIS and then when your ready to test IIS will restart.

Its not the concept that's complex - its the execution.  Getting all the bits and pieces to play nicely with each other is a problem.

2005-04-08 I have extended SETI Net by one more machine. 

I purchased a Gigabyte GA-K8NXP-SLI-8Σ series motherboard that uses an AMD Socket 939 Athlon 64 bit processor.  This machine runs in excess of  3,000 Hz and has 2 Gig of dual access main memory.  I also added a 200 G hard drive.  This machine, renamed Zeke, will be my primary development machine and runs Windows 2000 workstation.  I have installed Delphi 6 and 8 (Delphi Net) along with Visual Basic Net and Borland's C# for development tools.

The second machine is Delphi a laptop that is used by my wife.  This is the one we take with us in the  motor home to the mountains for R&R and remote programming.  We access the internet with this machine using a Verizon cell phone.  We usually expect to see about 200 kb access rate with the Verizon high speed network and it seems to be everywhere we travel.

The third machine is the original Zeke, now renamed Remote-SETI, has 1 1/2 gig of on line memory and 40 G of storage and runs Windows Server.  This machine will become the remote SETI server.  When you hit the 'root' link below your connecting it.

Now that I have all three up and running and interconnected its time to get back to the Remote-SETI client/server development.

2005-03-29 Testing the ASP page now (hit it if you like but no guarantee):

2005-03-28 The decision on which server to use seems to have been solved.  Here were the server choices:

Home Grown - The one that I ran the test on, I wrote it, and of course it doesn't have any of the security features needed.  It also isn't

Apache - I was able to build Apache DSO modules that started when a remote client logged in but I could never find a way to start an OLE server (like my antenna server or the receiver) from the DSO.  I have learned that Active Server Pages (ASP) can start an OLE server and that Apache supports ASP with a third party add-on.  Unfortunately that add on only works under Unix and I only work with Windows so that solution is out.

Internet Information Server (IIS) - I installed IIS on my home machine and then tried build an ASP script that is called when a client connects.  This seems to work.  From the script I can start an OLE server and pass the data back to the client.  There is still a lot of work but IIS seems to be the way to go because of its ability with ASP pages.

2005-03-27 With the successful test of the first prototype client/server I can move to the next step - development of a full scale client and server.  Several questions must be answered.

  1. Should I attempt to use an Apache server at SETI Net?  I have one in operation now but it is complex to manage and I am not sure if I can build the required 'hooks' into it.
  2. Should I use IIS from Microsoft?  I have one as well but it only allows 10 users when running on Win2000 rather than Win2000 server.  This is a mixed blessing.
  3. Should I move to SOAP?  I like the idea of XML moving through the client but I'm not sure if I can  build a SOAP server.   IF SOAP then I need to start the development of the schema.  I am familiar with XML (the SML Generator is an XML application) and might do it for no other reason.
  4. If not SOAP - what protocol?
  5. Should I use OCX's in the clients?  They cause reconfiguration problems every time the clients have to be updated but the do look nice (the Antenna gauges are OCX's).
  6. I would like to be able to 'stream' MP3 from the receiver to the client if they wish.  I know the compression would kill the low level signals that we are attempting to find but I would also move the collected WAV data to the server data repository.  This way the client can 'listen' using MP3 and 'analyze' using the WAV.  Question is how can I stream MP3 with Apache? 

62. Creation of a Prototype Remote SETI Station (2005-03-18 to 2005-03-26)

2005-03-26 First is a test of a *very* simple remote client.  If it works it will connect to the server on my home machine and bring back the header information from the server.  It also has a gauge on it that should show the current Az on the SETI Net antenna.

Test Results:

  • Dave Ames downloaded the client and was able to watch the movement of the antenna from London.  First remote SETI operation.
  • A young French boy (13 years old) wandered into the chat room but was unable to download the client.  I think it was a language problem (French/English).
  • Greg (last name unknown) attempted to start the client but it threw off some exceptions.  Some kind of floating point to string conversion problem.
  • John Marcus started the client and it worked fine (although I wasn't moving the antenna at the time).
  • Several other clients were started but I have no idea who they were. 

2005-03-25 Now that I can build a Sky Map into the remote client the development of the client can begin in earnest.

2005-03-24 Since I wish to build the Sky Map into the remote client I had to find a way to isolate it from the clock.  I didn't want to have to distribute a clock with every remote client because it would have no other purpose than to form an interface between the remote client and the Sky Map.  I managed to isolate the map by changing the design to a more abstract interface using the Public interface of the units.  This also lead to a more object oriented organization.

2005-03-22 I got a HTTP client and server running and was able to make a few tests on it with other Argus stations so I will go ahead with that design.

2005-03-20 Well the socket thing didn't work out to well.  I was able to get a socket server and client running on my local network but during the test it bombed out trying to get through everyone's firewalls and routers.  So now I'm back to attempting an HTTP server and client.

  This should wake up my home grown HTTP server on my home machine...

As they stay... Stay tuned.

2005-03-19 If I can figure out how to code the transmission of data to and from a remote client I should be able to turn my station into a Remote SETI Station.

(thinking out loud) What I would like to do with RSETI is the following:

  1. Build a client that can be distributed and that contains a simple dialog box to select the receive frequency, the DEC/RA of the antenna and the integration time requested.
  2. The client would send its Argus station ID to the server for verification
  3. The server would check if RSETI is busy and respond if it is.  If not it would send the current current AZ/El (or DEC/RA) of the antenna and would update it as the antenna moves to the requested star position.
  4. The system would monitor that position for the requested time or until the star moved out of range of the SETI Net antenna.
  5. At the end of the collection period the server would cause the WAV file to be uploaded to the data arcive

After foundering around for several days investigating socket programming, web snap components, Active Server pages, Apache DSO, web brokers, web servers and SOAP <gasp>  I'm back where I started - Sockets.  It seems the simplest way to connect computer to computer and I'll give it a try.

 Stay tuned...