4 ms·
AOL's server code was excellent. It was written by some people that had done similar things for BITNET and had a deep understanding of Unix programming and how
by lanstin 2y ago
AOL's server code was excellent. It was written by some people that had done similar things for BITNET and had a deep understanding of Unix programming and how to use event loops for scalability.
It was in C, but the process was expected to run for months without crashing or running out of memory; if it had an abnormal exit, you'd (the owner as set in some code thing) get an email with the core backtrace. If it had a memory leak, ops would be on you quickly. Ops was considered a primary driver of requirements to dev, and absolutely everything could be reloaded into a running server without restarting it. There was a TCP control port where a TCL interpreter inside the service was exposed and generally you wrote the (very simple, CS 101 style) TCL commands to manage the server. It was a "No Threads Kernel", scaled to the dozens or hundreds of physical machines communicating over a very well managed network, and most 1 process per core, and 1 core for the OS. The 200
or so unix developers (as we were called) had a common understanding of how the framework worked and if you were just writing app code it was basically impossible to write slow services. We had technical writers that would interview the developers and write books that could be handed to outside developers and lead to a successful integration with no developer time spent.
The NTK was primarily for sending msgs over the network - we had a principle to never write to disk (which were pretty slow in the 1990s), so everything was just a server to get network messages and then send out other messages in reponse and then assemble the replies/timeouts and send back a msg to the caller. All done over persistent connections established by the infrastructure, the applications just registered callbacks for msg type 'X' which would present one with the caller information, the msg as a buffer, and potentially a "user word" which would be a way to keep server state around between calls.
The layering, from the main select loop thru different layers of TCP connection, SSL handling (if used, not 100% was SSL in the 90s), thru persistent link handling, application msg handling, timers, memory allocation, etc. was done with such art that I felt it to be a thing of beauty.
- mrpippy 2y agoFascinating, what kind of hardware/OS was used in production?
- lanstin 2y agoStarted with Tandem and Stratus pre Unix then migrated to HPUX then Solaris then Linux on stock hardware. Also Digital for big machines and early usage of 64 bit. I ported to Mac OSX but only for local dev. Funny thing about HPUX to Solaris migration is we found a ton of null pointer dereferences which didn't cause SEGV on HPUX but did on Solaris. And Linux migration was to a different endianness so had to fix any copying to/from ints to a buffer.
- tibbydudeza 2y agoI worked at a bank where we used Tandem NonStop on Guardian OS - loved the programming environment using TAL language and the built-in SQL database.
- patrick451 2y agoSadly, it seems like the moral of this account is that engineering quality is orthogonal to business success.
- bakuninsbart 2y agoGood engineering quality can't save a business, but the reverse isn't true, we just usually don't attribute the failure directly to the software. Instead we would say things like "the company ran out of money" - even if the underlying reason is that engineering was expensive with low velocity. Or that a disruptive competitor brought the company down, even if this could have been prevented if the architecture had permitted eg. relatively easily updating to a more modern UI.
- winrid 2y agoI wouldn't say it was a failure. They had a good run in a very quickly evolving time. That they got a slice of business for years during that period isn't bad!
- CPLX 2y agoWhen did they fail? They acquired Time Warner, creating a company that after continued consolidation is now ranked #13 on the Fortune 500 list.
- deleted 2y ago[deleted]
- foooorsyth 2y agoAOL was an incredibly successful business. Nothing lasts forever.
- __loam 2y agoThe creative destruction of the business cycle grinds ever onward.
- huhtenberg 2y ago
- vmsp 2y agoIs this it? https://aolserver.github.io/ https://aolserver.github.io/
- lanstin 2y agoNo that is a webserver that AOL bought. It used TCL but also threads.
- edgyquant 2y agoCan’t be the same thing GP is talking about as the repo says it’s multithreaded and the poster said what they worked on wasn’t
- mtoddsmith 2y agoMight have been updated later on.
- mtoddsmith 2y agoWild seeing "19 years ago" as the last commit time. https://github.com/aolserver/aolserver https://github.com/aolserver/aolserver
- YZF 2y agoBITNET the IBM academic network? I thought that was mostly IBM mainframes (Not a lot of Unix). A lot of US universities had a mix so I guess people would have exposure to C/Unix.