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…
Well, it’s gone now. It won’t be hurting anyone again :)