【正文】 grammer. In this paper, we present the concept of an overlay socket as a new programming abstraction that serves as the end point of munication in an overlay work. The overlay socket provides a socketbased API that is independent of the chosen overlay topology, and can be configured to work for different overlay topologies. The overlay socket can support application data transfer over TCP, UDP, or other transport protocols. This paper describes the design of the overlay socket and discusses API and configuration options. 1 Introduction Applicationlayer overlay works provide flexible platforms for developing new work services without requiring changes to the worklayer infrastructure. Members of an overlay work, which can be hosts, routers, servers, or applications, anize themselves to form a logical work topology, and municate only with their respective neighbors in the overlay topology. A member of an overlay work sends and receives application data, and also forwards data intended for other members. This paper addresses application development in overlay works. We use the term overlay work programming to refer to the software development process of building application programs that municate with one another in an applicationlayer overlay. This work is supported in part by the National Science Foundation through grant ANI0085955 work. The diversity and plexity of building and maintaining overlay works make it impractical to assume that application developers can be concerned with the plexity of managing the participation of an application in a specific overlay work topology. We present a software module, called overlay socket that intends to simplify the task of overlay work programming. The design of the overlay socket pursues the following set of objectives: First, the application programming interface (API) of the overlay socket does not require that an application programmer has knowledge of the overlay work topology. Second, the overlay socket is designed to acmodate different overlay work topologies. Switching to different overlay work topologies is done by modifying parameters in a configuration file. Third, the overlay socket, which operates at the application layer, can acmodate different types of transport layer protocols. This is acplished by using work adapters that interface to the undelaying transport layer work and perform encapsulation and deencapsulation of messages exchanged by the overlay socket. Currently available work adapters are TCP, UDP, and UDP multicast. Fourth, the overlay socket provides mechanisms for bootstrapping new overlay works. In this paper, we provide an overview of the overlay socket design and discuss overlay work programming with the overlay socket. The overlay socket has been implemented in Java as part of the Hyper Cast software distribution. The software has been used for various overlay applications, and has been tested in both localarea as well as widearea settings. The Hyper Cast software implements the overlay topologies described in and this paper highlights important issues of the overlay socket, additional information can be found in the design documentation available from several studies before us have addressed overlay work programming issues. Even early overlay work proposals, such as Yoid, Scribe, and Scattercast, have presented APIs that aspire to achieve independence of the API from the overlay work topology used. Particularly, Yoid and Scattercast use a socketlike API, however, these APIs do not address issues that arise when the same API is used by different overlay work topologies. Several works on applicationlayer multicast overlays integrate the application program with the software responsible for maintaining the overlay work, without explicitly providing generalpurpose APIs. These include Narada, Overcast, ALMI, and NICE. A recent study has proposed a mon API for the class of socalled structured overlays, which includes Chord, CAN, and Bayeux, and other overlays that were originally motivated by distributed hash tables. Our work has a different emphasis than since we assume a scenario where an application programmer must work with several, possibly fundamentally different, overlay work topologies and different transmission modes (UDP, TCP), and, therefore, needs mechanisms that make it easy to change the configuration of the undelaying overlay work. Fig. 1. The overlay work is a collection of overlay sockets. Root (sender) Root (receiver) (a) Multicast (b) Unicast. Fig. 2. Data forwarding in overlay works. The rest of the paper is anized as following. In Section 2 we introduce concepts, abstractions, and terminology needed for the discussion of the overlay socket. In Section 3 we present the design of the overlay socket, and discuss its ponents. In Section 4 we show how to write programs using the overlay socket. We present brief conclusions in Section 5. 2 Basic Concepts An overlay socket is an endpoint for munication in an overlay work, and an overlay work is seen as a collection of overlay sockets that selfanize using an overlay protocol (see Figure 1). An overlay socket offers to an application programmer a Berkeley socketstyle API for sending and receiving data over an overlay work. Each overlay socket executes an overlay protocol that is responsible for maintaining the membership of the socket in the overlay work topology. Each overlay socket has a logical address and a phys