Embedded Web Server ... Question about most common pactices...

Hi i need to implement an embedded webserver and i was wondering, what is
the most common practice on this field. To develop your own TCP/IP stack or
use a generic and open one as uIP? Any one knows if uIP is reliable? We
don't have a defined hardware, so i need to create it as portable as
possible but probably will be a 32 bits uCU as ARM. Just to explain the
application, is to create a basic interface to our product for initial
configuration purposes.

Thank you	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On Oct 4, 10:24=A0am, "Sink0" <sink00@n_o_s_p_a_m.gmail.com> wrote:
> Hi i need to implement an embedded webserver and i was wondering, what is
> the most common practice on this field. To develop your own TCP/IP stack =
or
> use a generic and open one as uIP? Any one knows if uIP is reliable? We

The most common practice is to see if your operating system already
provides such a stack. What operating system do you intend to run? If
you want to make your code "portable" and you cannot yet make a
decision as to which OS will be used, write your code with BSD socket
calls and it should be buildable(ish) on most platforms.

Most people in this day and age would not write their own IP stack,
nor would they write their own web server.

>On Oct 4, 10:24=A0am, "Sink0" <sink00@n_o_s_p_a_m.gmail.com> wrote:
>> Hi i need to implement an embedded webserver and i was wondering, what
is
>> the most common practice on this field. To develop your own TCP/IP stack
=
>or
>> use a generic and open one as uIP? Any one knows if uIP is reliable? We
>
>The most common practice is to see if your operating system already
>provides such a stack. What operating system do you intend to run? If
>you want to make your code "portable" and you cannot yet make a
>decision as to which OS will be used, write your code with BSD socket
>calls and it should be buildable(ish) on most platforms.
>
>Most people in this day and age would not write their own IP stack,
>nor would they write their own web server.
>

Probably with no OS, just from bios. But there may be a chance to run from
an OS as some kind of embedded linux. But i will assume for now that i will
run from bios. 

What do you mean that they would not write their own web server? How would
they have a customized web server without wiriting it?	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On Oct 4, 10:02=A0am, "Sink0" <sink00@n_o_s_p_a_m.gmail.com> wrote:
> >On Oct 4, 10:24=3DA0am, "Sink0" <sink00@n_o_s_p_a_m.gmail.com> wrote:
> >> Hi i need to implement an embedded webserver and i was wondering, what
> is
> >> the most common practice on this field. To develop your own TCP/IP sta=
ck
> =3D
> >or
> >> use a generic and open one as uIP? Any one knows if uIP is reliable? W=
e
>
> >The most common practice is to see if your operating system already
> >provides such a stack. What operating system do you intend to run? If
> >you want to make your code "portable" and you cannot yet make a
> >decision as to which OS will be used, write your code with BSD socket
> >calls and it should be buildable(ish) on most platforms.
>
> >Most people in this day and age would not write their own IP stack,
> >nor would they write their own web server.
>
> Probably with no OS, just from bios. But there may be a chance to run fro=
m
> an OS as some kind of embedded linux. But i will assume for now that i wi=
ll
> run from bios.
>
> What do you mean that they would not write their own web server? How woul=
d
> they have a customized web server without wiriting it? =A0 =A0


Just as there are many embedded (and other) OS's, free and otherwise,
and many of those include (sometimes optionally) IIP stacks (and IP
stacks are available separately as well), so it goes with web
servers:  Many OS's have one or more web servers available already,
and many reasonably portable web servers are out there - heck you can
port Apache to your new platform if you like (although that=92s not at
all trivial., but you end up with one heck of a lot of function).

Or are you confusing the web server with the web *site(s)* that it
hosts?  The latter you would usually write, the former, only rarely
(as usually, doing it well is a lot of work, and most of us don't get
paid for pointlessly reinventing the wheel).  Although a basic web
server with very limited functionality is not that hard to write, and
may be an option if you need something very lightweight.

>Just as there are many embedded (and other) OS's, free and otherwise,
>and many of those include (sometimes optionally) IIP stacks (and IP
>stacks are available separately as well), so it goes with web
>servers:  Many OS's have one or more web servers available already,
>and many reasonably portable web servers are out there - heck you can
>port Apache to your new platform if you like (although that=92s not at
>all trivial., but you end up with one heck of a lot of function).
>
>Or are you confusing the web server with the web *site(s)* that it
>hosts?  The latter you would usually write, the former, only rarely
>(as usually, doing it well is a lot of work, and most of us don't get
>paid for pointlessly reinventing the wheel).  Although a basic web
>server with very limited functionality is not that hard to write, and
>may be an option if you need something very lightweight.
>

Yea that makes sense... just question. Any idea if uIP and lwIP are good
and reliable stacks? Do you have any sugestion of a open webserver for
running from bios?


Second question and totaly OFFtopic, do you post from embedded related or
from another website? I cant see the same signature on your post....

Thank you	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On Oct 4, 10:40=A0am, "Sink0" <sink00@n_o_s_p_a_m.gmail.com> wrote:
> >Just as there are many embedded (and other) OS's, free and otherwise,
> >and many of those include (sometimes optionally) IIP stacks (and IP
> >stacks are available separately as well), so it goes with web
> >servers: =A0Many OS's have one or more web servers available already,
> >and many reasonably portable web servers are out there - heck you can
> >port Apache to your new platform if you like (although that=3D92s not at
> >all trivial., but you end up with one heck of a lot of function).
>
> >Or are you confusing the web server with the web *site(s)* that it
> >hosts? =A0The latter you would usually write, the former, only rarely
> >(as usually, doing it well is a lot of work, and most of us don't get
> >paid for pointlessly reinventing the wheel). =A0Although a basic web
> >server with very limited functionality is not that hard to write, and
> >may be an option if you need something very lightweight.
>
> Yea that makes sense... just question. Any idea if uIP and lwIP are good
> and reliable stacks? Do you have any sugestion of a open webserver for
> running from bios?


No idea - I've never used either.  OTOH, they appear to have a number
of successful ports, which is usually a good sign.  And they're open
source, which means that you can fix any problems you encounter - and
that will almost always be less work than developing the entire stack
from scratch, assuming you don't have some special requirements.  And
being OSS, just given one of them a try - at the very least you'll get
into the innards of a working stack, which will be invaluable
experience if you do decide to roll your own.


> Second question and totaly OFFtopic, do you post from embedded related or
> from another website? I cant see the same signature on your post....


This is a Usenet group, and is not related to any web site.  For
reasons mostly involving laziness, I used Google Groups to post this
(and yes, that=92s at least a bit embarrassing).  A proper newsreader
would be better, but it's not one of my life's priorities.

Sink0 wrote:
> Hi i need to implement an embedded webserver and i was wondering, what is
> the most common practice on this field. To develop your own TCP/IP stack or
> use a generic and open one as uIP? Any one knows if uIP is reliable? We
> don't have a defined hardware, so i need to create it as portable as
> possible but probably will be a 32 bits uCU as ARM. Just to explain the
> application, is to create a basic interface to our product for initial
> configuration purposes.

The answer to these questions depends on the resources you
have available (both at development time and run time).

Also, the possible interaction of the "configuration service"
with the rest of your application should be considered.  I.e.,
does the application continue to provide *its* full complement
of services to the user while configuration is taking place?
Or, does configuration preempt normal operation?  Are changes
made during configuration immediately visible to the application
or are all changes deferred until "configuration complete"?
(note this often has significant ramifications regarding valid
combinations of configuration options).

Is the configuration information "sensitive"?  How do you handle
multiple requests to configure the device concurrently?  Are
there any other features that the served pages need to have
supported?  Are there any other run-time uses of the web server
that are essential to -- or could be beneficial to -- your product?
(or, is it *solely* used for configuration)  How vulnerable is
your product to hacking (i.e., honeypot)? etc.

Each of these issues reflects the degree of sophistication in
your network stack and web server.  The more "general" you want your
solution to be, the more capable your implementation must be.  If
you can constrain your needs, you can increase the option available
to you.  (e.g., I recall QNX had an OS+web server on a 1.4M floppy;
I have seen other implementations considerably smaller than that!)

You might also consider the means by which the user will be
interacting with your "configuration program".  E.g., if
he/she will typically be using a "PC" to perform this function,
how viable is it to move the configuration "tool" into the
PC (even if it is in the form of a text file that the user
edits *on* the PC) and then ship the resulting "snapshot" over
to your product (where it is parsed and accepted/rejected in toto)

>The answer to these questions depends on the resources you
>have available (both at development time and run time).
>
>Also, the possible interaction of the "configuration service"
>with the rest of your application should be considered.  I.e.,
>does the application continue to provide *its* full complement
>of services to the user while configuration is taking place?
>Or, does configuration preempt normal operation?  Are changes
>made during configuration immediately visible to the application
>or are all changes deferred until "configuration complete"?
>(note this often has significant ramifications regarding valid
>combinations of configuration options).
>
>Is the configuration information "sensitive"?  How do you handle
>multiple requests to configure the device concurrently?  Are
>there any other features that the served pages need to have
>supported?  Are there any other run-time uses of the web server
>that are essential to -- or could be beneficial to -- your product?
>(or, is it *solely* used for configuration)  How vulnerable is
>your product to hacking (i.e., honeypot)? etc.
>
>Each of these issues reflects the degree of sophistication in
>your network stack and web server.  The more "general" you want your
>solution to be, the more capable your implementation must be.  If
>you can constrain your needs, you can increase the option available
>to you.  (e.g., I recall QNX had an OS+web server on a 1.4M floppy;
>I have seen other implementations considerably smaller than that!)
>
>You might also consider the means by which the user will be
>interacting with your "configuration program".  E.g., if
>he/she will typically be using a "PC" to perform this function,
>how viable is it to move the configuration "tool" into the
>PC (even if it is in the form of a text file that the user
>edits *on* the PC) and then ship the resulting "snapshot" over
>to your product (where it is parsed and accepted/rejected in toto)
>


The product is just aimed to be used on a local network so protection is
not a problem so far.. Other than the configuration, the server is aimed to
be used to monitor some sensors and control of the products output. The
product itself must be real-time when controlled by the automation process
but not when when controlled or monitored using web-server. Basically will
be an easy access to the system for configuration, debugging and to send
simple commands but it is not aimed to be used as its main interfaces.
Basically a window that display some values and you can control the system
on-line but the timing is not very strict as long it does respond on a
minimum time, lets say 200ms so that the human eye consider instantaneous.

	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com

On Mon, 04 Oct 2010 11:38:31 -0500, Sink0 wrote:

> The product is just aimed to be used on a local network so protection is
> not a problem so far..

For a web server, protection /is/ a problem even if you only allow
connections from the local network.

It's quite likely that every host on that network will be running a web
browser which acts as a bridge between the local network and the internet.

A modern web browser is a program which does more or less whatever the
internet tells it to do. Placing trust in HTTP connections originating
from local systems is unwise.

On Oct 4, 12:38=A0pm, "Sink0" <sink00@n_o_s_p_a_m.gmail.com> wrote:

> The product is just aimed to be used on a local network so protection is
> not a problem so far.. Other than the configuration, the server is aimed =
to

ROFLMAO! Famous last words!

On the Ethernet, EVERY HOST IS HOSTILE.