Thank you for using Ethernet Starter Kit. This Demo Application is a little example of an embedded webserver. The Tiger functions as a server and the client is any person using a Browser like the Internet Explorer, Netscape Navigator or Opera. The Tiger implements HTTP protcoll and CGI, so that you can interact with your Starter Kit immediatly.
By pressing the Update-Button at the left side of the webpage you will download the current settings of your Ethernet Board. Try turning the Encoder or pressing some Buttons at your Board, then click the Update Button and watch the results at your Board and your browser.
It is also possible to change the settings through your Browser. Click a Button in the middle of the window and take a look at the LED on your Starter Kit. The buttons have the same effects as the one on your Starter Kit. It is also possible to start more than one Browser and communicate to Ethernetmodule, so try it. To Refresh the information permanently would be too slow for the user and the number of clients at the same time would be limited, so we have chosen the update method. For most applications this function should be sufficient enough.
The "reset Encoder" button resets the countervalue of the Encoder to 0. By turning the Encoder to the right, the value will increase, othewise it will decrease. The "reset Keys" buttton resets all Keys to initial position.
Here you get a short overview about the implementation of the server. The server is implemented in Tiger Basic®.
First Step is to get a connection to the network, then the Tiger listens and waits for other incoming connections. A HTTP-Server always listens to port 80. If there is an incoming connection, we open a new socket to communicate with the client. The other socket continues listen to port 80, so more than one connection can be hold at same time.
The programm is seperated in several files. "HTTP_Protokoll_V[vers].inc" contains all functions implementing the http protocoll. There are methods to read out HTTP requests, search for saved documents in flash memory and to send an answer back to the client. There is also a file named "cgi_V[vers].inc" which includes the subs working with cgi-programms. That means, that a programm/function is started on the server by the client.
We realized a multisocket programm, so that the server can interact with more than one client at the same time.This feature is implemented in more functions. If there is an incoming connection, this connection gets a unique socket and buffer numbe . So we can discern all connections and data. In the task "onData" we read out buffer and socket number. So it's easy to differ all incoming data and to serve all clients with correct data.
The incoming data will be checked for valid HTTP request. A HTTP request always begins with "GET", "HEAD" or "POST", in our case we'll only need the "GET" request, because it is the most common used request. If you want more information about the HTTP protocoll itself, please look up here:
http://www.w3.org/Protocols/rfc2616/rfc2616.html
http://wwwstud.rz.uni-leipzig.de/~mai00cjs/studium/http/http.html(German)
We compare the beginning of the request with the valid commands and if they equals it is a HTTP request, so we have to wait for the first empty line. The empty line is the end of the header of a HTTP request. In the header mostly is enough information to send the right answer. Most important is the request line. In the sub "request_line" we'll analyze all given information from this important line. The key to the right document is the URL, which is saved in the request line. One part of the URL is the (relative/absolute) path of the document on the server. Information about URL/URI is shown here:
http://www.w3c.org/Addressing/
We saved all required files in "datafiles_V[vers].inc". You must save all names of the files in flash memory in the string files$ to identificate them, in the same order as they are saved in the flash memory of the Tiger. So it is possible to get the starting Adress and the length of the file we need.
There is also the possibility to create some more directories on the server. In our case we have a second directory, where all CGI Files are saved. We search in valid URL for first "/", so we can read out the current directory. We select the directory with a switch...case instruction. If there is no "/", we search for standard documents in the root folder. We compare the name of the URL with the names of our saved files, and if there is a congruence, we read out the file and save all information about that file as possible. This is very important for the HTTP response. We have to know what kind of document this is, eg. a HTML file or a picture as gif. The kind of document is named content type and must be mentioned in the HTTP protocoll. So the browser is aware of how to interprete the received document. It's also very important to specify the length of the document to the header of the response.
If the document was found, we send it to the client with the most recent information. The answer consists of the statuscode, which is part of the header, and the entity.Mostly the statuscode is HTTP_OK, what is the number "200". Also often used is "404 Not Found", "400 Bad Request" or "204 No Content"
In our case we have to generate a part of the HTML site dynamicly on the server, because there are many possibilities of how the website could look. The Encodervalue can change and the LED status, too. So, we generate the HTML site within the right information. We write e.g. the parameters for the LED, which are realized in a java applet. With this method we save much memory. The basics of the HTML site is saved in Flash memory and it is read out and saved in RAM temporary. Then we search for unique elements in the HTML Site and append or insert code to the script. E.g. we search for the declaration of the variable encVal, which symbolizes the value of the encoder, so we search for "var encVal;". We get the position of this and after this statement we insert the real value of the Encoder, so the user can see the correct results. We manipulate the LED status the same way. The status of the LED is given by 5 parameters, who are read out from the java aplet while initializing.
The generation of the HTML-Site could already be part of a CGI programm . CGI means, that a programm on the server is started by the client. On the Tiger these are no real programms, but functions/subs who are started. We have to check, wether a function was called by checking the names of the functions and compare them to the URL given of the request. This was made with a switch...case instruction, which is realized in the function startCGI in "cgi_V[vers].inc" To get detailled information about cgi and working with cgi, please read following links:
http://www.ku.edu/~acs/docs/other/forms-intro.shtml
http://www.htmlhelp.com/faq/cgifaq.html
http://hoohoo.ncsa.uiuc.edu/cgi/interface.html
http://snowwhite.it.brighton.ac.uk/~mas/mas/courses/html/html3.html#CGI-call
We need cgi programms eg. to toggle the LED's. If you clicked on a buttons, we send a cgi-command to the Tiger. This cgi-command is just a link in HTML, eg. "cgi-bin\MyCgiSub". Mostly, no real response is needed, only the sub has to be started. In this case the response has the statuscode "204" and no entity. The entity is the second part of the response. The first part, the header, consists of the information of the document, and the second part, the entity, is the document itself.
The structure of this HTML site is not that fastidiously, so that you can understand quickly. For detailled information about HTML, please look up:
http://www.w3.org/MarkUp/Guide/
http://www.w3.org/MarkUp/
Every HTML-Site has one index-site. Our index site only consists out of 3 Frames. One Frame for the left site with the menubuttons, one Frame for the Top, consisting only of one picture and the main part of the site, the lower right part. The buttons are pictures within a link. If one buttons is pressed, we open the associated link with one parameter. This is an example of a cgi-programm. We start a sub in the Tiger to toggle the state of a LED, then we get an answer, that nothing new has to be shown on LCD.
The green LED's at the right of the browser are realized with a java applet. The applet gets five parameters, which symbolizes the status of the buttons and the LED's. The startvalue is constant in HTML, but the site is dynamicly generated, so they can change. While initializing the applet, it reads out the variables from the HTML site and adapt the color of the LED. The Java-applet has a public function "setLightState( LED, state)", where you are able to change the status of the LED's. The function needs 2 parameters. The first parameter is the index of the LED. The LED's are numbered from top to bottom and from left to right.
0
1 2 3
4
The second parameter is the state of the LED. If you want to turn off the LED, the parameter has to be "0". Set it to 1 to switch on the LED. This function can be called from a function in javscript. If a button was clicked, the link is activated and a function in javascript is called, which calls a function in java-applet. This one then will changes the color of the LED. Sure, it is not necessary to use a java-applet for this task, but it shows, how easy it is to implement an applet. Applets can make very complex work, but javascript is limited. Don't forget, that an applet need the rights to work on foreign computers, so an applet isrestricted, too. It is impossible to write and delete files at the local PC or open another port to communicate differing from port 80.