-
Notifications
You must be signed in to change notification settings - Fork 0
Admin Program Structure
The Admin program is the hub and glue of the operation. It starts out simply by receiving a new connection, making a new thread to handle it, reading the header, branching out the work. The connections that come in are supposed to be any device on the network requesting the webpage or sending commands.
The webserver is one of the jobs of the admin program. It provides useful user interactions such as camera control and information. The admin program filters out web browsers looking for the html pages by looking at the HTTP header. It knows it is an HTTP header because it will use GET to request a page. This keyword at the beginning of the stream is used to differentiate it from a PI and is passed to the webserver services.
The webserver services receives the header that was first read before the decision to be passed here. The header is looked at to see what path the client is requesting. It is looked up in a list of hard codded options to see if there is anything special that should be done, such as send a command. If there is no special hard codded thing to do, then the path is prepended with 'www' and the file loaded from the www directory is sent back.
There is a special case when dealing with this logic chain, when a file is not found. The file is attempted to be loaded, but not able to be so, and as such we try to load a different file; 'www/404.html'. This is supposed to be the 404 page to handle such cases, and it is encouraged to have a link back to the home page.
This is the directory that files are read to be sent to the user. This directory must be within the working directory that the server is running from. Any file just about can be put here, within any folder, and the server will serve them like a normal web server. There is limited functionality, such as no POST so no forms and such. There are some reserved file names that are hard-codded into the program.
- reads files from here IF and ONLY IF there is no hard-coded path
- each file is to be read and then modified in-stream
- there are specific symbols that will get replaced like how PHP does it - see the wiki page for a list
- contains other directories that are the photo sets
- this is not ever directly seen on the web-browser side, but the /images url will redirect to /images.html
- the images.html page should have the special tag to load the list of available image sets
- each image set has a page for it at /images/XXXXX where XXXXX is the 0-padded number (eg 00004)
- each image set's page should show all the images and have a download button where it will give back an archive of all the images
- the image set's archive download url is /images/XXXXX/zip
This is a mainly internal set of information that you probably don't really need to worry about as a user. This handles all connection types the PIs have with the admin, sending and receiving. This also defines the global list of known PI connections. This list is maintained by this module but used in the web server side.
This is the normal flow that the control system deals with. Typically in terms of the images being sent back. The following are the ways that a receiving connection can go.
- Image being sent back
- reporting in
The web server section, for given urls, will use functions from here that send to the PIs. The following are ways that sending connections are used.
- Command to take a picture
- turning on/off noise projections
- reboot command
- Video Reset
- Updating
Each raspberry Pi contacts the Admin server to tell it that it exists. This lets the user see a list of connected devices to do such things as view video streams. This connection is done by waiting for the Admin to send out a broadcast UDP packet and then replies to the sending address. This way the admin can be anywhere on the network and it still work properly, allowing greater flexibility in setup.