The History of SLACi
The primary function and objective of the CaPSCi / SLACi Architecture have their origins in a programmable wedge device – a hardware PCB labeled only with the word ‘Doerr’. The ‘wedge device’ was connected between a user’s keyboard and its computer to perform routine keyboard tasks in Point-of-Sale applications.
TRON programmed that device to be positioned between a user’s keyboard and a Keyboard, Video and Mouse (KVM) Switch.
Remigius Shatas at Cybex Corporation coined KVM or specifically the term KVMS from the writings of Gary D Davis but he had insider insight. At the time, emerging ‘KVM’ switches allowed a user to have a single Keyboard, Monitor ‘and Mouse’ to operate up to eight computers.
The switch (also a wedge device) was required for various technical reasons detailed in a 1994 industry white paper co-authored by Gary Davis (Workcenter Corporation) and Anthony de Kerf (Tron International). In short, keyboard commands were used to switch between computers.
On a single switch with eight computers, it’s not much of an issue and you can reach buttons on the switch. But hardware design and moreover data center use cases were reaching 96 computers connected to the one monitor, keyboard and mouse.
Further, these users were not connecting the same brand of switches. They had to remember and use different keyboard commands depending on which switch the server they wanted to operate was connected to.
Solution: KVMSelect (the ad may still reside at NetworkWorld)
It was my first invention, said Anthony de Kerf, simple thinking outside the box. That keyboard wedge solved a big problem while improving the efficiency of user interaction with single touch switching to any server. It was an agnostic approach operating independent of KVM Switch brand(s). Users bypassed switching protocols getting directly to servers anywhere in the overall topology of interconnected switches.
But honestly, this was nothing compared to an inventive approach by Gary Davis. He created the very first multi-console KVM Switch topology in 1991 – again, by thinking outside the KVM hardware box. We were solving customer problems not trying to change the world, said Gary Davis. The two note industry leaders Cybex and Apex didn’t duplicate Gary’s architecture until 1995. It took others another three years.
KVMSelect was short lived but we discovered an astounding demand even as Cybex and Apex liberated the concept and continued a legal battle over the On-Screen-Display (OSD) system implemented to mimic KVMSelect.
Markets were evolving and so was the KVM technology so de Kerf responded by creating the Three Tier Topology . Using those OSD systems, TRON was managing connections between massive numbers of users and servers on a common {secure} infrastructure.
The user:server numbers established by Tron’s topology were far greater than what manufacturers marketed and the ‘only way’ to reach the number of device KVM producers claimed to support. The architecture supported more than 200 user consoles (what Tron called user sessions) and over 10,000 severs. The first deployment on a scale this large was based on a design for Intel under use case specifications defined by Jeremy Murtishaw.
The three tier approach took an out of the box approach by deploying a tier of KVM switches as ‘network routers’. As a middle layer of hardware this tier interconnected an upper and lower layer of switches with users (top) and servers (bottom). User session throughput is determined by the switch matrix (i.e.: 4×8, 4×16 up to 8×32).
Tron’s three tier architecture supported 256 user sessions with more than 10,000 severs but the OSD in modern KVM switches supported less than 1000 entries. The first software version of what became SLACi was developed at Tron to manage the large number of servers made possible by the three tier topology.
The initial digital KVM switches also hit a snag with mouse operation on Windows servers. Microsoft used two difference mouse drivers between the login screen and the desktop. Mouse operation through a digital KVM switch was often erratic leaving users with difficult and often unmanageable mouse controls when accessing different servers.
Tron customers demanded an immediate solution so de Kerf developed a software application called ReMO. Its function was simple and proved to be invaluable to early digital KVM users! Users pressed a combination of keyboard keys to interfaced directly with system settings for mouse speed based on the OS and screen settings.
In late 1998 on the eve of writing a second edition of the industry’s technology white paper’s, Davis & de Kerf devised methods and techniques for video compression on a computer network. Years later de Kerf with the help of David Wittenkamp confirmed compression rates starting at 1000:1.
It was a difficult time to fund hardware so the operating software (SLACi) would be the best way to market and ultimately fund hardware development. While markets for that ‘I/O network’ is believed to survive today, the hardware portion has since been abandoned in favor of the software.
SLACi for data center users addressed a hybrid of digital and analog switches joined with other types of remote sessions (SSL, TSL, terminal and remote console, etc.). An added challenge was a variations in the many types of data center operation and a host of users, network administrators and software developers who all own and manage different pieces of server operation.
The bigger problem was authorities, identifying who owned what, when, why and where to find applicable stakeholders at any given moment (usually an IT emergency) while managing “server-to-user routing” (a push method in contrast to the user pull approach).
In addition, you had to know how hard the fault was. This determined authentication requirements and whether users needed access to Remote Desktop or a console, did they need KVM access or perhaps a telnet session via a specific network port. The original SLACi data center software solved all those challenges and more . . .
The SLACi patent process was long and arduous. Before patents were finally issued de Kerf discovered real estate industries suffered similar challenges in connecting users, technologies and data. The bigger challenge would be stepping outside the closed loop operating environment of KVM switches. Research ensued and concepts defined within SLACi were applied to support the broad diversity and fragmentation of data, stakeholder and technology interests in the industry.
The concept of agnostic was essential to both user and industry acceptance. Users expressed high utility and affordability as important factors to adoption across a variety of specialties. Recognizing the source and flow of data, how, why and what’s ingested by different stakeholders and purposes was critical to establishing a foundation on which diverse user technologies could emerge fully capable of communicating autonomously.
The technologies ultimately selected to develop a solution for real estate weren’t available during initial research so form and fashion has taken on some interesting approaches between introduction and industry adoption. Today as technologist we’re focused on data quality, reliability and accessibility requirements of going forward with AI for targeted use cases in real estate.
Over many years SLACi evolved into a software infrastructure called CaPSCi that identified development of property, the construction or build thereof as the origins of all related data and center of continued operational process, workflows and data accumulation. CaPSCi was designed to allow property, management and AEC technologies to evolve around data and service provider ecosystems without affecting the property, its data or the investment.
Jeremy Mutishaw’s subject matter expertise as a user and network infrastructure professional provided key insight when developing original versions of SLACi for the data center. Gary Davis provided market knowledge, design strategy and support defining the specifications that were patented. David Wittenkamp guided development of the first smart software interface for KVM switch operation – SLACi’s proof-of-concept.
Since the original SLACi efforts, both Gary and Jeremy continued to contribute in ways they may not have been aware of at the time. That support and their growing expertise facilitated the transition of SLACi concepts to CaPSCi connecting users and technologies to data in AEC, build, the operation and management of property.