Recently I am busy on vohttpd 🙂 VoCore should have a light weight and powerful httpd(NOTE2), so we can make IoT web interface easier.(save memory and flash will reduce the cost too 🙂 )
I am new to web develop, so the process on http/javascript is very slow 🙂 But I am good at net/c develop, that part is going well.
Currently I have finished the vohttpd main application, now just consider the framework for the web side interface. I want it to be very simple and modularized.
This is my dreamed embedded httpd application:
1. light weight. even able to run on 8~16MB memory device.
normal memory usage < 60KB(NOTE1), or even < 20KB in low performance situation.
2. flexible. we can drag & drop plugin into browser, then the embedded device will have such function.
For example: to enable webcam function, we just need to drop the install package into browser, it will install all necessary compose. and show the webcam video on browser.
3. easy to develop. it should have only a few( < 10) necessary api for the plugin. I hate read documentations; also hate write them. 🙂 A developer who knows some basic C language(mainly is for string) will able to develop plugin.
User Interface should be all in web side. Plugins should only provide the function, like webapi. The javascript make the logic for the UI, bootstrap and html for the widgets on the UI.
4. fast speed, stable, etc...
I write a simple plugin control interface, based on bootstrap and jquery. source code can be find at http://github.com/vonger/vohttpd. I am still learning this, the interface will be upgrade later.
Now it is able to compile and run on linux, macos, windows(mingw). Browser: firefox, chrome, ie.
NOTE1: this memory usage is the application alloced memory, system memory is not contained. It is about 200KB~300KB in total. That is used to shared libraries, plugins, etc.
NOTE2: I compared and tried many httpd applications, none of them made me happy, in my last blog I explained that.
Dear Vonger!
It seems to me like you are re-inventing the wheel here. I would dust off the good old boa server and start with that. It certainly has the performance characteristics that you are looking for: http://www.osnews.com/story/2217/An_Overview_of_the_Boa_Web_Server/page2/
The biggest downside with boa is that it is no longer maintained actively. But it is surely better to start off with a stable boa web server than start from scratch. Yes, you currently have pretty simple use cases, but sooner or later you will need to complicate things, e.g. SSL/TLS (patch exist for boa).
Merry X-mas,
Zalan
Thank you, I will check 🙂
I am not re-inventing wheel, just trying to make it better.
As my last blog said, such web server like boa can not deal heavy load due to it is using shell cgi. If I want to transfer video, sh app will be too slow for that. Shell is a old fashion way and really easy to use, but for embedded device like VoCore, it can not afford that. boa is mainly used on raspberrypi, or 2440 based board, that has a lot of memory(>= 64MB) so shell cgi is not a heavy load for them. But for VoCore, its CPU is not that strong, we have to optimize the code to make it works like native application for video, audio etc. If just used to control some GPIOs from web side, I won’t write vohttpd, due to LuCI is working very well already. If you want get video from VoCore and same time have some free CPU to send signal to GPIO to control the robot motor, have to improve it.
PS: https is easy to be added as a plugin. after that, vohttpd main app about 34KB, much smaller than boa. 😀
Hello!
Sorry, i’ve been trying to find where you mention boa in “my last blog” without success. Have you actually tried Boa on vocore or are you just making assumptions about its performance? The reason for why I’m still sceptical is that we’ve been using Boa on all Axis network surveillance cameras for ages (on weaker CPUs than VoCore) and we have not experienced any HTTP streaming issues, which you are mentioning.
//Z
I improved two important parts(maybe for me it is important 🙂 )
1. memory control: boa is good, it use look a side list for memory control(this is good, most httpd just malloc and free), but I want it stable in extreme situation, so I write a memory control, I do not want http takes too much memory then effect other process.
2. cgi-bin: every call is a new process, if we call it frequently, there will be a lot of resource cost on create/destroy process also pre-deal the cgi macro. My web UI request cgi-bin very frequently, so I have to improve it to native code. At least, a native code is more or less faster than a shell script.
I tried to make it able to transfer 720p or 1080p, when I do the job, the LuCI index page is very hard to open(they based on cgi shell), compared vohttpd opens easily.
I write it just because none of exists httpd reached my request. If you feel happy about boa, just keep using it 🙂
Actually I’m planning on sticking with uhttpd myself for my use-cases. I was just trying to help you out with boa, since I wasn’t sure you knew about it.
By the way, it is possible to write and host pre-compiled binary CGI applications as well with boa, uhttpd, and all other web servers complying with the CGI standard as far as I know. In other words, you are NOT limited to shell or lua scripts for that matter.
//Z
Zalan, I am trying boa with luci web contents/cgi. But the web browser does not show the styles of luci web admin pages. Do you know why? Problems of boa to serve stylesheets? Yeah, it takes much less resource than uhttpd.
Brandon. I’ve not tried Boa with OpenWRT + vocore, but i hope to find the time soon. My experience with Boa comes from Axis network cameras. I’ll let you know how it works out when I do.
And found luci cgi with lua is another one that consuming very much of memory, I guess http server is not the one to blame with luci.
Brandon!
I’ve had some time to play around with my vocore now. I also tested sthttpd (supported thttpd). As expected it boa has the smallest memory footprint of all web servers:
932 root 1564 S /usr/sbin/uhttpd -f -h /www -r OpenWrt -x /cgi-bin –
2249 root 896 S boa -c /www -f /etc/boa.con
2155 root 1796 S thttpd -C /etc/thttpd.conf
As you can see the VSZ of boa (896) is way smaller than uhttpd (1564). thttpd is actually bigger than (uhttpd). So you will basically save 600 KB RAM by switching to boa.
I do not know why you failed to load static content (*.css) with boa, since I did not experience any problems like that – neither with boa nor with thttpd. For your convenience I’ve pushed the openwrt source, which I’ve build for vocore including boa and thttpd here:
https://bitbucket.org/zuperman/openwrt/branch/vocore
As you also note, luci/lua itself consumes most memory approx. 2.5 -3.5MB for each session. Its not really surprising, since Lua is a virtual machine with some overhead.
The only significant limitiation I can see with uhttpd/boa/thttpd is (what Vonger also points out), the obvious fork-rate limitations of the CGI standard. However, I’m only planning on using vocore for controlling stuff, so I guess I will not run into that limitation.
I tried vohttpd. Current the plugins design is attractive to me. The command line startd vohttpd is a little difficult.
vohttpd -d xxxx/yyy.so -d xxxx/zzz.so could load plugins correctly.
do not add space.
like this:
./vohttpd -d/tmp/voplugin.so -p80
do not like getopt 🙂
Yes.
vohttpd -dxxxx/yyy.so -dxxxx/zzz.so -p80.
I forget when i write the notes. I love the ideal.
If you want ultra low memory and cpu usage, writing a http server in c using libwebsocket is the way. you will get upload functionality and websockets in a very small program. The demo code with libwebsockets shows it well, and once you get use to the library callback structures its really easy to implement a server in c which uses websockets for transfer of data. Its practically already written in the examples too. Add libwebsocket to your build root packages is easy because they already made the make file ready for openwrt.
actually a web server is very easy to write…hard part is the client part.