A certain degree of frustration

Now on iteration…mmmmm….four, I think, of pushing IP v6 into CygNet, and am making invisible progress, I’d say.  That’s the kind where you seem to be doing a lot and accomplishing little of substance.  But, it leads to good situations like today, where I realized trying to keep the v4 infrastructure and shovel in the v6 isn’t going to be a good idea, even for a prototype.

Part of the problem is that CygNet is very nearly perfect in its architecture, in the sense that it works without requiring enormous computational overhead, and that it’s been pruned by expert code gardeners wielding sharp and precise tools.  There’s no fat, and there’s the source of one of my problems.  In many systems it’s possible to exploit of inherent inefficiencies in objects/classes/entities.  We don’t have those, in any meaningful way.

The other issue, and the one that’s been stymieing me is that the network world has changed.  When CygNet rolled out, most non-gateway(router) machines had a single NIC and a single address, which rarely changed.  Today, though, it’s hard to even define what “computer” or “host” means.  The research server has six IP addresses scattered across 3 physical NICs and 3 virtual (for VMware).  It has inward and outward facing names/addresses (frith.research.dom and research.cygnetscada.com).

It has at least 4 different copies (in 2 versions) of CygNet running on it: one on the main OS and the others on simultaneously executing VMs.

Now, you tell me, does it make sense to say of CygNet, “It’s running on the research server.”?  Well, yes, it does, if you’re willing to accept that “server” no longer means a physical computer, but instead refers to a logical locus of execution.  This is, I should point out, part of the premise of cloud computing.  Unfortunately for us, simply pushing CygNet onto v6 without any other changes wouldn’t accomplish much, in my current opinion.

And then there’s NAT: we already have problems with NAT, because NAT is the Wrong Thing, poorly implemented.  It broke the fundamental design of end-to-end connectivity upon which the ‘net (and CygNet) was predicated.

It’s not that we should stop pushing v6 into the product, but simply swapping out the v4 for v6 addresses isn’t going to teach us anything, and will cost us in the long run because we’ll need to come to terms with the v6 world and the coming distributed environments.

Architecture Notes

Imagine I wanted to run Cygnipede services on the Research server.  What I’m saying by this is that there is a business domain (Research) in which computing resources are [probably] available to execute “business” (logical) transactional activities.

Consequence:  rather than being host centric (and literally tied to a single IP address), a v6 CygNet could use a scope id to define a logical set of addresses from which services could be requested.  Changes to CygNet, beginning at the bottom (CAddressBytes()), the v6 changes need to accommodate a logical-locus-of-execution model.  Entities which currently use CAddressBytes() as a way to access services will need to move to using a new entity like “CLogicalDomain())”, which itself is a list (ideally dynamic) of CServiceHosts which are lists of 1 or more service/host names and corresponding addresses.  Note that IP is clever in that you can have multiple addresses associated with multiple names.

More later after I try some more mods to CAddressBytes().


Leave a Reply

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