Dr. Dobb's Journal - November 2007 - (Page 25)

d11zeid_p6db 9/10/07 11:04 AM Page 25 clients and servers with distributed objects, although logically it is still a client-server system and any machine may be both a client and a server at the same time. • Clustering refers to a set of tightly integrated computers that run the same processes in parallel. Tasks are subdivided and the subdivisions are run on individual machines. The individual results are then assembled to produce the final result. Clustering differs from other kinds of distributed computing in that clustered computers are usually much more tightly coupled. Clustering is a way to construct a kind of “supercomputer” from a group of similar machines over a LAN. Clusters are centrally controlled and often the node machines don’t even have keyboards or monitors. These nodes exist strictly to share their resources for the processes allocated by the server. • A computer grid utilizes the resources of many separate machines connected by a large network to solve process-intensive problems. Where a cluster is a logical client-server model, a grid is more like a peer-to-peer model that shares resources as well as files. This scheme often uses the Internet to access many widely dispersed computers to solve problems that would normally require the use of a supercomputer. An example of this is the SETI@home project (setiathome.berkeley.edu) that uses idle time on thousands of computers throughout the world to help analyze data from radio telescopes as part of an effort to search for extraterrestrial life. Communication Strategies There are three common strategies for implementing a communications scheme in client-server architectures (Table 2). These are presented in the order of oldest and most standard to newest and most modular. Berkeley sockets (or just “sockets”) are the earliest version we discuss, followed by RPC, and then RMI. The latter two strategies are both based upon sockets yet remove some of the management overhead normally required by sockets. Sockets are defined as endpoints for communication, with one socket at each endpoint of the communications channel. A socket works with Internet Protocol (IP) and either Transmission Control Protocol (TCP) or UDP (User Datagram Protocol). The dif- ference between TCP and UDP is that TCP provides error checking and is bidirectional. UDP is unidirectional and provides no error checking. In this project, we needed TCP because it provides feedback that a connection has actually been established. With sockets the client has to manage the socket connection by opening it, closing it, and establishing an input stream to read from the socket. The server employs a “listener” to monitor a specific port. When a client sends a request for a connection, the server will accept the request and the connection will be established. With sockets each connection is unique. The client needs to know the address of the server, but the server does not need to know the address of the client prior to the connection being established. Once a connection is established, both sides can send and receive information. The main disadvantage of plain sockets is the overhead of creating and managing the connections. There are newer communications strategies such as RPC and RMI that simplify these connection maintenance details. When a process calls a procedure on a remote application in a distributed system, it is known as an RPC. With RPCs, an ordinary data structure is used in passing data to a remote procedure. The essential concept of RPC is hiding all the network code within “stub” procedures. The goal of RPC is to simplify writing distributed applications by making the networking code transparent. With RPC, a daemon or “stub” runs on a port of a remote system and listens for messages addressed to it. These stubs locate the appropriate port on the client or server and package the parameters into a form that can be transmitted over the network. This is known as “marshaling.” The main drawbacks of RPC are that in passing parameters, true pass-byStrategy Master divides up jobs and send a chunk to each worker (Push model) reference is not permitted, it is difficult to send and make sense of complex data types such as user-defined types, exception handling is more difficult, and there can be issues with data representation (www.wikipedia.org/ wiki/Remote_procedure_call). There is a selection of standardized RPC systems available such as Microsoft’s .NET Remoting and Java’s Remote Method Invocation. For reasons of portability and tool availability, we decided to use RMI. With RMI, objects are passed using remote method calls known as “callbacks” instead of data structures. RMI simplifies the design of the client because all it does is get a proxy for the remote object from entries in the RMI registry. It then simply calls the method in the same way it would call a local method. Since RMI is Java specific, it doesn’t provide a direct connection between objects implemented in different languages. Using Java’s Native Interface (JNI) API, however, it is possible to wrap existing C or C++ code such as the CodeMatch DLL with a Java interface, then export this interface remotely through RMI (see Figure 1). The JNI lets Java code that runs inside a Java Virtual Machine (JVM) interoperate with applications and libraries written in other programming languages. Distribution Strategies There are two different basic ways to distribute the jobs to the worker machines in this type of consumer-producer scenario (Table 3). These are known as the “push model” and the “pull model.” The way we will describe these is to have a “Master” computer, which is the controller, and many “Worker” computers that merely share their resources and perform computations. This is commonly known as the Master-Worker Paradigm (see Figure 2). The Master initiates the computation by creating a set of tasks or Disadvantages More difficult to establish any sort of load balancing. More work up-front to decide how to distribute the work. Greater initial network traffic. Extra work in creating the queue and setting up its availability to workers. Brief Comparison of Distribution Strategies Advantages No need to set up a shared queue. Shared queue (Pull model) Work load balances itself. Table 3: Distribution strategies. November 2007 l www.ddj.com l Dr. Dobb’s Journal 25 http://www.wikipedia.org/wiki/Remote_procedure_call http://www.wikipedia.org/wiki/Remote_procedure_call http://setiathome.berkeley.edu http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - November 2007

Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook Smart Compilers - But Smart Enough? Conversations Grid-Enabling Resource-Intensive Applications Distributed Computing: Windows and Linux Adobe AIR: Desktop/Web Convergence Transparency on Demand Reusable Associations Effective Concurrency The Agile Edge Swaine’s Flames

Dr. Dobb's Journal - November 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.