
This file collects various random notes about the microscope system.

Notes on the server's structure

* A master process controller (MPC) creates a bunch of FIFOs (one for each 
  process, plus its own) and the server's log file.

* MPC starts children.  When one dies, it writes/mails the traceback 
  as configured.  It also reads a FIFO of its own for commands.

* Child processes do whatever work they like, and also periodically
  check for commands on their input pipe.  Commands are single lines 
  in the format understood by parse_message_line().


Initial requirements for the microscope redesign

* Simpler code, hopefully producing a more reliable server.

* Actual test cases for things

* Use standard protocols to make it easier to build clients using
  existing libraries.

* Ability to adjust to the user's bandwidth

* Ability to support instruments with different capabilities

* Support wafer-level navigation, and overlaying of mask layouts

* Able to support higher frame rates on the client (likely not
  possible with Java, though)

* Actually implement access control



Architecture:

1) Continue the current arrangement of the client talking directly to
the microscope server in the fab.

2) Client talks to central server at MX, which is the only party who 
talks to the microscope server in the fab.

      Pro: 
      Authentication is simpler -- just use our session framework.
      The code on the microscope computer is simpler.
      Easier to do things like draw mask layouts and perform other 
annotations at the server.

      Con: 
      Images now get shipped through 2 round trips.
      If mems-exchange.org is inaccessible, even people in the fab
can't use the microscope.
     
3) Mixture of 1 and 2.  For example, microscope control is done
through a central MX server, but the images are sent directly from fab
to client.

      Con: All the complexity of implementing 1 and 2, too.


Protocols:

1) Continue using our current protocol.
2) Design some brand-new protocol.

3) Use some existing protocol -- HTTP is the most obvious candidate,
   but lacks a way to push information to the client, such as the
   'microscope moving' flag.  

  

Proposal:  

Cut through the threading problems by writing the server as several
processes.  

1) Camera process -- gets camera images and writes them atomically to
a file

2) Microscope hardware process -- gets commands for the hardware, and
sends them out.  Maintains a scoreboard of the microscope's current
status.  

3) Networking script -- handles incoming connections, and commands
from clients.  This process dominates processes #1 and 2.

4) Manager process -- checks the status of processes 1-3, and restarts
any of them that crash.  

What to use for IPC?  Pipes?  Shared memory?  Whatever it is, it
should be as simple and idiot-proof as possible.  

External protocol?  




   
