I like writing toy servers too, but I don't get a lot of opportunities, so my latest project is a programming challenge that presents a new protocol spec every 2 weeks for people to implement, and automatically tests the implementations[0].
OP says:
> Goal: write a basic server that can handle the WS handshake and parse an incoming WS frame to see the message sent from the client
> Non-goals: writing a robust or real HTTP server, writing a fully compliant WS server, or handling all edge cases
This is a great way to get started with something that you don't yet understand. I sometimes think of it as implementing "just enough to trick people into thinking that it works".
FWIW, I think the implementation in this post has a bug whereby a client that sends half an HTTP request will block the entire server from accepting further connections, because handle_request() makes blocking calls to recv() until it has a full request, and the program can't accept new connections until handle_request() returns. That's the spirit!
“If you wish to make an apple pie from scratch, you must first invent the universe” – Carl Sagan
It's interesting to see what different people mean when they say "from scratch". In this case the lowest abstraction is (what seems to be) Python's TCP library.
Actually the websocket specification is so simple, that any novice developer should be able to easily implement it by just following the RFC (on top of any TCP library)
Yes and no. There are precision considerations to get this correct, such as allowing interpolation of control frames or fragmentation or how tightly to write frames for maximum performance without collision. These things aren’t so immediately simple and require a bit more effort.
But you are correct in that websocket support can be written directly on top of tcp (without http) for greater performance.
It's like the people who "built a search engine from scratch", or "built a web browser from scratch". It's as simple as pulling a Chromium repo, or plugging into Bing's API!
I love this article! I'm going to start my own series of "toys" for my personal edification now, I never thought doing something half-assed would be so much fun! I mean that with the utmost of respect, too, because I have been stressing so much lately trying to build something "commercializable" but I should have been focusing on educating myself and having fun with tiny projects like this, which can be completed in a few days.
You'll find that most successful software out there that attempted to improve or innovate started as a "half assed" toy.
Otherwise the dude would have given up before it's complete.
No one on their own should aim at building a "cathedral". Build a hut. Then add a toilet cause it sucks to shit outside. Then a sewer system because it stinks. A tap to wash your hands. Might add a bed to sleep overnight. Make that a bedroom. Ok now it needs a shower.
2 years from now you have your "cathedral" and other people come shit in your toilet, so making it squeaky clean becomes a priority.
People tend to forget the word software has "soft" in it.
> No one on their own should aim at building a "cathedral". Build a hut. Then add a toilet cause it sucks to shit outside. Then a sewer system because it stinks. A tap to wash your hands. Might add a bed to sleep overnight. Make that a bedroom. Ok now it needs a shower.
I think Halfassed toys and projects meant to actually be "successful" should have a clean separation.
OP seems to have enjoyed making a toy websocket server. I highly doubt they want to turn it into something bulletproof. It seems they just wanted to learn and make a cool blog post.
Fun weekend projects are usually things you can quit or modify.
When one of them gets attached to a real goal, you get stuck reinventing 50 wheels, and if any get tedious, or the tech you wanted to learn gets obsolete, it's much harder to drop them, you get sunk cost fallacy stuff, etc, plus you can't try random stuff.
You have to use a toilet. You can't make a paper mache tuba and shop vac contraption on a project meant to succeed.
If someone is going to slowly build a cathedral, I think that works best with something that has a reasonable MVP.
The only WS server I would choose is one of the top most bulletproof ones in the language I was using. Until you reach that threshold, the product is a terrible idea for anything practical.
If you want to make a WS server for fun, you probably want to go just far enough to learn some stuff and then stop, because a practical one takes months(Unless you're one of those NIH nuts that would rather use something small and DIY than something reliable).
I suspect that the lack of expectations is why so many people seem to enjoy these weekend projects, and why I pretty much regret literally 95% of them, and feel that they were just time drains I didn't enjoy at all.
I expected DIY projects to actually be part of my future goals, and did crap like building light fixtures instead of buying DMX lights.
I learned some things in the process, but I didn't actually start getting closer to where I want to be in my career till I learned to stop, and that nobody cares what tech I invent, they want stuff to work, and they want people who know how to use the stuff they already trust.
Love this article, i was working on a project for an inverse.proxy with CORS + websockets, spent few weeks learning deep HTTP and ws. Is a good experience to learn the basic building blocks of tech
OP says:
> Goal: write a basic server that can handle the WS handshake and parse an incoming WS frame to see the message sent from the client
> Non-goals: writing a robust or real HTTP server, writing a fully compliant WS server, or handling all edge cases
This is a great way to get started with something that you don't yet understand. I sometimes think of it as implementing "just enough to trick people into thinking that it works".
FWIW, I think the implementation in this post has a bug whereby a client that sends half an HTTP request will block the entire server from accepting further connections, because handle_request() makes blocking calls to recv() until it has a full request, and the program can't accept new connections until handle_request() returns. That's the spirit!
[0] https://protohackers.com/