This is a quick FAQ written in response to the comments on the Slashdot posting.

Did the phpstack demo server stand up to the Slashdot effect?

Yes, it survives but it is incredibly slow because of the many packets that is must handle.

What is new with this? It is really easy to write a simple web server!

Yes, writing a simple web server is very easy. The novel thing with phpstack is that is contains its own TCP/IP stack. To the best of my knowledge, nobody has been stupid enough to write a TCP/IP stack in PHP before :-)

Why is the web server so very limited?

The web server is intenstionally very limited in order to be very simple. It does not even attempt to parse the incoming HTTP request.

Why is the TCP/IP stack so very limited?

The TCP/IP stack is intensionally limited to meet the particular needs for the simple web server. I never claimed it to be RFC compliant or of production quality. See my uIP or lwIP TCP/IP stacks if you are looking for full-scale implementations of the TCP/IP stack. Also see my paper entitled "Full TCP/IP for 8-Bit Architectures" for a thorough discussion of the specific issues of limited TCP/IP implementations.

Is it really a "stack", given its limitations?

Yes, the term "protocol stack" refers to how the protocols are designed - they are "stacked" on top of each other. It does not mean that the implementation has to use a stack data structure, nor does it say anything about how large the protocol implementations have to be.

How can the stack support an "unlimited amount" of connections?

The TCP implementation uses a special optimization trick that makes the implementation require no state for each connection. Hence, it does not matter how many connections that are open, the memory usage is constant. The only limitation is the port number range in the client, that is, every host on the Internet can make 65536 simultaneous connections to the server without problems.

The reason this optimization works is that the appliction (the web server) only sends out a single TCP segment in response to an incoming segment before the connection is closed. In this special situation, it is possible to keep all connection state in the client. It works well in the face of packet loss, since the client will make retransmissions. If you find this hard to understand, try drawing a small diagram with all the packets that are exchanged. Try removing one packet at a time and think about what happens. You will notice that the connection will work correctly even when the server makes no retransmissions. This optimization will however only work with clients with an MSS of 1460 and therefore it shouldn't be used in a real system.

This is really easy to do, why did this make it to the Slashdot frontpage?

I submitted it to Slashdot simply because I like to read such news myself. Given the amount of visitors to the demo server, it seems that a lot of other people feel the same :-)