Oh, so that does nothing?

Our network library is fairly complex. It supports Windows, using the Windows Winsock API rather than standard sockets, Macintosh OS9 and OSX and our Linux-derived servers. The code is a nightmare of optional (#ifdef) code, and it comes in no less than 9 different flavors!  On the server side, we have to build two versions: “transport” and “server”. A good deal of my time over the years when looking into any networking issues has gone to maintaining the “transport” version.

I’m in the throes of flattening out our server-side directory tree. Each of our projects has its own “syscfg.h” file in its directory hierachy, which naturally causes a conflict if you try to flatten out the directories, and each of them is different. They are all #defines, however, so I can just move them to the commandline for each project.

So there I am looking at the teulKit Makefile and sources and wondering how to resolve the 6 teulKit syscfgs I have. I notice that the ‘server’ library is actually built with the teulKit flag that indicates it should include client functionality and not the server stuff. That’s very odd…

My first port of call was my archive of the source of 1.19; and that was configured the same way – its not something I’ve broken meantime. Next I pulled up Source Off Site and checked the project. It’s been this way since before I joined CRS. Ok. I didn’t break it.

Time to look at the code and see what this means…

After a good 2 hours of browsing, I’ve looked at all the #ifs, and come to a remarkable conclusion. The “teultransport” library, which takes aproximately 1/5th of the cluster build time … Isn’t used.

Apparently this extra version existed to facilitate the old “three in one” architecture where the cell hosts had two processes running on them. TeulKit’s server architecture can only support/tolerate one clustered process per physical machine, so Marty developed a proxy which forwarded packets between the network and the actuall processes.

Then eventually along I come and observe that 97% of the CPU being used on these machines is communication between the processes and forwarding/re-receiving of packets and merge the cell host with its strat-data companion, getting rid of the proxy.

But apparently my understanding of teulTransport was incorrect, thinking it to contain the transport features of teulKit while teulServer was the server functionality common to each of the servers. Infact, they’re just two separate instances.  I can drop teulTransport.

With this realization comes another: all the code that is specific to teulTransport (heaps of it) is entirely moot. I went in an put an #error into each section of transport-specific code and rebuilt the cluster from scratch. If my assumption was wrong, it’s going to stop me from compiling never mind failing otherwise.

I checked source control and I’ve done at least half of my teulKit work on that code…

*Sigh*

Well, it’s gone now. It won’t be hurting anyone again :)

8 Comments

Ah, good old negative LOC leading to positive work. :)

“How many lines did you do this week?”

“Negative five thousand.”

Old programmer adage: when in doubt cut it out.
Amazing how often you wind up with code that does nothing.

I sometimes wonder if all the things we “think” are wrong in the game are a problem from the start or just a legacy of the evolution of the game over an old basement. Just like building over messy roman ruins, so to speak, and then noticing that some fresh well-organized concrete will fix it.

I think that’s why so often people are surprized when we tell them a thing is really difficult; the house of cards effect. The simple-things that are difficult in our engine are usually only hard to do because the engine is built to not do them rather than simply not built to do the thing.

Sheesh, while you’re at it, cut out the MacOS 9 stuff .. we didn’t support that when I was still there .. and that was a while ago now :)

Heh, SourceOffSite decided to play silly buggers yesterday, that thing where you say: Check out file, [./] Do NOT overwrite local copy, Check in file and … voila, somewhere in the process it overwrote the local file. Or possibly the one where the file on disk has the same checksum as the one in source safe despite being different and there’s no way you can persuade SoS to commit it. I dunno which, but I got an early call from a very angry Martini ’cause the client was spewing hundreds of errors :)

I’d dumped the client’s 8 variously named “MAX_(NAME|CALLSIGN|HANDLE)_(LEN|LENGTH|SIZE)” and substituted them with “MAX_HANDLE_LEN” which is in a tiny little rickb-friendly header file, freeing a whole bunch of files up from their dependency on vehmain.h :) (Bringing back memories, Thunder? :)

Just about done with this cleanup now; got all but the mmhostd switched, strat took a little longer because of the Lua stuff, made it build its own dependency file so that it’ll regenerate correctly and apropriately, but for the life of me I couldn’t get the output from tolua++ to compile until I finally realized I *wasn’t* giving it -Wall -Werror in the old build, and there’s a bunch of redundant code that’s always been there but gets ignored without those :)

vehmain.h .. aaAAHAAHHAHHHHHHH!!! Hehe. It’s ok, now I have unit_s.h and unit_c.h to keep me busy!

Source control .. wow .. that could turn into many many blog entries worth of content right there.

Leave a Reply

Name and email address are required. Your email address will not be published.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

You may use these HTML tags and attributes:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: