uip VS Nginx

As the other commenter pointed out, uIP seems to be from 9 years ago. From the issues in the project, I found it is part of Contiki. Are you developing using Contiki?

The CPU architecture is actually the least of your concerns there—I'm pretty sure qemu-user can run httpdito on ARM with less than an order of magnitude performance overhead. There are a lot of embedded systems where an HTTP transaction per second per MHz would be more than sufficient.

The bigger problem is that the Raspberry Pico is a dual-core Cortex-M0+, which doesn't have an MMU, so it can't run Linux and especially can't handle fork(). But httpdito is basically scripting the Linux system call interface in assembly language—it needs to run on top of a filesystem, an implementation of multitasking that provides allocation of different memory to different tasks, and a TCP/IP stack. Any one of these is probably a larger amount of complexity than the 296 CPU instructions in httpdito.

The smallest TCP/IP stack I know of is Adam Dunkels's uIP. Running `sloccount .` in uip/uip cloned from https://github.com/adamdunkels/uip gives a count of 2796 lines of source code ("generated using David A. Wheeler's 'SLOCCount'."). uIP can run successfully on systems with as little as 2KiB of RAM, as long as you have somewhere else to put the code, but for most uses lwIP is a better choice; it minimally needs 10KiB or so. uIP is part of Dunkels's Contiki, which includes a fairly full-featured web server and a somewhat less-full-featured browser. I think he got both the server and the browser to run in 16KiB of RAM on a Commodore PET, but not at the same time.

(twIP http://dunkels.com/adam/twip.html is only 139 bytes of C source but doesn't support TCP or any physical-layer protocol such as Ethernet, PPP,or SLIP.)

However, Adam Dunkels has also written Miniweb http://dunkels.com/adam/miniweb/, which implements HTTP and enough of TCP and IP to support it, in 400 lines of C. It needs at least 30 bytes of RAM. Like twIP, it doesn't provide a physical layer. But that's solvable.

I am currently reviewing existing TCP/IP stacks for microcontrollers, and in particular uIP.

Yeah, unless I'm looking at it wrong, there doesn't seem to be any meaningful difference between 1.25.5 and 1.26.0:

https://github.com/nginx/nginx/compare/release-1.25.5...rele...

However, it's very unlikely that .NET developers will directly expose their Kestrel-based web apps to the internet. Typically, we use other popular web servers like Nginx, Traefik, and Caddy to act as a reverse-proxy in front of Kestrel for various reasons:

> I actually don't understand why I am seeing arguments like this all the time.

Have a look at:

https://github.com/nginx/nginx/blob/master/src/http/modules/...

It's got the whole checklist: nginx idiosyncratic module system, inline parsing, custom utf conversion, buffer preallocation and adjustments, linked lists, comments about side effects of custom allocator, and probably other things.

It's not easy to deal with source like that and any serious improvement to that area would effectively be a rewrite anyway.

Since anything doing work in nginx is a module anyway, it wouldn't even have to be a full rewrite in one go.

According to this article, nGinx is being used to serve 34% of all websites in the world. I checked out who's contributing to nGinx, and just like I thought, the project has 8,208 commits, and 5,366 of those commits was made by 2 software developers; igorsoev and mdounin.

Nginx + Roadrunner (fcgi mode)

Apache’s mod_fastcgi’s last commit was 2 weeks ago:

https://svn.apache.org/viewvc/httpd/httpd/trunk/

It’s a fork of what you linked (and was more popular afaik back when fastcgi was state of the art, and apache was the undisputed champion of web servers).

These days, nginx has more market share than apache, and its fastcgi module is one of the more recently updated ones in its source tree (5 months vs multiple years):

https://github.com/nginx/nginx/tree/master/src/http/modules

If I was going to build an embedded web server, I’d start with nostd rust, probably with though axum + tokio, since thats already memory safe-ish.

If I needed fastcgi for some reason (dynamically loadable endpoints, or os-level isolation), there are at least four implementations of fastcgi for it. No idea if any are decent though.

APISIX is an API Gateway. It builds upon OpenResty, a Lua layer built on top of the famous nginx reverse-proxy. APISIX adds abstractions to the mix, e.g., Route, Service, Upstream, and offers a plugin-based architecture.