A virtual network interface approach for end-host operating systems

This review focuses on a research paper that examines how network applications and operating systems interact. [1] The researchers argue that operating systems cannot control traditional computer networks or hold them accountable. The researchers then demonstrate potential problems and their solution – a virtual network interface (VIF) approach for end-host operating systems [1].
This report does not go through details on how to implement and validate the usage of VIF. Instead, it tries to present the researchers’ concepts for building a layered operating system that provides network applications with more efficient performance. To make this research easier to understand, this paper first discusses existing problems in network control. Then, it illustrates the proposal for solving network control problems.
While today’s operating systems serve standalone computers and networks, the operating systems do very little to differentiate between them, the researchers say. As a result, operating systems often fail to process network information in the most efficient way. Like the authors say, “Most of the work in this area remains domain-specific and without a general scheme for providing network controls as an OS service.” Figure 1 (a) illustrates the inefficient process involving a network and an operating system. Each Virtual Machine (VM) directly talks to network interface (cylinder at bottom). Suppose 10 concurrent users access this network interface, and the OS provides no way to control them. This means, among other things, low-priority jobs may occupy resources before high-priority jobs. For example, on a Web server, some requests only need an HTTP process with low resource allocation, but the operating system’s network control may erroneously assign them a high-streaming process. The poor assignments dramatically degrade network performance.
Takashi Okumura, Daniel Mosse, Masaki Minami, and Osamu Makamura [1] propose a virtual network interface for solving these problems. Figure 1 (b) illustrates a virtual interface between VM and a network interface. Each VM has its own process interface (cylinder at bottom of each VM). These virtual interfaces determine who and what to do with each process based on the request of network. The virtual interface allocates a HTTP process request if it detects a low-level request. Similarly, the virtual interface allocates a streaming-dedicated process if the coming signal is a high-level request. The VIF finally transfers each customized process to the network interface. Instead of responding with a common process for each request, the network interface allocates a different process for each request. This methodology greatly improves resource allocation.


(a) (b)
Figure 1: Conceptual Overview of the Mechanism [1] Page 3 Fig.1

Thomas [3] presents another system called GLUnix. GLUnix is a layered operating system, which supports a network of workstations. He says, “GLUnix was designed to provide transparent remote execution, support for interactive parallel and sequential jobs, load balancing, and backward compatibility for existing application binaries.” There are two types of process in the network system: sequential and parallel. The sequential process is a list process instances executed in an order. The parallel process is a collection of process instances executed concurrently. GLUnix provides a user-level layer to manage these processes successfully. First, it extracts the interactive sequential and parallel processes through intelligent job placement. Second, it groups these processes as two individual processes. Finally, GLUnix sends these two processes to network system. Because GLUnix builds the processing strategy, the network system does not need to figure out which processes need to execute in sequential or parallel mode. Instead, it just executes them. This greatly reduces communication traffic between network and operating system. GLUnix consists of three components: a per-cluster master, a per-node daemon and a per-application library. GLUnix master primarily focuses on job placement. GLUnix daemon is a listener for the master, gathering and detecting each node’s performance information and sending feedback to the master. GLUnix library provides a GLUnix service interface for processing users’ requests. Thomas emphasizes that GLUnix works very well on sequential and parallel jobs placement.
The interesting thing is that although both VIF and GLUnix implement the layered interface solution to address the network control issues, their approaches and targets are different. VIF helps to solve process optimistic issues, which means it allocates the most economic resource for each process request. The GLUnix daemon acts as the process listener, providing centralized management of processes. This management makes it possible for the GLUnix system to dramatically improve the performance of interactive sequential and parallel programs because all processes are ready to execute.
This author agrees that the layered network interface is an easy and effective way to solve operating system support network control problem, but VIF may create problems. For example, consider what happens when VIF receives 10,000 requests simultaneously. The VIF interface provides 10,000 instances to process these requests. In other words, the more requests sought, the more instances created. Of course, all of these instances greatly impact the system resource allocation and memory-leaking might occur.
In conclusion, this paper reviewed two ways a system might provide a layered system interface to give operating systems better network control. One methodology called VIF provides request specified process layer to fulfill network control. The other methodology called GLUnix provides a different layer proposal – the listener, which provides an intelligent process interface.


Reference:
1. “Operating System Support for Network Control: a virtual network interface approach for end-host OSs” Takashi Okumura; Daniel Mosse; Masaki Minami; and Osamu Makamura; 2002.
http://www.asahikawa.wide.ad.jp/taka/research/iwqos2002.pdf
2. Modern Operating Systems, 2nd Edition, Tanenbaum, Andrew S., Prentice Hall, Upper Saddle River, N.J., 2001, pages 867 -897.
3. “GLUnix: Layered Operating System Support for Network of Workstations” Thomas Anderson; 1996-1997.
http://www.ucop.edu/research/micro/96_97/96_006.pdf

This paper focuses on developing componentized systems software and how to build systems software which solve complex problems but which is both easy to configure and robust. This paper provides an overview of two implementing approaches: Knit toolset and OOP components linking strategy.
Alastair, Matthew, Leigh, Jay and Eric (2) introduce a new module language and toolset for managing systems components called Knit. Knit is based on units, a model of components in the spirit of the Mesa and Modula module languages. Knit provides features useful in the design and implementation of complex operating systems on Unix machine.
Based on Alastair, Matthew, Leigh, Jay and Eric’s discussion, Figure 1 illustrates the Knit linking model atomic units, which a system can link together to form compound units. A compound unit contains a set of imports (the top part of the outer box) that can be propagated to the imports of units linked to form the compound unit. The compound unit explicitly specifies exports and imports are to be propagated. Because all connections are explicitly specified, arrows can connect import and exports with different names, allowing each unit to use locally meaningful names without the danger of clashes in a global namespace. The imports of the linked units that are not satisfied by imports of the compound unit must be satisfied by linking them to the exports of other units within the compound unit. The example in Figure 1 links the previous example unit with another unit that logs requested URLs. The original serve web function is wrapped with a new one, serve_logged, to perform the logging. The resulting compound unit still requires serve_file and serve_cgi to be provided by other units, and also requires functions for manipulating files. The compound unit’s export is the logged version of serve_web.


Figure 1: A compound unit

An alternate way of implementing components linking in Windows operating system is to use an object-oriented language or framework. In this approach, the links among components are defined by arbitrary code that passes object references around. This is the view of components implemented by object-based frameworks such as COM. Figure 2 shows a common visual representation of a software object: Everything that the software object knows (state) and can do (behavior) is expressed by the variables and the methods within that object. The object’s variables make up the center, or nucleus, of the objects. Methods surround and hide the object’s nucleus from other objects in the program. This conceptual picture of an object – a nucleus of variables packaged within a protective membrane of methods – is the ideal that designers of object-oriented systems strive for. Linking with objects includes specific linking instructions that connect each object’s global variables to its sharing nucleus. Symptoms of misusing objects as components include the late discovery of errors, difficulty in tracing the source of link errors, a performance overhead due to virtual function calls, and a high programmer overhead in terms of manipulating reference counts. Code for linking components is intermingled with regular program statements, making the code difficult for both humans and machines to analyze. Even type checking is of limited use, since object-based code uses many dynamic type checks (i.e., downcasts) to verify that components have the expected types, and must be prepared to recover if this is not so. These problems all stem from using a dynamic mechanism (objects) to build systems in which the connections between components change rarely, if ever, after the system is configured and initialized.


Figure 2: Object-Oriented Framework

Both Knit and Object-Oriented Framework systems provide a method for components in an efficient way. The Object-Oriented approach start with object files that are linked to create the program. It allows programmer to provide the collection of files to the linker as a package of objects. This makes grouping components more flexible. However, it reduces the operating system performance. Knit gives a better solution on the components multi-implementation on the same interface, but programmer has difficulties on the future linking changes. Because all units are linked to each other explicitly, whenever a component changed, the whole system links need to be re-evaluated, if some cases, they must re-link.
In conclusion, Knit brings strong analysis and optimization techniques to bear on componentized systems software. It helps to detect deadlocks and unsafe locking, reduce abstraction overheads and flatten layered implementations. All of these tasks require the well-defined component boundaries and static linking information. Object-based component language provides better help to the programmers in ensuring that components are linked together properly. Objects are essentially reusable software components that model items in the world. Object-oriented programs are often easier to understand, correct and modify.
 

The Age of Spiritual Machines: When Computers Exceed Human Intelligence

When I first time heard the book, I just felt that this is probably another theory book. However, after starting to read it, things changed. I finally liked it. "The Age of Spiritual Machines" is destined to become one of the more important books of the late 20th Century.

Kurzweil has ratcheted up the human-versus-artificial intelligence debate a few notches. There will, he makes clear, be no human intelligence versus artificial intelligence. Our computers and we will become one. "There is a plethora of credible scenarios for achieving human-level intelligence in a machine," writes Kurzweil. "We will be able to evolve and train a system combining massively parallel neural nets with other paradigms to understand language and model knowledge, including the ability to read and understand written documents."

Kurzweil’s own law of accelerating growth and return is centered on the idea that this new bio-digital species becomes increasingly learned and sophisticated, life will become more orderly and efficient, while technological development continues to accelerate. Kurzweil’s premise – that computers will become as smart as we are and then merge their intelligence with ours -- is not only challenging and provocative; it also makes sense. But he isn’t as clear or coherent when it comes to divining just what kind of intelligence computers will have – how intuitive they can be, how individualistic or ethical.

By the second decade of the next century, there will be reports of computers passing the Turing Intelligence test, says Kurzweil. The rights of machine intelligence will become a public policy issue. But machine intelligence will still largely be the product of collaborations between humans and machines, computers still programmed to maintain a subservient relationship to the species that created them.

Where his book and his vision stumble is in grasping what will happen to us when computers become smarter than we are, then sensual, social or spiritual. Will we better off? Will the computer be moral? Will it have a social or other consciousness? Do we wish to merge with computers into one species? Will we have any choice? We could be heading for a sci-fi nightmare or, alternatively, for another of those utopian visions that used to pepper Wired magazine before it became the property of Conde Nast. While futurists can measure or plot the computational skills of tomorrow’s computers, can anyone really know the precise nature of that intelligence, and whether or not it can replicate the functions of the human brain?

The idea of our being outsmarted, thus dominated and endangered by computers, has been portrayed as a nightmare in Stanley Kurbrick’s "2001" (Kubrick apparently greatly underestimated the virtual person Hal would become). It’s also surfaced in various rosy intergalactic Disney-like visions in which machines perform labor, clean the air, heal humans, teach kids. Kurzweil doesn’t say which notion, if either, sounds more plausible.

The latter half of the book becomes essentially a time-line: Kurzweil somberly walks us through the evolution of computing intelligence, and the eventual merging of digital technology and human beings into a new species.

By 2009, Kurzweil predicts, human musicians will routinely jam with cybernet musicians. Bioengineered treatments will have greatly reduced the mortality from cancer and heart disease. But human opposition to advancing technology will also be growing, an expanding neo-Luddite movement.

By 2019, nonetheless, Kurzweil predicts that computers will be largely invisible, embedded in walls, furniture, clothing and bodies – sort of like the artwork in Bill Gates’ massive new mansion. People will use three-dimensional displays built into their glasses, "direct eye" displays that create highly realistic, virtual visual environments that overlay real environments. Paraplegics will routinely walk and climb stairs through a combination of computer-controlled nerve stimulation and exoskeletal robotic devices. This display technology projects images directly onto the human retina, exceeds the resolution of human vision, and will be widely used regardless of visual impairment.

By the year 2099, a strong trend towards the merger of human thinking with the world of machine intelligence that humans created will be underway. There will no longer by any clear distinction between humans and computers. Most conscious entities will not have a permanent physical presence. Life expectancy will no longer be a viable term in relation to intelligent beings.

Small wonder Kurzweill expects a growing discussion about the legal rights of computers and what constitutes being "human." Direct neural pathways will have been perfected for high-bandwidth connection to the human brain. A range of neural implants will be available to enhance visual and auditory perception, machine-generated literature and multi-media material.

There are some things I dislike: He takes Roger Penrose seriously, he fails to mention Racter in the discussion of computer authors, and he spends just a wee bit too much time tooting his own horn (Kurzweil Computer Products, Kurzweil Reading Machine, Kurzweil Data Entry Machine, Kurzweil Music Systems, Kurzweil Applied Intelligence, Kurzweil Education Systems, Ray Kurzweil Cybernetic Poet...) But to be fair, he HAS pioneered in all these areas, so perhaps he has earned his immodesty.

Overall, a fascinating, thought-provoking book which is not afraid to make concrete predictions. Given Kurzweils track record, he may just prove to be 100% right.

References
Ray Kurzweil, (1999) The Age of Spiritual Machines
Miastkowski, S. (1999) ‘Voice Xpress 4 eases training’, PC World, May.
Winograd, T. and Flores, F. (1986) Understanding Computers and Cognition, Norwood NJ, Ablex.
Winograd, T. (1985) ‘Moving the semantic fulcrum’, Linguistics and Philosophy, 8(1): 91-104.
The Age Of Spiritual Machines: How We Will Live, Work And Think In The New Age Of Intelligent Machines.
http://norlonto.net/index.cfm/action/reviews.view/itemID/15/type/rvwsBooks#top

This paper focuses on the Unified Modeling Language (UML) deployment diagram, a static view of the run-time configuration of processing nodes and the components that run on those nodes. It shows both hardware and software partitioning.
Page-Jones (2001), Ambler (1999) and Eyrolles (1997) agree that the deployment diagram focuses on a system’s infrastructure nodes, depicting system components, objects and the physical arrangement of run-time computational resources. But each author chooses to emphasize different things when implementing a deployment diagram
Page-Jones notes that the deployment diagram is roughly equivalent to the architecture --interconnect or architecture -- flow diagram. He focuses on associations between nodes that represent communication paths and the associations that have stereotypes to distinguish different kinds of paths. He says that a cube represents each hardware resource, showing the physical presence of the equipment within the system. A few deployment diagrams can describe any system. Lines connect the nodes in the deployment diagram to each other and solid lines indicate communication connections between nodes. Stereotypes, indicated with <> notation, are a UML mechanism for extending the modeling language by defining common types appropriate to the problem domain. Figure 1 shows the mapping between the nodes LCD Display and UI Processor to their physical architectural representation.


Figure 1. Illustrating the use of stereotypes in a deployment diagram

Eyrolles views the deployment diagram in much the same way as Page-Jones, but Eyrolles dedicates more discussion to node -- the node classes and node instances. He says the graphical difference between classes and objects is that objects names receive underlining and class names do not. Physically nesting the object symbol inside the node symbol shows the presence of an object on a node and the object symbol may contain the tag location.
Both Page-Jones and Eyrolles concentrate on explaining of nodes. Eyrolles gives more details on nodes association, but both authors ignore the nodes relationship on dependency, generalization and when a software engineer needs to create the deployment model.
Ambler provides the broadest and most accurate material on deployment diagrams, including Page-Jones and Eyrolles’ ideas. He also covers dependency, modeling tips and how to determine whether a system needs to apply the UML deployment model in the software process stage. Many software engineers are happy using the core UML diagrams; such as class, use-case, state and collaboration. But Ambler gives special attention to the deployment diagram, even though it usually gets little attention.
Besides Page-Jones and Eyrolles’ ideas, three suggestions on how and when to apply UML deployment diagrams throughout the software process that Ambler proposes.
First, Ambler discusses node dependencies, the connections between two components (sometimes through interfaces). Dotted lines with arrowheads show dependencies between nodes.
Second, software engineers need to determine whether a project needs to create the deployment model?
This is a common question for software engineers who are in charge of the UML modeling process. It’s very clear that the software engineers must implement UML core diagrams, but what about the deployment diagram and the component diagram? When? Why? Ambler presents a simple way to answer these questions. Ask and answer the following question: If a software engineer know nothing about the system and someone asks him to either install or maintain it, would he wants a description of how the system’s parts fit together? If the answer is yes, Ambler says develop a deployment diagram. Ambler’s practice shows that deployment modeling is well worth it -- deployment models force software engineers to think about important deployment issues long before they must deliver the system.
Third, software engineers should perform the deployment modeling early in the project’s life cycle and update it throughout the project as needed. Ambler says, deployment is a difficult process that software engineers should start early in the life cycle, the process begins with requirements definition during the Inception phase, continues with deployment modeling and deployment planning during the Elaboration and Construction phases, and lead to deployment of the system workflow starting late in the project life cycle. He says that deployment modeling is a key component of the deployment workflow and incorporating the UML deployment diagram into system development efforts will increase the chances of delivering the system successfully.
As a result, deployment modeling and the deployment workflow are an important part of system development models.
Based on Ambler’s discussion, Figure 2 depicts a UML deployment diagram for a university administration system. This figure depicts how software engineers deploy major software components into the production environment, enables the project team to identify its deployment strategy.



Figure 2. A Project-Specific UML Deployment Diagram
In conclusion, three authors suggested that the deployment diagram shows run-time architecture of processors and devices, and visualizes the configuration of physical processing elements and the software components that execute on the processing elements. The first two authors emphasize on how to implement the deployment diagram, and the third author emphasizes how and when software engineers need to apply the deployment diagram in the software process stage. This researcher believes that Ambler’s deployment diagram explanations give a fuller and clearer picture of a system than the methods of other authors. The deployment diagram is an important model for increasing the chance of successfully delivering system.