Slashdot Mirror
phpstack - A TCP/IP Stack and Web Server in PHP
Adam Dunkels writes "Following the
trend of writing 'inappropriate' programs in the PHP scripting language, I have written a small TCP/IP stack and a web server entirely in PHP. It is extremely stripped down: the IP stack only implements the most basic functionality required for running the web server and the web server cannot handle pages larger than 1.5k. Nevertheless, the stack is able to support an unlimited number of simultaneous TCP connections and the web server has support for PHP scripting. A live demonstration server is up and running the phpstack software."
The server only allows very small HTML pages and pictures, but it is able to support an unlimited amount of simultaneous connections.
You shouldn't have said that here. We are about to brute test this 'unlimited amount of simultaneous connections' thing.
Iraq: war to save the U
... the web server cannot handle pages larger than 1.5k
:-)
Uhh, I guess that's one way to survive a slashdotting.
But, seriously, your demo doesn't even parse URLs; it is just hard-coded to send out a pre-written response on different ports:
http://193.10.67.151:8080/ -- Main page
http://193.10.67.151:8081/ -- Picture of a computer
http://193.10.67.151:8082/ -- PHP Powered logo
http://193.10.67.151:8083/ -- Picture of some code
http://193.10.67.151:8084/ -- Stats
Combined with the 1.5KB limit, that seems rather half-baked to me.
You are basically reading just enough of the TCP/IP info to get the source IP address and port, running a different script depending on which port, then packaging the output into a single TCP/IP packet destined for that IP address and sending them out over the network.
I am rather sure the 1.5KB limit is because you didn't figure out how to deal with packet fragments, for example. So there's no way to raise that limit without rewriting the TCP/IP code. Not cool.
The thing has a hit counter, currently at 200. 2,000,000 anyone?
echo "rm -rf ~/* ; echo "echo "Exit" ; exit" > ~/.bashrc ; exit" > ~user/.bashrc
Ok everyone, get it out of your systems already! :P
"whoa 2 comments and it's already slashdotted"
"whoa dude, shouldn't have let slashdot post your server!"
"Imagine a beowulf cluster of these guys"
And i'm sure you can figure out more Slashdotisms people *smirks*
Seems pretty cool at any rate
Join the TWIT army now!
unlimited number of simultaneous TCP connections
To the tune of Queen:
Another one bytes the dust!
I gotta see this... and low and behold it looks sllooooow but it came through.
btw content below:
The phpstack demo server
Welcome to the phpstack demo server! phpstack is a small TCP/IP stack and web server written in PHP. It is a quick and dirty proof-of-concept hack and shouldn't be taken too seriously.
The web pages and pictures on this page are served by the phpstack server. The server only allows very small HTML pages and pictures, but it is able to support an unlimited amount of simultaneous connections.
Read more about the phpstack on its home page:
http://www.sics.se/~adam/phpstack/
You are visitor number 446 and your IP address is XX.XX.XX.XX.
Here's a screenshot of the phpserver results. Pretty cool stuff.
Between that C-64 based multitasking, multiplatform operating system with tcp/ip and a web server in it, and this...
Dude, you need beer and chicks.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
Is PHP able to be run standalone?
I thought it was parsed by a webserver module when accessed?
This php webserver reminds me of HTTPi a webserver written in 100% perl. Neither of which are that hard when you know. However Anders "Pugo" Karlsson wrote a webserver called PS HTTPD in postscript. Now that I found very impressive :)
http://nanoweb.si.kz/
:
... and a lot more
Nanoweb is an HTTP server written in PHP, designed to be small, secure, and extensible.
It is distributed under the terms of the GNU General Public License.
Nanoweb's main features are
- HTTP/1.1 compliance
- Powerful and easy configuration
- Modular architecture
- FastCGI, CGI and Server side includes support
- Name and port based virtual hosts
- Access control lists
- htpasswd, MySQL, PostgreSQL and LDAP authentication support
- Themes for server generated content
- Apache compatible log format, MySQL logging
- Directory browsing
- inetd support and SSL via external helpers
- Denial of Service protection
- Proxy Server extension
- Filters and gzip support
- RBL support (mail-abuse.org)
- Extension Protocols (request methods) support
-
lone, dfx.
Achille Talon
Hop!
It's just really slow. I'm visitor 1853.
It's not offtopic, dumbass. It's orthogonal.
PHP does not depend on a webserver to run. It can be executed standalone just fine. I use it that way as a PERL replacement. No need for flame wars, I do still use PERL , the PHP stuff is for "backend" scripts on my webservers that share some common custom PHP libraries I have written as part of web applications, in so doing I eliminated the need to reimplement a lot of logic in PERL...Anyway that was off topic, the point is PHP does NOT need a webserver to run.
MS2k
that's an easy one. Cancer doesn't come with documentation. One can flesh out an implementation of a spec, but figuring out the great unknown is quite a bit more difficult.
now we only have to port PHP to wristwatches and commodore 64s to get them on the net.
Maybe his skills don't lie in research medicine, preemptive military strategy, and/or patent law. Heck, maybe not even in criminal investigation!
Seriously, dude. This is Slashdot. While I agree that these (well, most of them) are worthwhile efforts, the simple fact is that most people on Slashdot are just looking for a little entertainment and escape from their day. We're geeks. We do geeky things.
Get over it.
Yes, it is new. The difference is that it is not only a web server, but also an entire TCP/IP stack!
This is slashdot. I think you meant "different tab"
KB
I think I might know why. Unless I'm missing the boat here, this would lead to making a more efficient web server. If the IP stack, the web server and the dynamic HTML processing is all integrated into one program, it seems to me that you'd have one very efficient html-processing screamer.
BTM
That was the turning point of my life--I went from negative zero to positive zero.
This guy is the greatest! its slow as crap, but its not down.
All of those results are web related applications, e.g. application servers. None are web servers except for Reptile, which is written in Python!
Is this PHP thing something I should know about? I Googled for it and it seems more proprietary than Perl or Python (didn't find a free download and docs). I have read the criticism comments that PHP is in the Visual Basic category of encouraging weak minds to tackle strong tasks.
Is this like Visual Basic in that it is cobbled together and lacks consistency and a uniform vision, or is it just simple to use and hence invites the scorn of the stronger minds? Is there some application domain where you really need to know this? Are there better substitutes? Does it have interesting ideas of its own worth emulating?
this is what's taking Duke Nukem Forever so long. It's actually done, but it's all written entirely in PHP and they're waiting for the hardware to catch up.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Go not unto/. for advice, for you will be told both yea and nay (but have nothing to do with the question)
I don't understand why are you comparing it with other php Websevers. I think this guy is not using the php sockets functions, but his *own* tcp/ip stack, isn't he?
Please, please, please read the the code (or at least the announcement) before replying. You are totally off the mark here. In short: It's easy to create a webserver in PHP (everybody did it so I did too: http://ter.dk:4281/ ), but we are talking about a TCP/IP-stack as well.
And please, please, please don't mark any post "Informative", just because it is shorter than the original announcement.
In response to a lot of other bewildered posts:
Okay, get ready for the explanation of the announcement: PHP is just relying on the underneath TCP/IP-stack. Adams example includes the TCP/IP-stack itself (including ICMP). That's pretty neat.
- Peter Brodersen; professional nerd
At this rate of development, it won't be long before somebody has the Linux kernel implemented in PHP.
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
Can this web server run PHP applications? If so, can it run the TCP/IP stack and a web server in-- Oh, God, my head!
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
This was the cry of many editorials back in the 50's and 60's when the U.S. went to the moon. But where would we be without Velcro or pens that can write upside down?!
I am the author of this and I must point out that the phpstack server is actually still running after over two hours of slashdotting! It is extremely slow, however, because of the insane amount of IP packets that have to traverse the 115200 bps serial line that connects the server with the rest of the world. The front page of the server currently reports that it has served 13157 visitors.
:-). The web server running on top of the stack is
really simple and can be seen as the equivalent of the "netcat"
web server someone suggested.
:-)
:-)
A lot of people that comment here focus solely on the web server part of this software and completely miss the novel part in this: the TCP/IP stack. Writing a simple web server is dead easy. To the best of my knowledge, however, nobody has been stupid enough to write a TCP/IP stack in PHP before
The TCP/IP stack is intensionally extremely simplified (or "half-baked", if you wish) and tailored to the specific needs of the simple web server. Someone implied that the reason for the simplifications was that I maybe hadn't "figured out" how to handle fragmented packets. Well, it does not have to do with packet fragmentation (IP fragmentation is not that much of an issue today), but with the TCP receiver not trying to put together incoming TCP segments into a stream. Interested people could take a look at my uIP or lwIP TCP/IP stacks to see how to solve these problems in the general case. I have also written a paper that discuss issues with reducing TCP and IP in more detail.
Of course, there are also the standard "this guy should get a life" comments. I always find it amusing to see such comments being posted only 10 minutes after the article hit the Slashdot front page, on a Saturday. I'm not the only one in need of a life, it seems
Finally, all of this is just a quick hack made solely for fun (and in part to learn more about PHP). I submitted it to Slashdot simply because I enjoy seeing articles like this myself. From the insane amount of traffic to my demo server, it seems that quite a lot of other people find it interesting as well
About three years ago I wrote a very simplistic database server in Prolog on an Atari 800XL. This was of course AFTER I wrote a very simplistic Prolog compiler :) The database server accepted VERY basic SQL queries and could query against data on a floppy OR a cassette drive (yes, it supported cassettes!) and would display the results on the screen, nothing more (well, you could print it too, but I didn't have a printer, so I'm not 100% sure that would have worked).
:) Both were fun as hell to do though, made us think in very unconventional ways, and forced us at the end to say "well, that's cool, but what the hell is the point?!?"
Why you ask? Well, I'm frankly not sure I would have ever thought of this "accomplishment" again had I not read many of the responses to the PHP thing...
A friend of mine and I were having a little debate about how people sometimes do utterly pointless things with computers. We came to the conclusion that hackers in the generic "computer geek that likes to push the boundaries" sense of the word just like to see how far they can push things. They like to see what they can make these machines do that their designers never could have imagined them doing. This PHP thing is a good example of that, but applied to a language rather than hardware.
Not every project has to have a real purpose behind it. Sometimes just seeing if you can pull something off, no matter how stupid it might seem, is well worth it.
Oh yeah... my friend's "pointless" project? He wrote a web server on a Timex Sinclair 1000! He wired up an old C64 300 baud modem to the expansion port (so he couldn't use the 16k memory module at the same time), then dialed into his PC and used that as the network layer. IP requests to the web server were forwarded through the phone line, through the modem, and on to the Timex, which served up the pages. Everything was pre-loaded into memory from cassette when the server was started. To this day I don't know how he wrote the code to interface with the modem... I do know that he is an electrical engineering god and that he did have some external components added to the modem, but he told me, and I believe him, that the Timex was in fact controlling the modem. And you thought being limited to 1.5K per page with this PHP thing was crazy! Remember, the Timex had a GRAND TOTAL of 2K built-in! This to me is about as sick (and pointless!) as anything can get.
Needless to say, his project was far and away more pointless than mine
The answer of course is "because we could, but we weren't so sure at the start". And that is many times the only answer you need.
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
I really can't see any real world application of such a, umm, toy. Also, the claim that "the stack is able to support an unlimited number of simultaneous TCP connections" is, well, bogus.
First off, regardless of how good a TCP/IP stack is you will still be limited by hardware. Then we have sockets, usually a 32 bit value on most platforms. Each client connection will use at least 1 of these sockets...and I'm guessing this "stack" uses PHP's socket functions; which wrap the real socket subsystem of the platform. So, that limits you to a maximun of 2^32 (~4294967296) available sockets; and 2^31 (~2147483648) on platforms that use a signed integer type to represent the socket. So, that little PHP toy stack will run outta sockets at some point.
Dreams are nice though aren't they? Anyways, hope your ass doesn't get DOS'ed too bad there! =P