A client-server architecture for modern times

Client-server computing (Maffeis 2003) at its zenith in the 1990's (Sinha 1992) provided rich and diverse technology on both sides of the wire. Clients had the ability to perform literally any operation. Code could be written in any language on either side, and the decision of where to deploy a component could be changed easily to optimize performance. However, this version of client-server computing never fully reached its promise due to two concerns: 1) corporate IT departments struggled with deploying rich clients, patching them with updates, and upgrading them uniformly and 2) a lack of security standards meant that the great power of clients also represented a potential threat from malware, and even from simple programming errors. The rise of the World Wide Web brought a standard client: The web browser, which allowed Javascript code to be deployed seamlessly to clients. Version compatibility between client and corresponding server could easily be maintained, and standardized browser "sandboxes" (Prevelakis and Spinellis 2001) mitigated many security concerns. However, early implementations of the Javascript runtime suffered from both performance and capability limitations, though these limitations have been mitigated greatly over time. Nonetheless, the security restrictions of the browser sandbox represent a significant limitation on work that can be done on the client side. For example, an application that requires client-side system calls simply cannot be written fully in Javascript. Furthermore, Javascript applications currently lack support for threading, the ability to offload work to GPUs, and other performance innovations. Finally, for many developers, Javascript is an "acquired taste" at best. Software developers should be free to work in the languages and frameworks they commonly use for server applications and stand-alone applications such as C, C++, Java, C#, or Python. We revisit the original client-server paradigm, but with a modern improvement: advances in containerization can be used to solve the deployment issue. We consider an architecture in which an extended web protocol allows servers to provide a container to the client that is version-compatible with the server. Further, since the container has all necessary dependencies, the client software within can be written in any language. Architects can move components between client and server container images to address performance and convenience as needed. We include a security negotiation phase in the protocol, so that clients can limit the capabilities of the client-side container as desired. Finally, we compare the performance, capabilities, and security of sample browser-based client-server applications with analogous fully container-based applications.

Name thesis:degree_name

Ph. D.

Level thesis:degree_level

Doctoral

Discipline thesis:degree_discipline

Computer science (MU)

Grantor dc:publisher

University of Missouri--Columbia

Year dc:date.issued

2024

Author dc:creator

• Ries, James Edward

Advisor dc:contributor.advisor

• Scott, Grant

Language dc:language.iso

eng, English

DOI

https://doi.org/10.32469/10355/104732

OAI identifier oai:identifier

oai:mospace.umsystem.edu:10355/104732