Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Hardware

The World's Smallest Webserver(s) 73

Posted by CmdrTaco from the collect-them-all dept.
The always excellent Russ Nelson sent us a report on the competition for the lucrative title of "World's Smallest Web Server". Apparently there are a few folks going for it. He writes "HP has one. Dallas Semiconductor has one (only $50). MMC Embedded has one that isn't even in the running, although it does have COM1-4 and LPT1. Dawning Technologies' entry is a joke: far too big to be "smallest". Stanford has one which is best known. And Rt-Control has one named uCsimm because it fits in a SIMM module. The latter two get bonus points for running Linux. Phar Lap claims to have one, but it's a non-starter, being PC-104 based. Dekad Ltd says theirs is really small, but they don't have an Ethernet interface. The one from iReady really seems to be the smallest, but it too lacks Ethernet. Emware's one is so small it doesn't need any hardware (how they claim it's smallest without reference to any hardware, I'll never know). "
This discussion has been archived. No new comments can be posted.

The World's Smallest Web server More

The World's Smallest Web server

Comments Filter:
  • the iPic looks very cool, but he hasn't been willing to let anybody look at his source, so i tend to believe it's a hoax.

  • They have been /.'ed out of existence... anyone have any details in their cache? I'm quite interested in this...
  • Yup, beats mine. Here's the world's *second* smallest Web Server :-)

    #!/bin/bash

    ################################################ #########################
    # #
    # Project: Gild #
    # http #
    # #
    # Purpose: HTTP 0.9 handler for GILD. Handles http requests #
    # reasonably accurately, considering it's under 100 lines #
    # of shell-script. #
    # #
    # Author : Simon Brooke #
    # Copyright: (c) Simon Brooke 1997 #
    # Version : 0.1 #
    # Created : 10th October 1997 #
    # #
    ################################################ #########################

    # $Header: /usr/local/cvs/repository/gild/handlers/http,v 1.2 1997/10/15 20:16:08 simon Exp $

    SERVER_ROOT="/usr/local/etc/gild/httpd"
    DOCUMENT_ROOT="$SERVER_ROOT/htdocs/"
    AGENT_NAME="GILD_http_handler/0.1"

    now=`date "+%a, %d %b %Y %k-%M-%S"`

    read command file protocol

    case $command in
    "HEAD"|"Head"|"head") ;; # that's OK;
    "GET"|"Get"|"get" ) ;; # So's that...
    * ) cat $SERVER_ROOT/error/501.html;
    echo "$now: $REMOTE_HOST: Unknown command [$command]" \
    >> $SERVER_ROOT/logs/error_log;
    exit 0;;
    esac

    rq_file=$file

    if [ -n $file ]
    then
    file=`echo "$DOCUMENT_ROOT$file"`

    if [ -d $file ] # if it's a directory, look for it's
    # index...
    then
    file=`echo "$file/index.html"`
    fi

    if [ -r $file ]
    then
    length=`ls -l $file | awk '{print $5}'`

    ftype=`file $file | sed 's/[^:]*: //' | awk '{ print $1}'`

    case $ftype in
    "HTML" ) type=text/html;;
    "ascii" ) type=text/plain;;
    "english" ) type=text/plain;;
    "a" ) type=text/plain;; # probably a shell script!
    "GIF" ) type=image/gif;;
    "JPEG" ) type=image/jpeg;;
    * ) type=x-unknown/unknown;;
    esac

    echo "HTTP/0.9 200 OK"
    echo "Date: $now"
    echo "Server: $AGENT_NAME"
    echo "Content-Type: $type"
    echo "Content-Length: $length"
    echo ""

    case $command in
    "HEAD"|"Head"|"head") exit 0;;
    "GET"|"Get"|"get" ) cat $file;;
    esac

    echo "$now: $REMOTE_HOST: $command: $rq_file" \
    >> $SERVER_ROOT/logs/access_log
    else # didn't find it; report and log
    cat $SERVER_ROOT/error/404.html
    echo "$now: $REMOTE_HOST: No such file [$rq_file]" \
    >> $SERVER_ROOT/logs/error_log
    fi
    fi
    exit 0 # yes, I know it _shouldn't_ be necessary
  • They're up to 3.0.3 on the release level now, and it's a pretty big improvement over 2.5. Some of the emMicro ports could use some cleaning up, and they're doing some of that now. I'm expecting a new PIC port soon, because the one that shipped with 3.0.3 didn't really fully support RS-485. Also, the C implementation of emMicro has cool things like gotos out of then clauses nested two deep.

    However, they've changed their pricing and now all you can really buy is an unlimited OEM development and distribution license, and thus the price is about the same as that of a very nice automobile.

    I agree that calling emMicro a "Web Server" is pretty lame, although it does provide "services" to emGateway.

    As to whether there are any shipping products, it's hard to say. They have a lot of press releases disclosing design wins, but those tend to be of the "these people say they're gonna use our stuff for this cool new product they're working on" sort, while OEMs tend not to be so interested in blowing emWare's horn when the product ships.

    My project is in-house only (and I can only really afford to do so because I bought before they changed the pricing structure), so it will never "ship" in any traditional meaning of that word.

  • A few comments about emWare and embedded web servers:

    The first question that always came to my mind about embedded web servers was why? Most people are just interested in the hype of the whole thing and not if it will actually do anything for them. A real embedded web server will require more hardware and software than most embedded developers are willing to use in a typical application. The real question is why would you want to server up files through HTTP? You will still have to encode data into that file and process it to mean anything to the client.

    What makes more sense is to have a complete distributed application framework. What emWare has done is create a piece of software that enables embedded developers to create distributed applications in their 8 bit Microchip PIC micro-controller, or micro-controller of their choice, without exorbitant hardware or software costs. It is true that this framework relies on a middle tier application that will proxy a light weight protocol to TCP/IP. This means though that one proxy application (in emWare's case, emGateway) can service a number of devices and provide a common interface for network clients to access those devices. It also means that this application can do some more of the traditional things network servers do but embedded ones don't, namely access control, and security.

    Cheers,
    wharper

    BTW: There is a prototype emGateway running on Linux.

  • Once you've got fifty matchhead-sized computers scattered about you, controlling everything from the gas pressure in your running shoes through the setting of your air conditioner to the caffiene level of your blood, what are you going to use for a control panel?

    My toaster has a custom control panel, with six buttons, four LEDs, and a seven-segment display. My ADSL modem, on the other hand, gets away with one failure-prone moving part - the power switch - by using a web server for its panel.

    Using web-based consoles the graphic interface is done for you, and the software is available (for FREE!) from multiple vendors for all popular platforms. Powerful graphic design tools are available off-the-shelf as well. The last missing link is the web server for the little embedded systems.

    With a rudimentary comm stack and an even more stripped-down web server, filling in the blanks in canned pages and forwarding responses to a cgi-based command handler, you've got all the control and display you need. You can even flip from machine, so you only need one window to run the whole show.

    The smaller the web server, the more of your tiny processor is available for useful work (or the smaller a processor you can get away with).

    So that's why you suddenly see a flood of little web servers for embedded micros, and why it's very important.
  • So there isn't really any evidence that its the thing in the photo, and not the Unix box, a that is answering the pings and serving the web pages.
  • Take any laptop machine, remove the screen, the keyboard, the battery, the hard drive, the exterior packaging and what are you left with? The CPU, the memory, a coupla PCCard slots and a power supply which is now overkill for the now stripped down machine and could probably be replaced with something much smaller. All in all the total package is no bigger than a cell phone and most of that space is the PCCard slots and the power supply. In fact for packages like mine that mount the RAM on a card underneath the battery you could replace it with a flash card and still use the other PCCard slot for a network adapter. Extend this idea to something already small like a Libretto and you'd have a working standalone machine about the size of a Palm Pilot.
  • You could do it many other ways, but what I want is x86. I can use standard linux distros, I can use already available apps and RPMs.

    LK
  • You mean this one [umass.edu]? (and here's the /. article [slashdot.org])

    If you read the updates section, the guy spends a lot of bits defending against suggestions that it isn't legit. Perhaps the story was pulled because he complained to the /. mavens that his little web server was being so severely /.ed. Just a guess.

    --

  • Have you seen the framerate of his gear? it would be more of a "premier webcam" than a stream.

  • The http://www.circuitcellar.com/online won't be functional until Aug 9th. But the initial web page did appear the be /.'d.

  • I wonder if anyone has actually put a webserver in a toaster.

    Wouldn't the heat fry the chips very quickly ?

  • Re:iPic (Score:1)

    by edgy ( 5399 )

    $ ping 128.119.41.46
    PING 128.119.41.46 (128.119.41.46): 56 data bytes
    64 bytes from 128.119.41.46: icmp_seq=0 ttl=53 time=158.6 ms
    64 bytes from 128.119.41.46: icmp_seq=1 ttl=53 time=146.0 ms
    --- 128.119.41.46 ping statistics ---
    2 packets transmitted, 2 packets received, 0% packet loss
    round-trip min/avg/max = 146.0/152.3/158.6 ms
    $ telnet 128.119.41.46
    Trying 128.119.41.46...
    Connected to 128.119.41.46.
    Escape character is '^]'.

    Digital UNIX (eternity.cs.umass.edu) (ttyp3)

    login:


    I would tend to think so too. He had a link to the web server and it gave out an ip address. Unless he's doing some sort of trick with portforwarding, the machine's running Digital Unix.
  • Wireless ethernet? dunno of this, wireless lan maybe, but otoh....
  • Sorry about my incomplete post! (I was in a hurry) That's actually what I meant. At my work we've been doing some stuff for low-cost high-bandwidth transmissions in the under-1000 ft. range, which, since it's specific to streaming data (in my case, sound) with a guaranteed bandwidth, would, with proper real-time compression, work (once you're outside the building it would need something else, but it could be done. Where there's a will there's a way). That's why this idea came to mind. I may want to have one of these microservers (the $15 all-on-a-chip kind, probably) as part of the system for my work, to improve it's adjustability on the fly. (I'd tell you what my work project is for, but my nondisclosure agreements at work would then require me to kill you or something)
  • The page does say the server is connected to the net through SLiRP on a Digital Unix machine, so yes, "he's doing some sort of trick with portforwarding".
  • "Who needs this fire thing? I *like* sushi!"

  • What? (Score:1)

    by stoney ( 780 )
    Please tell me about someone who really needs this. Wearable with ethernet-connector? Gimme a break.

  • Slashdot getting more and more boring ! (Score:1)

    by Anonymous Coward
    Well maybe this is going to be moderated down, but I don't care, I need to say it ! maybe tjis will change somehow the subjects which are choosen by CmdTaco. Yeah I believe that Slashdot is getting more and more boring, really who might be interested by this ! as if there is not anything more interesting in the Open Source arena. I am really puzzled buy the links which are posted here. And I must confess, I get more and more informartion from Linuxtoday !

    Khalid
  • They're refering only to the software. As in, Apache is a web server.

    They say it needs only 750 bytes of ROM and 28 of RAM which astounds me, but whatever..

  • I came up with a use for it: (stretching a bit)

    You wear eyeglasses with a camera in the middle (pricy, but available and very discreet), and have the world's smallest server and a good wireless transmitter hidden in your clothing/pockets. You then broadcast the premiere (or better yet one of the early test showings!) of the next Star Wars and other movies through video streaming in real time from the theater, which is then extended through repeaters througout the world (sit really still, and don't comment!). I'm sure Lucas would be thrilled about that one!

    To up the ante, I offer a $250 prize to the first person who can prove they pull it off (but I assume no liability for their actions!). And here's my email (remove the !'s) to prove I mean it:
    !rickyray!@!patrickhayes!.!com!
  • Somebody pulled a slashdot article on a tiny webserver a few weeks ago. It had some critics but other people felt it might be real. I was annoyed that the article was pulled instead of commented on, if it was a fake.

    Anyone know for certain what it was?

  • Does this current interest have to do with the fact that IPv6 [slashdot.org] will allow every traffic light to have its own IP? Just think of the possibilities for traffic reports!

    Actually I can think of some advantages of including web servers in handhelds and similar devices -- it would raise journalism to a whole new speed. Now that I think about it, there's no reason other than the spirit of the Internet why it wouldn't be better to just use a central server...

  • It seems to me that the one in this slashdot article from January [slashdot.org] is still in the running, once you add the inevitable peripherals (esp. the power supply or battery). And that one's been operational for over a year now.
  • Wheee! We've Slashdotted the world's smallest server. "You big bullies! Pick on something your own size!"
  • There is no way to do this using just a computer hidden in your pocket. A computer small enough to hide would not have enough power to compress the video stream very well. However, you could have a device in your pocket that simply broadcasts the movie at low power on a frequency that no one is likely to notice. You could then hide a device outside the theatre that picks it up and records it. I doubt that it would be possible to send it out realtime, since you would need a fast internet connection to do that, and I have never seen ethernet ports in the bushes outside theatres.

  • iPic (Score:3)

    by Joe Rumsey ( 2194 ) on Saturday July 31, 1999 @09:24AM (#1772538)
    There was another posted to slashdot only a few weeks ago called iPic. It's smaller than any of the ones mentioned here, I think. The URL is http://www-ccs.cs.umass.edu/~shri/iPic. html [umass.edu]. The page has even been updated (new picture, more info) since it was first posted.
  • Boring? Just imagine the possibilities single-chip, IPv6 capable micro-webservers have to offer. It's a bit like X10 taken to the extreme, for only a few dollars per device.

    You might not find this exciting, but I see great potential in developments like this.

  • I've installed a flash-disk based linux on the following board:

    http://www.jumptec.de/product/data/slotpc/littlemo nster_586.html
  • Run it on a socket 4 Pentium and it won't need any heating elements. The concept of bread as a heatsink takes a little getting used to, though.

  • That one was mentioned... "Stanford has one which is best known."

    http://wearables.stanford.edu [stanford.edu]


    ..................................@ @
  • I've actally been thinking about buying and coding a ucSimm for work. I think one would be great for checking ethernet links, VLAN membership, bad packets flying, etc...Just add my pilot as the console. It would be better than lugging a laptop around campus. And I can get around the WinNT requirment if it's not really a laptop...
  • It could be very useful for sharing of documents when you don't need something so heavy duty as apache or even ncsa. Think about it.

    It's the easiest way to share your documents quickly, and if someone adds some code, in a securer manner. Just a quick and dirty module to do file listings on directories and its browsable in your favourite browser. Running Apache for sending a couple of users alone might be a bit much to run and config.

    I know of many companies who use apache to serve documents across the net simply because netbios is a nasty overkill. No more NFS/Netbios shares.

    The smallest HTTP getter? Possibly snarf. The usage of these two tools is great for information passing. Slap on a small html interpreter; they come in a few hundred kb's for the pilot already.

    Mm.. the possiblities...

  • I particularly like the $50 one from Dallas Semiconductor (and the uCsimm for $150). In "real life" I work as a systems analyst at a custom engineering firm; sometimes I'd practically kill for a cheap ethernet connection for embedded devices!


    I've bookmarked the Dallas page (I already had uCsimm bookmarked); I want to play with that toy... but I'll wait for the $50 version, $500 is too much for such a toy at home.

  • x86 is what I'd want. The HD would use so much power that AA batteries will do no good. I'm thinking more along the lines of either 12v DC from an automotive power source or a bunch of D batteries. I'd be able to deal with the extra size & weight of the batteries to make up for the extra music time I'd get.

    LK
  • I don't know if they use on-chip webserver mentioned here, but as far as I know all HP JetDirect print servers have an embedded web server. Once you have assigned an IP address, either through a supported printer or included software, the print server can be configured through http or telnet.

    I think that there are a lot of applications for this and similar products. Wouldn't it be very nice to be able to program the VCR through a web page, instead of pressing the tiny buttons on the remote, or your company's PBX or central heating system).... and these are only some of the more obvious ideas..
  • I've heard of a webserver on a smartcard....now that's tiny
  • This is a hoax: if you've ever used 12c508/9's you'll know a few things.

    1. No UART. You have to do it yourself in software. He's using the internal RC oscilliator which does NOT give enough tolerance to run at 115,200bps which he claims it does.

    2. A software UART which will give byte in/byte out will take around 100 instructions. Oh, and you can't receive any data whilst you're processing other stuff, which makes it hard with bytes end to end - remembering also that 115,200bps is a bit every 10us or so, and that a 4Mhz 12c509 only manages 1 instruction per us.

    3. The RAM is patently too small to do *any* of this. You have something like 20 bytes of RAM on the PIC, even the default ICMP ping packet is around 56 bytes of payload, not taking into account the IP or ICMP headers. You need to copy the ping packet's data portion byte-for-byte when you do a ping reply - how are you going to do this when you can't even hold a single packet in RAM?

    etc etc etc. It's a hoax. You couldn't even get a RFC-compliant IP (let alone TCP/IP) stack on a 16f84, and this is a LOT bigger/faster. People have got limited TCP/IP functionality on 6502's (in 32k RAM) - but not host RFC compliant, just enough to do Telnet.

    Hugo

  • Is anyone using emWare's "server" in an actual product? I evaluated it about nine months ago (version 2.5, I believe) and found the C version sorely lacking in a few key points. Like, they messed up endedness of variables. 2-byte variables were sent little-endian, whereas 4-byte variables were sent big-endian. Their own code failed to pull one or the other out of the data stream correctly.

    Also, calling the embedded emMicro portion a "server" is stretching the definition quite thin. It's a communications stub which only talks to the emGateway portion running on a Windows PC. emGateway is the real web server.

    What it does it does quite well. If they've cleared up the bugs it should be a fairly nice niche product.
  • Yes, as for software.
  • I actually agree with you that the 12C508 is probably a hoax. It has 512x14 words of ROM and 25 bytes of RAM. My guess is that the MCU is having a computer front end the requests and the MCU just posts the data. If it's real it would be a major hack!

    But there is a web server on a 16F84 but it also has a Seiko chip with the TCP/IP stack. I'm not sure of how much RAM and ROM are used but there is probably not much left (1Kx14 ROM and 64 bytes RAM are available and it is code compatible with the 12C50x for the most part).

    I like the Seiko chip as it would allow me to use any processor. I need to get my hands on one of them to play.

    Doesn't Motorola also have a 683xx chip with built in ethernet (external interface components are needed)? Tha would make for a nice web server too (like the uCLinux unit).
  • Hey! The server software most certainly IS open source. In fact, it's released under GPL!
    The other guys may be fast and small but the ease of configurability of my Newton server plus the fact that it generates all the HTML it serves on the fly and runs Newtonscript CGIs and supports a special HTTP-based intant messenger client make it a contender for the world's smallest COOL server.
  • They're refering only to the software. As in, Apache is a web server.

    They say it needs only 750 bytes of ROM and 28 of RAM which astounds me, but whatever...

    What Emware has done is totally believable. It sounds like the server is communicating with the browser with those "microtags" which sound like ~2 byte integers to me. Their server doesn't do TCP/IP, just a "simple serial protocol" which also implies very little code. And the 750 byte ROM estimate probably doesn't include the code to make the device actually do anthing when the browser tells it do -- it is just the framework for sending and receiving commands.

    In other words, it sounds like what is in the device is just a simple framework for communication over a serial line (simpler, even, than a gdb sub!). Emware's business model has got to rely on their off-device technology or they are doomed.

    They also claim to have trademarked the term
    Dynamic Expansion
    which I find really funny. They even want to patent it.
  • Tiny machines dx4-100 and up with IDE, VGA, Ethernet and AUDIO. We could all have homebrewed MP3 players. No injunction from RIAA could stop their distribution either. They're just little computers. Not MP3 only devices.

    22gb of musical bliss. Ahhhhh.

    LK
  • http://www.circuitcellar.com/online/
  • Wearable with wireless ethernet connector?
    Does that make more sense to you?
    It does to me.
  • I (or my office, more properly) have a development license for emWare, and I've built a couple of devices that work with it. Basically, they provide some Win32 DLLs that will front end some low-overhead back-end networks: RS-232, multidrop/full-duplex RS-485, modem... also ethernet is supported, and I think that there's an X10 port of the protocol. The microcontrollers run a fairly light-weight software called emMicro; it is coded as an event loop that, each time through, does basic housekeeping -- doing all the stuff that microcontrollers do -- but also checking for requests coming in on the network. The protocol provides for the Win32 host to discover the capabilities of the controller, and then to access those capabilities over the link; on that level it works sort of like an ORB or portmapper.

    On the Win32 side, they provide a special-purpose proxy service that, on the one side, talks http to a TCP/IP network, and on the other it talks to the back end network (called emNet -- what else) to service requests coming in from the TCP/IP network. One could probably do the same sort of thing by devising a lightweight protocol to talk over a dedicated network of microcontrollers, and then writing service routines that were callable by CGI scripts off of Apache (that's what I was going to do before I found this software -- emWare probably took the better part of a year off my development schedule). Nevertheless, that would be a bunch of work, and emWare's already done it. Main downside is that it only runs on Win32 (95/58, NT & CE). The thing I like most about it is that you can focus on what the controller is supposed to be doing, and you don't have to screw around with matrix keypads and LCD displays and such. Once you get over the big hump in the learning curve, adding new functions is a breeze.

    In addition to the http interface, they also have some Java Bean controls, and an API callable from C++.

    I have it working on PICs (16C76) and some Hitachi H8 units (the H8S/2134 boards that emWare sells), and I'm working on an 8051 design now. I'm using multidrop RS-485. It's pretty straightforward once you see what it's doing, but it is quite expensive to get started with more than their eval license.

Slashdot Top Deals

"More software projects have gone awry for lack of calendar time than for all other causes combined." -- Fred Brooks, Jr., _The Mythical Man Month_

Close