Status of this Memo Content Internetworking (CDI) Scenarios This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice... more
Status of this Memo Content Internetworking (CDI) Scenarios This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to
Research Interests:
Research Interests:
Status of this Memo A Model for Content Internetworking (CDI) This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice... more
Status of this Memo A Model for Content Internetworking (CDI) This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called "content peering " or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary.
Research Interests:
A distributed object database stores persistently at servers. Applications run on client machines, fetching objects into a client-side cache of objects. If fetching and cache management are done in terms of objects, rather than fixed-size... more
A distributed object database stores persistently at servers. Applications run on client machines, fetching objects into a client-side cache of objects. If fetching and cache management are done in terms of objects, rather than fixed-size units such as pages, three problems must be solved: 1. which objects to prefetch 2. how to translate, or swizzle, inter-object references when they are fetched from server to client, and, 3. which objects to displace from the cache. This thesis reports the results of experiments to test various solutions to the problems. The experiments use the runtime system of the Thor distributed object database and benchmarks adapted from the Wisconsin 007 benchmark suite. The thesis establishes the following points: 1. For plausible workloads involving some amount of object fetching, the prefetching policy is likely to have more impact on performance than swizzling policy of cache management policy. 2. A simple breadth-first prefetcher can have performance tha...
Research Interests:
I present the problem of client object cache lockup in a distributed object-oriented database system where storage is recovered by garbage collection. If garbage collection is augmented with the ability to discard reachable unmodified... more
I present the problem of client object cache lockup in a distributed object-oriented database system where storage is recovered by garbage collection. If garbage collection is augmented with the ability to discard reachable unmodified versions of persistent objects, cache lockup is greatly reduced. I outline some remaining questions about this technique for managing an object cache. 1 Introduction In a distributed object-oriented database system, server machines store persistent objects shared by applications running on client machines. When an application invokes an operation on a persistent object, that operation must run on either the server or client. I consider the case where objects are moved or copied to the client for at least the duration of the client transaction. A number of existing object-oriented databases work partially or entirely in this mode of executing operations on the client machine: examples are O2 [1], GemStone [2, 9], and Orion [7]. 2 Complicating factors T...
Research Interests:
I argue against trying to solve the problem of clustering objects into disk pages. Instead, I propose that objects be fetched in groups that may be specific to an application or user, and that can be computed at fetch time. I briefly... more
I argue against trying to solve the problem of clustering objects into disk pages. Instead, I propose that objects be fetched in groups that may be specific to an application or user, and that can be computed at fetch time. I briefly describe crystals, which serve to record such groups statically. Finally, I speculate that ob- ject fetching may be particularly relevant for providing services to very small machines with limited memory, such as personal digital assis- tants.
Research Interests:
Research Interests:
We define and examine the shutdown problem for blockchain systems: how to gracefully end the system's operation at the end of its useful life. A particular focus is those blockchain systems that hold archival data of long-lived... more
We define and examine the shutdown problem for blockchain systems: how to gracefully end the system's operation at the end of its useful life. A particular focus is those blockchain systems that hold archival data of long-lived interest. We outline what it means to achieve a successful shutdown, and compare those criteria to likely end-of-life conditions in a generic blockchain system. We conclude that the decentralized nature of blockchain systems makes shutdown difficult, particularly if the system uses an unstable consensus like the Nakamoto consensus of Bitcoin. Accordingly, we recommend against using blockchain with unstable consensus for any data whose value is likely to persist beyond the life of the blockchain system. For any such systems that are already in operation, we recommend considering a hard fork to implement stable consensus. Such consideration needs to happen well in advance of the system's end of life.
Research Interests:
... of the constructs in Argus that support reli-able distributed computing are also useful for dynamicreconfiguration. ... Our experience is rel-evant to the reconfiguration of other distributed systems with shared ... In particular, it... more
... of the constructs in Argus that support reli-able distributed computing are also useful for dynamicreconfiguration. ... Our experience is rel-evant to the reconfiguration of other distributed systems with shared ... In particular, it is relevant to Thor, an object database which shares these ...
Research Interests:
Page 1. Subtypes vs. Where Clauses: Constraining Parametric Polymorphism Mark Day Lotus Development Corporation 1 Rogers Street Cambridge, MA 02 142 MarkDay@crd.lotus.com Robert Gruber Barbara Liskov Andrew C. Myers ...
Research Interests:
Research Interests:
Research Interests:
Research Interests:
Research Interests:
We previously designed the Notification Service Transfer Protocol (NSTP) as a general-purpose coordination mechanism for building synchronous groupware applications. We initially thought that a colleague awareness tool (colloquially, a... more
We previously designed the Notification Service Transfer Protocol (NSTP) as a general-purpose coordination mechanism for building synchronous groupware applications. We initially thought that a colleague awareness tool (colloquially, a "buddy list") was just another synchronous groupware application. However, as users requested more capabilities, we discovered that awareness applications have an underlying model of interaction that differs from our other, quasi-meeting,
Research Interests:
Research Interests:
Research Interests:
... Client Cache Management in a Distributed Object Database by Mark Stuart Day ... their own endeavors. Andrew Myers, Umesh Maheshwari, Sanjay Ghemawat, Atul Adya, Quinton Zondervan, Phil Bogle, Miguel Castro, Jim O'Toole, Franklyn... more
... Client Cache Management in a Distributed Object Database by Mark Stuart Day ... their own endeavors. Andrew Myers, Umesh Maheshwari, Sanjay Ghemawat, Atul Adya, Quinton Zondervan, Phil Bogle, Miguel Castro, Jim O'Toole, Franklyn Turbak, and Mark Sheldon have all ...
Research Interests:
... Acknowledgements Thor is a joint research project carried out by the authors and a number of others. Members of this team include Atul Adya. Boaz Ben-Zvi. ... In Proceedings of the Fifth Symposium on Principles of Database Systems,... more
... Acknowledgements Thor is a joint research project carried out by the authors and a number of others. Members of this team include Atul Adya. Boaz Ben-Zvi. ... In Proceedings of the Fifth Symposium on Principles of Database Systems, pages 240-251. Page 15. Eswaran К. ...
Research Interests:
This document serves both as a reference manual and as an introduction to Argus. Sections 1 through 3 present an overview of the language. These sections highlight the essential features of Argus. Sections 4 through 15 and the appendices... more
This document serves both as a reference manual and as an introduction to Argus. Sections 1 through 3 present an overview of the language. These sections highlight the essential features of Argus. Sections 4 through 15 and the appendices form the reference manual proper. These sections describe each aspect of Argus in detail, and discuss the proper use of various features. Appendices I and II provide summaries of Argus's syntax and data types. Appendix III summarizes some of the pragmatic rules for using Argus.
Research Interests:
Thor is a distributed object-oriented database where objects are stored persistently at highly available servers called object repositories, or ORs. In a large Thor system, performance tuning and system reconfiguration dictate that... more
Thor is a distributed object-oriented database where objects are stored persistently at highly available servers called object repositories, or ORs. In a large Thor system, performance tuning and system reconfiguration dictate that objects must be able to migrate among ORs. The paper describes two schemes for object references that support object migration, one using location-independent names and the other, location-dependent names. The paper analyzes the performance of the two schemes and concludes that location-dependent names are the right choice for systems like Thor, where we want fast access to objects that have migrated.
Research Interests:
... He received the PhD degree in electrical engineering and computer science from the Massachusetts Institute of Technology (MIT) in 1995. Carr: John Carr is a Software Engineer at Cisco Systems. He studied planetary science at MIT and... more
... He received the PhD degree in electrical engineering and computer science from the Massachusetts Institute of Technology (MIT) in 1995. Carr: John Carr is a Software Engineer at Cisco Systems. He studied planetary science at MIT and went into computer programming. ...