Reynolds, F. and J. Heller, "Kernel Support for Network Protocol Servers," in Proceedings of the USENIX Mach Symposium, pp. 149--162, Nov. 1991.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....in the single UNIX server [14] Therefore, the whole UNIX server crashes if one subsystem crashes due to the errors although the microkernel itself are not a#ected. To improve this insu#cient fail safety, Mach supporting multi server is proposed [15] For example, userlevel protocol servers [35] allow a new network protocol to be implemented, and errors of each protocol server are not propagated to the rest of the operating system. An erroneous server is simply terminated by the kernel. The multi server system achieves su#cient fail safety, but the performance is sacrificed because the ....

Reynolds, F. and J. Heller, "Kernel Support for Network Protocol Servers," in Proceedings of the USENIX Mach Symposium, pp. 149--162, Nov. 1991.

....comparing the speed of TCP in Mach 2.5 (from the networking point of view, similar to 4.3 BSD) and Mach 3. 0 (a microkernel with BSD derived networking code in user context) show that it is very difficult to optimize user space TCPs to run at even half the speed of the kernel based implementation [31]. Per byte optimizations for TCP Header processing is a cost that is incurred per packet. Checksumming and copying costs are incurred per byte. Optimizations for per byte costs are dependent on operating system environments and processor architectures. There are some general lessons, however, ....

Franklin Reynolds and Jeffrey Heller. Kernel support for network protocol servers. In Proceedings of the Usenix Mach Symposium, pages 149--162. Usenix Association, November 91.

....is spent in the network input path (packet filter, etc. though we did not have time to verify this through measurements. Assuming that Mach is responsible for most of the slowdown, there are two ways to fix it: 1. Improve general network performance. The work described by Reynolds and Heller [16] is an example of this approach. 2. Reduce the number of RPCs. Instrumentation shows that 36 of the Sprite RPCs that are generated by the Andrew benchmark are open RPCs. Adding a name cache would probably reduce this number considerably [18] though it would require changes to native Sprite. ....

Franklin Reynolds and Jeffrey Heller. "Kernel Support For Network Protocol Servers", Proceedings of the USENIX Mach Symposium, November 1991, 149--162.

....If the interrupt indicates the transition of an ADC s receive queue from the empty to a non empty state, the interrupt handler directly signals a thread in the ADC channel driver, as described in Section 2.1.2. At first glance, ADCs may appear similar to the mapped device drivers used in Mach [17] and other microkernelbased systems. In these systems, the user level UNIX server is granted direct access to, and control of, the network device. However, application device channels are different from mapped device drivers in two important ways. First, the OS kernel remains in control of the ....

F. Reynolds and J. Heller. Kernel support for network protocol servers. In Proceedings of the USENIX Mach Symposium, pages 149--162, Monterey, Calif., Nov. 1991.

....path through the kernel. Then, another ADC channel driver is activated, causing further network traffic to use the ADC. ADC reassignment is transparent to application programs, except for performance. 6. 4 Related Work At first glance, ADCs may appear similar to the mapped devices used in Mach [RH91] and other microkernel based systems. In these systems, the user level UNIX server is granted direct access to, and control of, the network device. However, application device channels are different from mapped device drivers in two important ways. First, the OS kernel remains in control of the ....

F. Reynolds and J. Heller. Kernel support for network protocol servers. In Proceedings of the USENIX Mach Symposium, pages 149--162, Monterey, Calif., November 1991.

....in the single UNIX server [14] Therefore, the whole UNIX server crashes if one subsystem crashes due to the errors although the microkernel itself are not affected. To improve this insufficient fail safety, Mach supporting multi server is proposed [15] For example, userlevel protocol servers [35] allow a new network protocol to be implemented, and errors of each protocol server are not propagated to the rest of the operating system. An erroneous server is simply terminated by the kernel. The multi server system achieves sufficient fail safety, but the performance is sacrificed because the ....

Reynolds, F. and J. Heller, "Kernel Support for Network Protocol Servers," in Proceedings of the USENIX Mach Symposium, pp. 149--162, Nov. 1991.

.... The performance of this variant is lower than the one with the mapped device [11] Some of the performance lost due to the message based interface can potentially be recovered by using a third variant that uses shared memory to pass data between the device and the protocol code as described in [22]. One alternative to a monolithic implementation is to dedicate a separate user level server for each protocol stack, and separate server(s) for network device management. This arrangement has the potential for performance problems since the critical send receive path for an application could ....

Franklin Reynolds and Jeffrey Heller. Kernel support for network protocol servers. In Proceedings of the Second USENIX Mach Workshop, pages 149--162, November 1991.

....applications, is a legitimate way to improve performance. The protocol architecture in conventional operating systems does not easily accommodate applicationspecific protocols. First, application specific code often runs substantially slower than native kernel protocol code [BFM 94, RH91, Bir93, vRHB94] Second, the failure of a protocol module can cause the entire operating system to fail [SMP92, Tho95] In response to this, some systems only allow the superuser to define new protocols [HPAO89, Sun, Wel95] greatly limiting the set of applications for which a new protocol can ....

Franklin Reynolds and Jeffrey Heller. Kernel Support for Network Protocol Servers. In Proceedings of the Second Usenix Mach Workshop, November 1991.

....of the packet filter, or use it more aggressively by having each receiving thread register its own filter. We could also use shared memory to pass data between the UDP server and its clients, as is done now in some cases by the Unix server 3 , or between the kernel and the Unix server [Reynolds Heller 91] The second response is that, for low latency request response protocols, the important parts of the protocol (that is, the common cases) can be implemented directly within the sending and receiving address spaces. This enables the protocol server to be bypassed altogether. With the exception of ....

Reynolds, F. and Heller, J. Kernel Support for Network Protocol Servers. In Proceedings of the Second Usenix Mach Workshop, November 1991.

....of Beta vrs. VHS) The need for application specific protocols, though not new, is more pressing than ever. The research community has not ignored this need. Kernel level packet demultiplexing to support application specific protocols has long been available [1] and has continued to evolve [2] [3]. Clarke and Tennenhouse [4] have proposed Application Level Framing as a guiding principle for the design of the next generation of protocols. ALF has had an influence on our work and others [5] One important difficulty is that regardless of the value of application specific protocols, protocol ....

Reynolds, F and Heller, J. Kernel Support for Network Protocol Servers, Proceedings of the Usenix Mach Symposium, pp 149-162, November 1991

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC