Content uploaded by S . Kumar
Author content
All content in this area was uploaded by S . Kumar on Jan 18, 2022
Content may be subject to copyright.
159
International Journal of Multidisciplinary Research and Development
Online ISSN: 2349-4182 Print ISSN: 2349-5979
www.allsubjectjournal.com
Volume 3; Issue 3; March 2016; Page No.159-161
; (Special Issue)
Design and Implementation of embedded web server through Tcp/Ip Protocol
M. Baskaran, J. Deenathayalan, S. Kumar , D. D. Saravanan
Research Scholar, Research & Development Centre, Bharathiar University, Coimbatore, Tamil Nadu, India.
Principal, Gandhi Arts & Science College, Sathyamangalam, Tamil Nadu, India.
Abstract
Embedded Web server development through Tcp/IP protocol projects main idea is to provide solution for embedded systems
interconnecting with internet using a TCP/IP protocol. Micro controllers are mostly used in controlling home appliances like
television, washing machines remotely. In order to improve flexibility for using micro controller applications there is need to
integrate web server to other intelligent devices which can be controlled from internet and provide solution for easy usage by
using web pages. Main advantages of implementing this application is it is light weight and cost efficient and users can use
features through web pages. It is easy to modify and upgrade web pages with new features.
Keywords: TCP/IP protocol, Web Server running under Linux, Outgoing from this ROM (Read-only-Memory, i.e. Flash
memory chips).
Introduction
After the “everybody-in-the-Internet-wave” now obviously
follows the “everything-in-the-Internet-wave”. The most
coffee, vending and washing machines are still not available
about the worldwide net. However the embedded Internet
integration for remote maintenance and diagnostic as well as
the so-called M2M communication is growing with a
considerable speed rate. Just the remote maintenance and
diagnostic of components and systems by Web browsers via
the Internet, or a local Intranet has a very high weight for
many development projects. In numerous development
departments people work on completely Web based
configurations and services for embedded systems.
The remaining days of the classic user interface made by a
small LC-display with front panel and a few function keys
are over. Through future evolutions in the field of the
mobile Internet, Bluetooth-based PANs (Personal Area
Network's) and the rapidly growing M2M communication
(M2M=Machine-to-Machine) a further innovating advance
is to be expected. The central function unit to get access on
an embedded system via Web browser is the Web server.
Such Web servers bring the desired HTML pages
(HTML=Hyper Text Markup Language) and pictures over
the worldwide Internet or a local network to the Web
browser. This happens HTTP-based (Hyper Text Transfer
Protocol). A TCP/IP protocol stack –that means it is based
on sophisticated and established standards– manages the
entire communication. Web server (HTTP server) and
browser (HTTP client) build TCP/IP applications. HTTP
achieved a phenomenal distribution in the last years.
Meanwhile millions of user around the world surf HTTP-
based in the World Wide Web. Today almost every personal
computer offers the necessary assistance for this protocol.
This status is valid more and more for embedded systems
also. The HTTP spreads up with a fast rate too.
Tcp/Ip-Based Http as communication platform
HTTP is a simple protocol that is based on a TCP/IP
protocol stack (picture 1.A). HTTP uses TCP (Transmission
Control Protocol). TCP is a relative complex and high-
quality protocol to transfer data by the subordinate IP
protocol. TCP itself always guarantees a Safeguarded
connection between two communication partners based on
an extensive three way-handshake procedure.
As a result the data transfer via HTTP is always protected.
Due to the extensive TCP protocol mechanisms HTTP
offers only a low-grade performance.
Fig 1: TCP/IP stack and HTTP programming model
HTTP is based on a simple client/server-concept. HTTP
server and client communicate via a TCP connection. As
default TCP port value the port number 80 will be used. The
server works completely passive. He waits for a request
(order) of a client. This request normally refers to the
transmition of specific HTML documents. This HTML
documents possibly have to be generated dynamically by
CGI. As result of the requests, the server will answer with a
response that usually contains the desired HTML documents
among others (picture 1.B).HTTP requests normally consist
of several text lines, which are transmitted to the server by
TCP. The listing 1.A shows an example. The first line
160
characterizes the request type (GET), the requested object
(/test1.htm) and the used HTTP version (HTTP/1.1). In the
second request line the client tells the server, which kind of
files it is able to evaluate. The third line includes
information about the client-software.
The fourth and last line of the request from listing 1.A is
used to inform the server about the IP address of the client.
In according to the type of request and the used client
software there could follow some further lines. As an end of
the request a blank line is expected.
Functional principle of a web server
Simplified a Web server can be imagined like a special kind
of a file server. Picture 2.A shows an overview. The Web
server receives a HTTP GET-request from the Web browser.
By this request, a specific file is required as answer (see step
1 into picture 2.A). After that, the Web server tries to get
access on the file system of the requested computer. Then it
attempts to find the desired file (step 2). After the successful
search the Web server read the entire file (step 3) and
transmit it as an answer (HTTP response comprising of
header and content object) to the Web browser (step 4). If
the Web server cannot find the appropriate file in the file
system, an error message (HTTP response which only
contains the header) is simply be send as response to the
client.
Fig 2: Functional principle from Web server and browser
The web content is build by individual files. The base is
build by static files with HTML pages. Within such HTML
files there are references to further files embedded –these
files are typically pictures in GIF or JPEG format. However,
also references to other objects, for example Java-Applets,
are possible. After a Web browser has received a HTML file
of a Web server, this file will be evaluated and then
searched for external references. Now the steps 1 to 4 from
picture 2.A will run again for every external reference in
order to request the respective file from the corresponding
Web server. Please note, that such a reference consists of the
name or IP address of a Web server (e.g. "dilnetpc.com"), as
well as the name of the desired file (e.g. "picture1.gif"). So
virtually every reference can refer to another Web server.
In other words, a HTML file could be located on the server
"ssv-embedded.de" but the required picture -which is
external, referenced by this HTML file- is located on the
Web server "dilnetpc.com". Finally this (worldwide)
networking of separate objects is the cause for the name
World Wide Web (WWW). All files, which are required by
a Web server, are requested from a browser like the
procedure shown on picture 2.A. normally these files are
stored in the file system of the server. The Webmaster has to
update these files from time to time. A further elementary
functionality of a Web server is the Common Gateway
Interface (CGI) -we have mentioned before. Originally this
technology is made only for simple forms, which are
embedded into HTML pages. The data, resulting from the
padding of a form, will be transmitted to a Web server via
HTTP-GET or POST-request (see step 1 into picture 2.B).
In such a GET- or POST-request the name of the CGI
program, which is needed for the evaluation of a form, is
fundamentally included. This program has to be on the Web
server. Normally the directory "/cgi-bin" is used as storage
location. As result of the GET- or POST-request the Web
server starts the CGI program located in the subdirectory
"/cgi-bin" and delivers the received data in form of
parameters (step 2). The outputs of a CGI program are
guided to the Web server (step 3). Then the Web server
sends them all as responses to the Web browser (step 4).
Dynamic Generated Html Pages
In contradiction to a company Web site server, which
informs people about the product program and services by
static pages and pictures, an embedded Web server has to
supply dynamically generated contents. The embedded Web
server will generate the dynamic pages in the moment of the
first access by a browser. How else could we check the
actual temperature of a system via Internet? Static HTML
files are not interesting for an embedded Web server. The
most information about the firmware version and service
instructions are stored in HTML format. All other tasks are
normally made via dynamic generated HTML.
Fig 3: Single steps of the Server-Side-Scripting
161
There are two different technologies to generate a specific
HTML page in the moment of the request: First the so-
called server-side-scripting and second the CGI
programming. At the server-side-scripting, script code is
embedded into a HTML page. If required, this code will be
carried out on the server (server-sided). For this, there are
numerous script languages available. All these languages are
usable inside a HTML-page. In the Linux community PHP
is used mostly. The favorite of Microsoft is VB Script. It is
also possible to insert Java directly into HTML pages. Sun
has named this technology JSP (Java Server Pages). The
HTML page with the script code is statically stored in the
file system of the Web server. Before this server file is
delivered to the client, a special program replaces the entire
script code with dynamic generated standard HTML. The
Web browser will not see anything from the script language.
Picture 3 shows the single steps of the server-side-scripting.
Web server running under linux
Once spoken about Web servers in connection with Linux
most people immediately think of Apache. After
investigations of the Netcraft Survey this program is the
mostly used Web server worldwide. Apache is an
enhancement of the legendary NCSA server. The name
Apache itself has nothing to do with Red Indians. It is a
construct from "A Patchy Server" because the first version
was put together from different code and patch files.
Moreover there are numerous other Web servers - even for
Linux. Most of this are standing under the GPL (like
Apache) and can be used license free. A very extensive
overview you can find at "http://directory.google.com/".
Every Web server has his advantages and disadvantages.
Some are developed for specific functions and have very
special qualities. Other distinguishes at best through their
reaction rate at many simultaneous requests, as well as the
variety of their configuration settings. Others are designed to
need minimal resources and offer very small setting
possibilities, as well as only one connection to a client.
The most important thing by an embedded Web server is the
actual resource requirements. Sometimes embedded systems
offer only minimal resources, which mostly has to be shared
with Linux. Meanwhile there are numerous high-
performance 32-bit-386/486-microcontroller or (Strong)
ARM-based embedded systems that own just 8 Mbytes
RAM and 2 Mbytes Flash- ROM .Outgoing from this ROM
(Read-only-Memory, i.e. Flash memory chips) a complete
Linux, based on a 2.2- or 2.4-Kernel with TCP/IP protocol
stack and Web server, will be booted. HTML pages and
programs are also stored in the ROM to generate the
dynamic Web pages. The space requirements of an
embedded system are similar to a little bigger stamp [3].
There it is quite understandable that there is no place for a
powerful Web server like Apache.
Reference
1. Burk, Bligh, Lee: TCP/IP Blueprints. SAMS Publishing
2000 page 269 ff.
2. Walter: MSR mit Linux. Franzis´ Verlag 2001 page 300
ff.
3. Embedded Web Server Moduls. Company information of
SSV Embedded Systems.