3. Web Server

It often can be quite useful to be able to find out about the current state of an experiment without having to sit around in the lab all the time or constantly coming back just to check that everything is still working fine. Instead fsc2 lets you start a built-in web server that allows you to monitor the current state of the experiment via a browser via the internet. The web server gets switched on by clicking on the WWW server button. The button remains green (instead of being grey) while the web server is running.

Normally web servers listen for incoming requests from the outside world on the port numbered 80. Thus you usually don't have to tell your browser to which port of the server to connect to, it will use port 80 by default. This is a bit different with fsc2. Because it's not run with the privileges required for use of port 80 (ports in the range between 0 and 1023 can only be used by programs running with the rights of the root user). Instead per default it uses the alternate HTTP port, which has the number 8080. Thus you have to tell your browser explicitely to connect to this port instead of the default port 80. This is done by specifying the port number in the URL. To do so youjust have to add a colon and the port number to the machine name like this:

http://name.of.computer:8080

where name.of.computer is the internet name of the computer the experiment is running on (don't prepend a www.). You also may tell fsc2 to use a different port instead of 8080 through the -httpPort command line option.

When fsc2's web server is running your browser will display a page telling you fsc2's current state, i.e. whether it is idle, running an experiment, waiting for user input (when e.g. a file selector is shown) or has finished the experiment. Furthermore, it displays a copy of the display window(s) and, if fsc2 is showing it, of the cross section window. They are shown in exactly the same way as they are displayed on the screen. Finally, it shows the last 30 lines of the browser for error messages and other output from the running EDL program.

Currently, graphics will only be sent in either PNG or JPEG format, thus your browser must support one of these formats (most do). While there is no technical problem not to support also graphics in GIF format some legal issues which keep me from doing so (as far as I know the LWZ compression method used with the GIF format is patented by Unisys and I am not going to buy a license). Perhaps this will change after the patent expired.

Please note that serving web pages is a rather low priority task. When fsc2 is very busy acquiring and displaying data the reaction time to a request for a new page might be long.

Under certain conditions you may get a "Not available" message instead of a graphic with the current state. This happens when you just reload a graphic (but not the complete page) and someone else, sitting directly at the computer where the experiment is running, has closed the corresponding window.

Interacting directly with requests from the internet always raises some concerns about security. First of all, the web server built into fsc2 is that simple (and is running with the privileges of the user only) that I am quite convinced that there are no bugs that could be exploited to gain access to data an outsider shouldn't be able to obtain. And because the server is written in Perl (and running in tainted mode) also e.g. buffer overflows shouldn't be an issue. All you have to worry about is that in principle everybody in the world can have a look at your measurement while the web server is up and running. If you are deeply concerned about this you can also build fsc2 without support for the web server.

The only other conceivable problem would be that someone really malicious would constantly send requests to the server which, in turn, must bother fsc2 to tell it about its current status and to create graphics with the window contents. In cases when fsc2 is already having problems acquiring and displaying measured data fast enough this could further increase its workload and, in extreme cases, might slow down the experiment a bit. If you have reasons to suspect something like this to happen simply switching off the web server (or not switching it on in the first place) is probably the best solution.

Please note: If multiple instances of fsc2 are running only one of them can run the web server on the default port 8080. So if you want more than one of the instances to run a web server you must assign a different port the web server is going to listen on to the different instances, using the -httpPort option.

This document was generated by Jens Thoms Toerring on September 6, 2017 using texi2html 1.82.