At this time I was not very happy with this thing. I also was not very happy with http (I still detest it). When I had to come up with a name for the new project, the first thing that popped into my head were the words I muttered to myself a couple of minutes before: "This Version Sucks". So the original first stand alone web server got the name TVS. Later I was a bit embarrassed and told people who asked me that it would stand for "The Void Server" as I owned a shop called "TheVoid" at that time.
The TVS was a forking, more or less, http/1.0 compliant server. The mugi interface changed several times and I added a couple of features as I needed them. After a while the whole system consisted of several in parallel running demons. There was the TVS as frontend, linked to that was a mugi (version b) distributor and a via mugi (version a) linked cgi kinda service. As a funny sidenote, the cgi part was bigger than the original TVS itself. Then there was a mugi called logmain (lm) which provided the interfaces for user, game and forum management. As the userdatabase was also needed for the outside forum (outside the game itself that is) and as the data was managed mainly by logmain there also was the external usermanagement (um). The TVS version 1.35 runs now since 2002. It once was running for 6 months without server restart, no leaks or other problems.
Final Harbour was meant as a testing platform for a much more complex game of the same kind. Based on my experience with FH I decided to write it in C++ as this kind of data crunching application would nicely fit into classes as well as the fact that FH already needed some 35 thousand lines and C++ is basically just this much easier to maintain on such a scale. After I started the new coding I also upgraded FH and the other system parts with the classes to improve them and much more important to test them. TVS however was at first glance just not fit to be the core for that new project anymore so I decided to build a new http/1.1 compliant server. This time a real one. If I had to put that much work into it anyway it also wouldn't hurt to go these last few meters too. If you wondered about the 'm' of mTVS, it stood for "more of". I had to change that name though, there are already other products and companies that might sue me for that, so it is now dpfTVS to mirror the current core technology. The first builts up to 2.0.450 or so still had a forking core. Then I ported it to use threads. Later I included the functions of the mugi distributer (around 0.600) and then finally with build 800 I squeezed the cgi part in. Since then I mainly add features, streamline and optimise the code. 831 was the first version I put up my server that did run in parallel with the old TVS 1.35, together with the alpha versions of the new forum and the usermanagement. At this moment, writing this text and building the first pages of the servers new home I use 873 to load the pages into my browser... Of course I code my pages by hand, do you think I really would use a tool for that???
One other piece of wisdom I gained from FH in the end was that this kind of game is currently not anything worth building anymore. So the project is on hold, most likely indefinitely. I still work on the other things. So there will be a mugi based forum system, the usermanagement will be there to use alongside the server, the mugis and of course together with cgi scripts.
Now we have January 2006. It's been an aweful long time since I wrote the above, time for a little update....
I decided to discontinue dpfTVS a year ago. While it had, and still has, a lot very unique code setting it above most other webservers out there, the approach had its faults. Don't get me wrong, it is astounding how far a "forking" core can be pushed, it just isn't the fastest approach. The architecture has its merits. Easier to maintain code is one, easier to build in the features an other. So believe me, it was a hard decission to nail its coffin.
hssTVS has shown speeds easily double that of dpfTVS. It has also shown how hard it is to code for that model. Almost all of the code has been at least redesigned and rewritten once. It became fast, but not much richer in features. Now I am facing the past months which didn't give me much time to work on that project and I know, that it will be as hard this year to get time to continue coding. However, I don't want to give up. I am making plans of the features the pure static content core has to get and I think further to the point when I am to include dynamic content creation again. No time table though, I don't get enough feedback to work any faster anyway, so I will take my time.
The next months will not be solely used to integrate better ways to configue and use what's already there, but to at least include some ways to use hssTVS as a full webserver. This will lead to code rewrites, mainly breaking large quantities into own classes. It might lead to some speed decrease, but will allow for a faster and less bug prone adding of features. So I am willing to make this trade off.
Multi-core and multi-processor technology is on the rise. While it's safe to say that it's utterly useless for static content serving, a single processor/core can fully load a GBit connection, it is a must to support this on the dynamic side of things. So I will leave the static core hssTVS has now mostly alone, but I will add multi-threading in varying degrees where it is capable to make a difference. Taking this a step further, I will revive the techniques I created for dpfTVS in the past. This also means that I won't even try to find ways to speed those old/new parts up by trying to keep the single thread maxime up.
How time flows by. It's January 2011 already....
Let's see. In 2005 I got married. My daughter was born no 24 hours after the entry I wrote above. Since then I bought an old house and my son has been born. Together with my job that left me with no time to persue any activity not related to these things...none at all.
It's sad, really. I added a few things to hssTVS, like other cache algorithms and some more config options for the virtual servers. But I am not even sure anymore, what made it into the last release. I even started adding the code needed for dynamic content. But I was interrupted in the midst and the only thing I could do a couple of months later was to roll back to the last version without it to get at least a working code base again.
I did try quite hard to get things going again, but as written above, a lot time gets used up for family and house. Truth be told, the past year I would have had some time to continue hssTVS again if not for my day job costing me my last nerve the past 2 years. So I am again looking to find a new job, one that does cover day by day expenses while not driving me up the next wall on a constant basis. Once I've accomplished that, I'll most definitely revive hssTVS.
Yes, I've said that many times. But perhaps it'll come true if I repeat it often enough.
That's it folks.