Abstract not found

le workstation as an X terminal. Currently, several companies sell a poor man's version of this --- the typical "workstation" is a small alphanumeric pager-like device which limits the user to reading and composing Email. Such an approach has its uses; however, there are some fundamental problems with the idea of building the world entirely with mobile X terminals. One problem is the very limited cellular bandwidth and its inefficient allocation by a circuit-switched, TDMA or FDMA phone network operating with a large cell size. Severe bandwidth constraints limit the number of simultaneous users, the nature of the applications that can be run, or both. (Presently in many areas callers are regularly denied service because no channel is available.) The present Email services may represent the limit of what can be done with analog phone service designed for voice. Another, hopefully temporary, problem with building on cellular telephone systems is that different systems are not always comp

Host mobility is becoming an increasingly important feature with the recent arrival of notebook and palm top computers, the development of wireless network interfaces and the implementation of the global network. This paper describes and compares three proposals from Sony, IBM and Columbia University for mobile host protocols (MHP) that are compatible with the TCP/IP protocol suite. A set of basic requirements for a MHP are also suggested and it is observed that none of the three proposals entirely satisfies these requirements. Each proposal has faults in their implementation of mobile network layer functionality. Moreover, it is noted they do not address problems that must be solved in both higher and lower layers. Key Words: Mobile Protocols, Wireless Networks, Networks, IP 1 Introduction Computers are no longer large, expensive, and nonportable. Recent developments make it possible to buy inexpensive notebook and palm top computers that are both portable and extremely powerful. As a...

this paper will touch on current topics in many areas of networking. From cryptography to routing, from billing to expanded techniques for automatic configuration, mobility changes the way we think about computing, and invalidates some of the design assumptions upon which current network protocols and products have been built

Introduction One can view file system evolution as having passed through three stages: 1. Uniprocessor systems, like original UNIX. In such systems there is no truly concurrent access to the same file by several clients, and so it was not hard to design file systems that provide the most recent data to every reader. 2. Distributed and/or parallel non-replicated systems, which bring added problems: ffl Concurrent access, meaning several clients access the same server. This opens the question of cache consistency. ffl Client and server can fail separately. 3. Replicated systems, bringing those problems mentioned above plus: ffl Concurrent access, now meaning the possibility of separate clients simultaneously accessing the same file at separate servers. ffl Separate failure among servers as well as between client and server raises the possibility of version skew at the servers. A fourth stage is here now: mobile computing, w

Contents 1 Introduction 1 2 Background 4 3 Mechanisms for Interposition and Composition 15 4 The FiST Language 24 5 Evaluation Plan 39 6 Related Work 41 7 Summary 46 A Appendix: Vnode Interface Tutorial 47 B Appendix: Typical Stackable File Systems 57 C Extended Examples Using FiST 63 D Appendix: Wrapfs Mount Code 72 E Appendix: Portability Using Autoconf 77 List of Figures 1 A Complex Composed File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Data Path in a Device Level File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Data Path in a User Level File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Data Path in a Vnode Level File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5 Typical Propagation of a Vnode Operation in a Chained Architecture . . . . . . . . . . . . 10 6 Composition Using Pvnodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7 Interposition Resulting in

We describe a mechanism for replacing files, including open files, of a read-only file system while the file system remains mounted; the act of replacement is transparent to the user. Such a "hot replacement" mechanism can improve fault-tolerance, performance, or both. Our mechanism monitors, from the client side, the latency of operations directed at each file system. When latency degrades, the client automatically seeks a replacement file system that is equivalent to but hopefully faster than the current file system. The files in the replacement file system then take the place of those in the current file system. This work has particular relevance to mobile computers, which in some cases might move over a wide area. Wide area movement can be expected to lead to highly variable response time, and give rise to three sorts of problems: increased latency, increased failures, and decreased scalability. If a mobile client moves through regions having partial replicas of common file systems, then the mobile client can depend on our mechanism to provide increased fault tolerance and more uniform performance.

Disconnected operation refers to the ability of a distributed system client to operate despite server inaccessibility by emulating services locally. The capability to operate disconnected is already valuable in many systems, and its importance is growing with two major trends: the increasing scale of distributed systems, and the proliferation of powerful mobile computers. The former makes clients vulnerable to more frequent and less controllable system failures, and the latter introduces an important class of clients which are disconnected frequently and for long durations---often as a matter of choice.