Chat applications are available on many computer platforms. We present a novel chat application on a bare Internet using bare PCs. In a bare Internet, which is overlaid on and coexists with the Internet, all computing devices are bare, meaning they have no operating system and no persistent storage. We describe the design and implementation of the chat application and use it to conduct preliminary tests on the Internet. The results show the feasibility of a bare Internet. Our contributions include a simple chat design, a closed system approach, a bare Internet architecture, context-based user authentication, security by design, server-controlled chat sessions, and extensibility to other application domains. This work lays a foundation to build other domain-specific applications on a bare Internet.

Obsolescence and its impacts on software and systems continue to be of interest. Reducing obsolescence in operating systems and microprocessors will help to reduce software obsolescence. We examine obsolescence in Intel microprocessors and Windows operating systems. We first present data that illustrates the extent of the problem. We then consider extensible designs to reduce obsolescence in operating systems and microprocessors. This approach can be adapted to design software and hardware that are resilient to obsolescence.

Over the years, operating systems (OSs) have grown significantly in complexity and size providing attackers with more avenues to compromise their security. By eliminating the OS, it becomes possible to develop general-purpose non-embedded applications that are free of typical OS-related vulnerabilities. Such applications are simpler and smaller in size, making it easier secure the application code. Bare machine computing (BMC) applications run on ordinary desktops and laptops without the support of any operating system or centralized kernel. Many BMC applications have been developed previously for single-core systems. We show how to build BMC applications for multicore systems by presenting the design and implementation of a novel UDP-based bare machine prototype Web server for a multicore architecture. We also include preliminary experimental results from running the server on the Internet. This work provides a foundation for building secure computer applications that run on multicore systems without the need for intermediary software.

We consider the design and implementation of a bare PC Web server with no OS or kernel running on a multicore architecture. Previous work has demonstrated initialization, loading and running of a 32-bit web server on a single core in a multicore configured system. The main design issues that need to be addressed are balancing the load, designing re-entrant code, enforcing concurrency control, partitioning network logic, sharing the network interface and designing multi-tasking execution. We describe a novel bare PC Web server architecture and design for addressing these issues. We also provide initial performance measurements that demonstrate the feasibility of this architecture and its implementation. It is shown that with this design and implementation, the main bottleneck impeding multicore parallelism is using a single Ethernet card in the system to handle multiple cores. This work serves as a basis for identifying issues that may exist in other networking and multicore configurations for a bare PC Web server.

With the increasing adoption of high bandwidth 802.11ac technology by mobile devices in the future, significant improvements performance are anticipated. However, many mobile devices are currently equipped with 802.11n network cards, and a large base of already deployed access points only support 802.11n. We conducted experiments to measure the performance of mobile devices in a 2.4 GHz 802.11n LAN. We used the 2.4 GHz band since most 802.11n networks use this band (802.11n networks can also use the less interference-prone 5 GHz band). Our results indicate that 1) there is high variability in the performance of mobile devices even in an interference-controlled environment with no congestion in the wireline network; and 2) higher performance loss does not always correspond to a higher level of congestion in the wireline network. Packet analysis reveals that the performance variability and performance reduction are primarily due to media access delays and the overhead due to retransmissions on the wireless link. This study shows that regardless of the gigabit capabilities of future 802.11 hardware, inherent characteristics of the shared wireless medium and the 802.11 MAC layer access mechanisms will limit the performance gains of mobile devices even under ideal conditions.

Split-protocol computing paradigm uses web services on geographically distributed Web servers. A network of large Split-servers that form the cloud to handles computing and storage task that would otherwise create a heavy CPU utilization for the traditional individual server. The split-protocol concept was devised for load balancing and faster data transmission. Connection and data communication phases are clearly divided between servers without involving the client or the central controlling mechanism, like a dispatcher or a load balancer. In an earlier paper, we demonstrated that the application Split-protocol produces higher performance compared to traditional clusters. Based on the need, different types of split configurations are implemented for throughput, response time, and connection time. The observed throughput improvement was within the range 6.5% - 25% over non-split systems. This paper first time examines the empirical results of Split-system to understand its analytical behavior and compares with traditional non-split systems. Also, this paper prepares the groundwork for the scientific understanding of Split-systems. The split-system technique with given sets of constraints can produce better throughput than conventional equivalent server systems. The performance improvement resulted because of the Split-system operates as a fine-grained pipeline of the parallel system.

Developing device drivers is often tedious and error-prone. Drivers for bare machine applications that run without an OS have been previously written by directly using specification documents. Transformation is an alternate approach that attempts to develop a bare machine driver by using existing code for an OS driver. We investigate the transformation of a Broadcom Linux 802.11n wireless device driver to a bare machine driver. As a first step towards understanding the transformation, we study the functions and OS dependencies of the Linux driver. The driver module is analyzed by examining its interaction with other modules, providing details of its key elements and code sizes, and by comparing code sizes with its counterpart Windows driver. We also discuss design issues that will be useful for developing device drivers that are independent of any operating system, kernel, or embedded system.

Computer science, information systems, information technology and other related programs have been evolving over the years to prepare students for the ever changing work force or to become research scientists. These program structures and curriculum gets updated rapidly even before a student had a chance to complete a four year cycle. When a student graduates, there may be a daunting challenge to find a right fit for a right job in todayâ??s global market. This paper proposes a revolutionary curriculum paradigm that is based on sound engineering principles and need for applied education. The curriculum proposed here is based on student needs and industry outlook. It reduces educational cost for students, administrative cost for teaching institutions and training cost for industry. It also provides a first cut of curriculum that integrates a variety of disciplines under the information technology umbrella. The curriculum taxonomies are shown to illustrate the proposed concept. An initial road map and time schedules are shown to demonstrate the feasibility of this concept. The roles of students, faculty and industry supervisors are discussed. The approach proposed here will have a broader positive impact in information technology when adopted. Further research is needed to fully exploit the proposed concept

We study the performance impact of recently recommended TCP retransmission timer settings using a bare PC Web server with no operating system or kernel running in the machine. We first evaluate server performance in a test LAN with various settings of the alpha and beta constants used for computing SRTT and RTTVAR in the presence of varying levels of background traffic generated by conventional systems. We then study performance with different minimum RTO settings, and compare the performance of the bare PC Web server using the recommended timer settings with the performance of the Apache and IIS Web servers running on Linux and Windows respectively. We find that (1) no combinations of alpha and beta, or sampling strategies, perform consistently better than others under the different levels of background traffic; (2) lower minimum RTO settings than the recommended 1- second minimum will work when there is moderate background traffic, but the 1-second minimum is best when there are higher levels of congestion; and (3) using the standard timer settings but not using the TCP SACK option and congestion control mechanisms degrades bare server performance for some levels of background traffic.

Protocol splitting has been used to enable protocols to be split at a server level without client involvement. We describe a novel split protocol client/server architecture that completely separates connections and data transfers within a typical session. In this approach, a client becomes aware of its multiple server sources and communicates with them using their IP addresses. Specifically, a client makes a single TCP connection to a connection server and subsequently communicates with one or more data servers to obtain its data and close the connection. We also conduct experiments and measure performance to demonstrate the feasibility of this architecture. Our results indicate that scalable server cluster configurations can be built using this approach. The proposed architecture simplifies server implementations, avoids traditional load balancing techniques, and isolates clients from data servers. It also results in a scalable and distributable approach to client/server computing that provides an alternative to the current paradigm.

HTTP request splitting is a new concept where the TCP connection and data transfer phases are dynamically split between servers without using a central dispatcher or load balancer. Splitting is completely transparent to the client and provides security due to the inaccessibility and invisibility of the data servers. We study the performance of mini Web server clusters with request splitting. With partial delegation in which some requests are split, throughput is better, and response times are only marginally less than for an equivalent non-split system. For example with partial delegation, for a four-node cluster with a single connection server and three data servers serving 64 KB files, and for a three-node cluster with two connection servers and a single data server serving 4 KB files, the respective throughput improvements over non-split systems are 10% and 22%, with only a marginal increase in response time. In practice, the throughput improvement percentages will be higher and response time gaps will be lower since we ignore the overhead of a dispatcher or load balancer in non-split systems. Although these experiments used bare PC Web servers without an operating system/kernel for ease of implementation, splitting and clustering may also be implemented on conventional systems.

We describe a Webmail server that runs on a bare PC without an operating system (OS) or kernel, and give details of its architecture, design, and implementation. We also present the results of experiments conducted in a test LAN environment to compare performance of the bare PC Webmail server with conventional Webmail servers Atmail and Mailtraq running on Linux and Windows respectively. Performance is evaluated by measuring the processing time for login requests; inbox requests with a varying number of emails; and composing or retrieving email messages and sending attachments of various sizes. We also measure the throughput for various sizes; and, under stress conditions, the processing and response times with a varying number of connections, and the total and average processing times for the POST command with a varying number of users. The results show that the performance of the bare PC Webmail server is significantly better than that of the OS-based servers. The bare PC Webmail server is an alternative to conventional Webmail systems, and its architecture and design features could be used as a basis for developing future high-performance systems.

Bare Machine (bare) email servers, which run on an ordinary PC without any commercial operating system, kernel, or other centralized support, have been shown to outperform conventional email servers that require an operating system (OS). The absence of an OS allows implementation of an email server that is lean and efficient, and able to reduce the usual communication overhead by intertwining the server application with the necessary network protocols. We identify critical points with respect to performance on a bare email server, and compare the associated internal timings with those for Java-based email servers with equivalent functionality running on Linux and Windows respectively. The results provide insight into email server operation at a protocol level, and explain the performance gains due to intertwining in the bare email server implementation. It is seen that bare email servers perform better than the OS-based servers at both the application level and the protocol level. Internal timings associated with critical server operations provide a useful means for comparing bare machine servers and their OS-based counterparts.

We compare VoIP performance on IPv6 and IPv4 LANs in the presence of varying levels of background UDP traffic. A conventional softphone is used to make calls and a bare PC (operating systemless) softphone is used as a control to determine the impact of system overhead. The performance measures are maximum and mean delta (the time between the arrival of voice packets), maximum and mean jitter, packet loss, MOS (mean opinion score), and throughput. We also determine the relative frequency distribution for delta. It is found that mean values of delta for IPv4 and IPv6 are similar although maximum values are much higher than the mean and show more variability at higher levels of background traffic. The maximum jitter for IPv6 is slightly higher than for IPv4 but mean jitter values are approximately the same. On an overloaded 100 Mbps link, packet loss can reach close to 18% for IPv4 and 24% for IPv6, and the MOS degrades significantly. At moderate levels of background traffic, the IPv4/IPv6 throughput ratio is close to the ideal (theoretical) throughput ratio, but at high levels of background traffic, throughput for IPv6 declines slightly faster than for IPv4. In general, our results indicate that the difference in VoIP performance for IPv6 and IPv4 is negligible. Results for the bare PC softphone confirm that reducing system and application overhead lowers delta and jitter values regardless of the IP version.

Bare PC applications do not use an operating system or kernel. The bare PC architecture avoids buffer copying, minimizes interrupts, uses a single thread of execution for processing network packets, and incorporates novel scheduling to minimize CPU utilization. We design a bare PC Web server that can serve both dynamic and static content. Measurements of response time, connection time and throughput for workloads containing requests for dynamic and static content indicate that the server has better performance than the Apache and IIS Web servers. For example, the bare PC server has a maximum request rate that is twice that of the Apache and IIS servers when serving dynamic content for small dataset sizes. Furthermore, at capacity the CPU utilization of the bare PC server is 1/5ththat of the other servers. The bare PC server can also sustain a higher maximum request rate for dynamic pages with a given request rate for static pages. The studies demonstrate that the performance of the bare PC server when serving dynamic content is limited only by the latency of the database server.

The Secure Real-Time Transport Protocol (SRTP) is an Internet standards-track security profile for RTP used to provide confidentiality, integrity and replay protection for RTP traffic. We study the performance of SRTP when it is used to secure VoIP conversations. Experiments are conducted using snom and Twinkle softphones running on Windows and Linux platforms respectively and a bare PC softphone running with no operating system installed to provide a baseline. Pre-defined SRTP transforms based on AES counter mode encryption with a 128-bit key and HMAC-SHA-1 with a 32-bit authentication tag, as well as 192 and 256-bit AES keys and an 80-bit authentication tag are tested. Measurement of internal processing times for each operation in the SRTP protocol indicates that authentication processing is more expensive than encryption regardless of key or tag size. A comparison of jitter and delta (packet interarrival time) for secured and unsecured VoIP traffic reveals that the addition of SRTP protection to VoIP traffic over RTP has a negligible effect on voice quality. VoIP throughput with SRTP is about 2% more than with RTP alone since the insignificant increase in delay is offset by the small increase in packet size.

Bare machine applications run directly over the hardware without using an operating system or a hard disk. This paper studies the performance of a bare machine email server whose design and implementation is based on several novel architectural features with a view towards optimizing performance. The results are compared with those for the AxiGen and ShareMailPro email servers, and a lean Java-based email server prototype running on Windows whose application-level operation closely matches that of the bare machine email server. For 80,000 emails in a LAN environment, the bare Machine server processing time is approximately 2 times faster than a Java-based server, and 2.4 times faster than the AxiGen server. For 5,500 emails in a WAN environment, the bare machine server performed at least 1.8 times faster than the Java-based and ShareMailPro servers. The results indicate that the bare machine email server outperforms the conventional email servers in LAN and WAN environments, and demonstrate the capability of using bare machines to build high-performance email servers.

We present a bare PC Web server design that runs on any Intel 386 based PC without any hard disk and other supporting software. This server design is based on simplicity and minimal functionality. We identify design issues related to such server and provide our preliminary performance measurements in comparison with IIS and Apache servers. We have found that our Web server performs comparable to commercial servers and it can be enhanced to perform even better when it is optimized for certain design factors. This work also has motivated us to pursue further research in building bare PC Web servers that can be scalable to run large applications. In addition, as the Web server is self-contained with all necessary code, it inherently provides ubiquity on the network, which allows for moving the server dynamically on the network during emergency and catastrophic situations. Furthermore, bare PC software may also provide alternate ways of building secure systems for critical applications.

Most of the computer applications today run on a given operating system environment. The application programs written in a programming language such as C++ are intertwined with operating system and environment to run on a given machine. Thus, a C++ program requires a processor such as an Intel Pentium and an operating system such as a Microsoft Windows. Why do we have to run applications in such a constrained environment? It may be because, that is how evolution of computing happened since the inception of personal computers in the 80s. In this paper, we describe details on how to run C++ applications on a bare machine. We provide some benefits of running applications on a bare machine without any operating system. We present some sample applications that are built to demonstrate the capability of running C++ applications on a bare machine. Finally, we describe our future research direction that may potentially offer a revolution in computing architecture and application development.