The bill of work was set last Thursday in my own words:
...look at them in the light of the new situation: are those sane business choices that help S.MG thrive or are they dangerous ideal choices that will sink S.MG in the end, all the more painfully for the prolongued agony that existing resources can allow? I tell you that I don't quite see what *else* can I do but at the same time, I also don't quite see how can this can be done with any guarantees.
Given the above task and the very issue at hand, I chose to start the work from what I see as hard, *usefulness* requirements for S.MG's tech overall and otherwise server and client sides in particular1:
Server Side
- Reliable - the server code2 should do exactly what I expect it to do, not more nor less. Easy to state, harder to guarantee given the whole environment otherwise but this requirement won't go away just because it's not a walk in the park.
- Secure - while this is arguably included in "reliable" above, it's worth mentioning it on its own too because Eulora's currency, the ECu, is pegged to Bitcoin and transactions as well as fortunes of players in the game can be quite hefty. Some items can be worth a fortune just by themselves, at least as far as the players are willing to bid to get them.
- Stable - Eulora is an always-on game really, there shouldn't be "down" time, no matter how much and what players throw at the server essentially. Some regular and minimal maintenance time3 may be all right but the plan is to keep such things to a very minimum (and predictable!) amount of time.
- Deployable in commercial settings - from a purely technical point of view I think I could state this along the lines that the server should be architecture-independent perhaps but this is already a reduction of the actual requirement. Eulora's server code is not meant to be public and as a result, there is the technical as well as non-technical aspect to deployability: it should be deployable in a variety of environments (hardware and software) but it should also keep its secrets, as intended.
Client Side
- Reproducible build - given that currently there is only one client and moreover that this one client is going to be whatever I release, I'd much rather have a fixed and reproducible build that won't be fucked up by shitgnomes armed with all sorts of updates. This might be of course not *fully* possible as stated in practice and I don't intend to chase it *more than it's worth* but the direction is there and the more fixed (ie won't need to fiddle with it if you have a different computer than mine) the building process is the better.
- Secure and flexible communications with server - see the ECu and Bitcoin at server side above. As the game proceeds effectively through an ongoing communication between client and server, there has to be a way for players to decide on the exact compromise they are happy to live with in terms of security of their communications and associated cost (including costs of all sorts, for instance convenience as well as bandwidth).
- Full decoupling of client from server & game version - in particular, there should be basically no pushing of "updates" on the user/client; the client should simply be able to discover and request + download new game content of any sort, as it becomes available on the server (ie the client pulls the updates if/when it wants to).
There could be more added above to both client and server but I think those are the most relevant currently and for the task at hand.
Armed with the above, I started looking at everything Eulora related, on three main directions: hardware dependencies, software dependencies, design decisions.
- Hardware dependencies
- Software dependencies
- Dulap-Gentoo: frozen snapshot, reproducible but dead-end.
- Cuntoo: frozen snapshot, reproducible but currently as dead-end as Dulap-Gentoo since nobody is/has been working on it for quite a while (and the amount of work required is considered high anyway); it also requires further significant effort to fully move all dependencies to static building and to Cuntoo itself
- CentOS 6: dead-end as unsupported by anyone and otherwise set to most likely vanish commercially from March 2020.
- Other distro: at best unknown, most likely incompatible with required versions of gcc & python at the very least.
- Design decisions
TRNG (Fuckgoats aka FG)
The main hardware dependency currently is the FG(s) provided until now by S.NSA and used as source of entropy for all encryption matters on both client and server. I reviewed the item and its design documents that are quite clear and as far as I can tell currently complete. Ideally I would take the time to procure the needed parts and make a few FG myself to be entirely satisfied that S.MG can indeed proceed on the assumption that there is a working TRNG connected at all times. However, the ideal is one thing and practice quite another: so far I haven't actually built an FG and therefore the most I can say at this time is that this latest review of existing items and documents did not reveal any potential trouble that I can see. Moreover, the S.MG code does not make a lot of assumptions about the source of entropy being specifically an FG - this means that changing the source of entropy at a later time should not be problematic for S.MG: the reading of data is isolated and can be replaced without a major overhaul of everything. Based on this, I wouldn't recommend any specific change to the code or approach regarding TRNG at this time.
Other than the FG, the initial perceived dependency on AMD architecture does not hold: both client and server have been successfully built and deployed on both AMD and Intel computers. While I haven't tried - nor do I have the hardware for such attempts - to further check it on other architectures, I don't think there really is a need at this time for exploring more exotic architectures.
A significant fixed dependency is on gcc 4.9 (or earlier but so far tested on 4.x versions only) and python 2.x (tested on 2.6 and 2.7 but in principle < 3).
Both client and server have been successfully built and deployed on the following distributions: CentOS 6 and 7, Ubuntu 14.04, Gentoo (several versions but I'm at a loss as to how to fully pinpoint one down since I'd need to list ALL versions of all packages by the looks of it, ugh). The server has also been compiled and ran on Dulap-Gentoo (aka as proto-cuntoo). It's worth noting that OS versions especially for server side are a potentially troublesome spot if S.MG has to rely on commercially available versions because the preferred versions are increasingly hard to find in the wild (CentOS 6 for instance seems to be set for vanishing from March next year) and new systems bring in a *lot* of changes that are a huge ball of unknown at best (and a complete disaster at worst). Dulap-Gentoo is a frozen snapshot and as such reproducible but essentially a dead-end since there's nothing supporting it.
It's unclear to me what concrete options does S.MG actually even have regarding OS on server side especially, since there seem to be:
Other than OS, the most significant software dependencies are CrystalSpace, Cal3D and MySQL, together with the autoconf/make/jam/ftjam building systems that CS especially depends on4. Those force in turn quite a few other dependencies (CrystalSpace is the champion at how many dependencies it pulls in) but it's worth noting that most of those are on client side (ie ultimately something that is more flexible anyway and up to players rather than S.MG directly). The more troublesome aspect here is the potential clash between versions of everything required, especially in the context of different OS versions (and corresponding python+gcc) than the ones already checked above. One promising direction as far as I would say now is mainly due to using GNAT as it comes bundled with gcc and therefore one could perhaps ride on that even on a different system especially if everything is indeed moved to static linking (see below at design decisions). This is however not fully investigated (ie to which extent it's enough & how it plays along with everything else).
A significant decision was the move towards Ada and GNAT as language and building environment, essentially away from C/CPP and all the auto/make tools. This move is still in progress in that some components (CrystalSpace most notably) still require autoconf and jam/ftjam. I looked again at all of this but I can't see any specific issue or problem in the long term with Ada and GNAT. There is of course the sjlj aspect for which the previous investigation still holds as far as I see. There is also the aspect of GNAT not working on ARM architecture but as far as I can see this is not a significant problem as there is no reason why S.MG should support or be concerned with ARM. If anything, I'd say quite on the contrary, removing concerns about the ARM architecture and its lack of GNAT makes more sense to S.MG (I don't see why should Eulora care specifically about ARM). The ARM architecture was pushed to some extent because of the Rockchips but that is no direct concern for S.MG from my point of view.
Overall, the move towards Ada and GNAT still seems to me both sane and essentially benefic to S.MG as compilation with GNAT5 is so far way more predictable in all the environments I tried (see above): even when autoconf & co failed because of various version clashes or packages not found, the main advantage with GNAT is that it comes as a standalone package and as such, so far, quite portable. If anything, I'd say that the main rub here is at most in the sense that this has to be moved further even more & faster: the only chance that I currently see for any sort of reliable building process is with GNAT & full set of dependencies at the very least, ideally statically linked as well; we are not there yet (though some steps are done towards that, in particular for Cal3D, server components and client-core) and moving CS to this is going to take quite some time and effort.
From a structural point of view, there wasn't any direct input from S.NSA given that the originally planned consultation failed to materialise on time. As such, I didn't spend a lot of time re-evaluating the structure of the code base but at any rate, I don't see any specific problems with the current direction there. There is indeed a worryingly big amount of effort still required to get to the point of releasing the new client and thus moving on to next stage but this is unrelated to S.NSA as far as I can see. In terms of the code itself, the parts reviewed more closely are "sane MPI", the UDP lib, Serpent and FFA. As before, it's still the MPI part that I'm most uncomfortable with and that mainly because it's still a recovered artefact of dubious origin and with previously found holes and cockroaches. The UDP lib, Serpent and FFA did not reveal anything I didn't know about and I don't see any problem with them as they are currently on my Reference Shelf.
With respect to FFA Ch1-Ch19, I want to say that I'd rather put it already to use (even in parts if and where that fits) instead of waiting (as I've been waiting even while doing EuCrypt out of necessity) for the next steps and the eventual fruition of a FFA iron or similar. Essentially at this stage the part glowing red for me here is that I sunk some time and effort into FFA and so far S.MG did not directly benefit from it at all so the sane approach would perhaps be to move towards extracting already some benefit from it too. However, there is of course some cost attached now to taking this step of integrating & using bits and parts of FFA.
Mainly for the sake of not leaving stuff out, I feel compelled to add to this list the decision to use V for code released by S.MG so far (e.g. Eucrypt). Here as with FFA, my only concern is more to do with the stalling that seems to have happened for quite a while but that stalling is arguably part of a broader issue. At any rate, if there is something dangerous that I can see here is perhaps just the cumulative effect of all those useful parts that are stalled at one point or another: by the looks of it, S.MG ends up having to push or otherwise support the development of all of them and this is a matter I'd rather discuss in more detail at this stage.
There is of course the other starting point as well, namely the tech, going at it from code up as it were. It's possible and one can even go at it with an initial list of items that used input from Stanislav/S.NSA - though characteristically, it's easier to figure those out from my own Reference Shelf and notes than from anywhere else, his blog included. Nevertheless and especially in this case, I needed to... arm myself, there's no better word for it. Hence first listing the main practical requirements and only then looking at everything and aiming to discern value or lack of it with those hard requirements always in mind. ↩
Like ALL the code and all the machines, ffs already! ↩
There used to be such regular maintenance on Wednesday evenings, usually less than 10 minutes of down time. ↩
Especially on client side there are a LOT of dependencies but 1. those have nothing to do with S.NSA 2. they are ultimately players' concern although currently they have to count for S.MG too given the desired client release. ↩
Both Adacore's version and Ave1's. ↩
Comments feed: RSS 2.0
Re: your Serpent component -- in fact was from a public domain graveyard, and your analysis of it pre-dates mine.
Indeed, thank you. As you might have noticed, the scope is a bit wider here at any rate.
For my own future reference, the relevant S.MG board discussion: