Return to rpc.t CVS log

Up to [CSRG BSD Unix] / 43BSD / contrib / X / doc / Usenix

Annotation of 43BSD/contrib/X/doc/Usenix/rpc.t, revision 1.1

1.1     ! root        1: .SH
        !             2: Stub Generators and the X Protocol
        !             3: .PP
        !             4: The X protocol is not a remote procedure call protocol as
        !             5: defined in the literature [4,5],
        !             6: as client calls are not given the same guarantee of completion and
        !             7: error handling that an RPC protocol provides.
        !             8: The X protocol transports fairly large amounts of data and
        !             9: executes many more requests than typically seen in true RPC systems.
        !            10: Given this generation of display hardware and processors,
        !            11: X may handle greater than 1000 requests/second from client applications to
        !            12: a fast display.
        !            13: .PP
        !            14: X clients only block when they need information from the server.
        !            15: Performance would be unacceptable if X were a synchronous RPC protocol,
        !            16: both because of round trip times and because of system call overhead.
        !            17: This is the most significant difference between X and its predecessor
        !            18: W, written by Paul Asente of Stanford University.
        !            19: On the other hand,
        !            20: a procedural interface to the window system is essential for easy use.
        !            21: We spent much time crafting the procedure stubs for the several
        !            22: library interfaces built during X development.
        !            23: .PP
        !            24: The original implementation of the client library would always
        !            25: write each request at the time the request was made.
        !            26: This implies a write system call per X request.
        !            27: There was implicit buffering from the start in the connection to
        !            28: the server due to the stream connection.
        !            29: Over a year ago, we received new firmware for the Vs100, and
        !            30: were no longer able to keep up with the display.
        !            31: We changed the client library to buffer the requests in a manner
        !            32: similar to the standard I/O library; this improved performance dramatically,
        !            33: as the client library performs many fewer write system calls.
        !            34: .PP
        !            35: Many current RPC [6] argument martialing
        !            36: mechanisms perform at least one procedure
        !            37: call per procedure argument to martial that argument.
        !            38: This is almost certainly too expensive to use for this application.
        !            39: Even if martialing the argument took no time in the procedure,
        !            40: the call overhead would account for ~10% of the CPU.
        !            41: Stub generators need to be able to emit direct assignment code for
        !            42: simple argument types.
        !            43: Complex        argument types can probably afford a procedure call,
        !            44: but these are not common in the current X design.
        !            45: .PP
        !            46: Proper stub generation tools would have saved several months over the
        !            47: course of the project,
        !            48: had they been available at the proper time.
        !            49: Arguments could be made that the hand-crafted stubs in the X client library
        !            50: are more efficient than machine generated stubs would have been.
        !            51: On the other hand, to keep the protocol simple, X often
        !            52: sends requests with unused data, for which it pays with higher communications
        !            53: cost.
        !            54: It would be instructive to reimplement X using such a stub generator and
        !            55: see the relative performance between it and the current mechanism.
        !            56: .PP
        !            57: Machine dependencies in such transport mechanisms need further work.
        !            58: The protocol design deserves careful study.
        !            59: Issues such as byte swapping cannot be ignored.
        !            60: With strictly blocking RPC, the overhead per request is already so
        !            61: high that network byte order is probably not too expensive,
        !            62: given the current implementation of RPC systems on 
        !            63: .UX .
        !            64: With the higher performance of the X protocol,
        !            65: this issue becomes significant.
        !            66: It is desirable that two machines of the same architecture
        !            67: pay no penalty in performance in the transport protocols.
        !            68: Our solution was to define two ports that the X server listens at,
        !            69: one for VAX byte order connections, and one for 68000 byte order connections.
        !            70: At a late stage of X development,
        !            71: after X client code had already been ported to a Sun workstation
        !            72: and would interoperate with a VAX display,
        !            73: another different machine architecture showed that the protocol was
        !            74: not as conservatively designed as we would like.
        !            75: Care should be taken in protocol design that all data
        !            76: be aligned naturally (words on word boundaries, longwords on
        !            77: longword boundaries, and so on) to ensure portability of code
        !            78: implementing them.
        !            79: .PP
        !            80: X would not be feasible if round trip process to process times over TCP
        !            81: were too long.
        !            82: On a MicroVAX\(dg II running Ultrix\(dd,
        !            83: or on a VAX 11/780 running 4.2, these times
        !            84: have been measured between 20 and 25 milliseconds using TCP.
        !            85: .FS
        !            86: \(dg VAX is a trademark of Digital Equipment Corporation.
        !            87: .sp
        !            88: \(dd Ultrix is a trademark of Digital Equipment Corporation.
        !            89: .FE
        !            90: As this time degrades, interactive "feel" becomes worse,
        !            91: as we have chosen to put as much as possible in client code.
        !            92: Birrell and Nelson report
        !            93: much lower times using carefully crafted and
        !            94: tuned RPC protocols on faster hardware; even extrapolating
        !            95: for differences in hardware,
        !            96: .UX
        !            97: may be several times slower than it could be.
        !            98: Given a much faster kernel message interface, one should be able to
        !            99: improve on the current times substantially.
        !           100: The X protocol requires reliable in order delivery of messages.
        !           101: .PP
        !           102: The argument against using such  specific message mechanisms are:
        !           103: 1) the buffering provided by the stream layer is used to good advantage
        !           104: at the server and client ends of the transmissions.
        !           105: 2) Lless interoperability.
        !           106: X has been run over both
        !           107: TCP and DECNET, and would be simple to build a forwarder between
        !           108: the domains if needed.
        !           109: This reduces the number of system calls required to get the data
        !           110: from the kernel at either end, particularly when loaded.
        !           111: .PP
        !           112: These times have been improved somewhat by optimizing
        !           113: the local TCP connection, and could be further improved
        !           114: by using
        !           115: .UX
        !           116: domain connections in the local case.
        !           117: .PP
        !           118: In general
        !           119: .UX
        !           120: needs a much cheaper message passing transport mechanism
        !           121: than can currently
        !           122: be built on top of existing 4.2BSD facilities.
        !           123: Stub generators need serious work both for RPC systems
        !           124: and other message systems
        !           125: particularly in light of some of the issues discussed above.
        !           126: We would make a plea that there be further serious study of
        !           127: non-blocking protocols[7].
        !           128: There should be some way to read multiple packets from the kernel
        !           129: in a single system call for efficient implementation of
        !           130: RPC and other protocols.

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.