Upload
becky
View
33
Download
0
Embed Size (px)
DESCRIPTION
Changing the way of designing distributed applications. Communication oriented design: FIRST design the communication protocol for the distributed system and then the program is developed accordingly - PowerPoint PPT Presentation
Citation preview
Changing the way of designing distributed applications
• Communication oriented design: FIRST design the communication protocol for the distributed system and then the program is developed accordingly
• Application oriented design: Develop the application as if everything were locally and then divide the application in modules which will run in remote machines
• The first approach is harder to design but simpler to implement
• The second one is better when there is a framework supporting the implementation of such a schema
Alternative Technologies
• Development of networks => development of distributed systems
• Development of middleware (libraries, tools, etc..) supporting easy programming of distributed systems
• Based on TCP/IP protocols• Higher level programming language for
distributed systems• The distributed case is not a problem
anymore
Remote Procedure Calls
• Motivation: NFS development (SUN)• A client application can call a procedure
(function) in a server application running on another computer as it were locally implemented
• Handle over parameters, receiving results in an appropriate format (integer, string, float,..)
• eXternal Data Representation, serialization
Remote Procedure Calls • The client stops until the procedure call returns
Call(parameters)
Receive results
RPC ServerRPC Client
Server framework: provided by the system
The Interface File • Specifies the protocol of the remote procedure: name, required parameters (number and type), result (type).• It is called the interface file because it holds the information the client needs to use
Uses Interface for compiling
Implements interface
RPC Server
RPC ClientInterface definition file
Remote Objects • This paradigm was rapidly replaced by the
remote object paradigm• An application can invoke a method of an object
located in another JVM • The interface file remains the key to describe
the object protocol to the clients
RemoteObjectServerInvoke method
Receive result
Files Involved
• Obtain reference to remote object
• Apply method as usually
• Receive results as usually
Client program Server program
• Define a particular class for implementing remote objects and implements the interface
• Create a remote-able object
• Make it publicly available
Define the methods (only the header)Which will be able to called remotely
implementsUse for compiling
Interface
An Example: Remote Date Server • The only method will be Date getDate(), the
server will answer with the local Date
DateServer
getDate()
getDate()
Tue Jun 12 17:20:24 DateClient
The interface file
import java.rmi.*;import java.util.Date;
public interface DateInterface extends Remote { public Date getDate() throws RemoteException;}
• It must import java.rmi.*• It must extend Remote• Every declared method should throw a
RemoteException
Define a class for implementing remote date objects
The remote Object Class definition
Remote Interface
RemoteObject
Implements
Remote
Extends
Extends
DateServer.java
The Client Program import java.rmi.*;import java.rmi.server.*;import java.util.Date;
public class DateClient { public static void main( String args[] ) { try { RemoteDate dateobj = (RemoteDate)Naming.lookup( "rmi://"+args[0]+"/DateServer" ); Date datum = dateobj.getDate(); System.out.println( “Server Date : " + datum ); } catch ( Exception e ){ System.out.println(e); } }}
The Stub and Skel Files• Communication is implemented by the stub and skel files• They are generated by compiling the class files of the remote object implementation with the rmic
command
Client
Stub
Remote Object Server
Skel
The name registry server• A server to register and make public remote objects• Server register the object by this server, clients ask this server for a reference to a certain object• It should run at the server‘s computer and have access (like any java program) to the stub file.• It must be started before the remote object is registered
Client Remote Object Server
rmiregistry
Which file where ?
• A client needs the stub file and the interface file• The server needs the Stub & Skel file
Client Remote Object Server
DateClient.classRemoteDate.classDateServer_stub.class
DateServer.class RemoteDate.classDateServer_stub.classDateServer_skel.class
How to generate stub & skel• The compiled implementation class should be compiled (again)
with the rmic command
DateClient.javaRemoteDate.java
DateClient.class
DateServer.class
DateServer_stub.classDateServer_skel.class
DateServer.java
RemoteDate.classjavac
javacjavac
rmic
Starting rmiregistry from program
• It is possible to start a registry server from the program• A number server will illustrate this and the concurrency problem
Remote Number Server2
ClientClient Client
getNumber()
getNumber()getNumber()
1 2 3
What do I get when calling a remote object ?
• A reference to the remote object• If the object has references to other not remote objects, the callers gets a COPY of these objects• If the remote object has a reference to other remote object, the caller gets a reference to these objects• See ListServer, ListClient, List Interface and MyList
The RMI-based Chat• The client must also receive messages from the server• It also implements a remote object, which is passed as parameter !!!• The server does not need to locate the client
Remote Object Client
Remote Object Server
addClient(this)
sendMessage(String)
newMessage(String)
refreshList(String[])
Automatic distribution (stub)• The stub can be distributed automatically but then the code needs to include a security policy statement• A security policy file must be provided, which must be specified in the command line • When starting the server, a URL for retrieving the stub file must be specified
java –Djava.security.policy=policy.txt -Djava.rmi.server.codebase=http://hostname/filelocation ClientProgram
Automatic distribution (stub)• The downloading of the stub class is made via URL protocol• A “web-server” must be running at the server side • We can use a small server which “serves” only class files for this purpose• ClassFileServer (extends ClassServer)• Steps :
– Download RFSClient.class, RFSInterface.class, policy.txt– Server start ClassFileServer port path– Server start Remote Object server– Client contacts server (with policy and codebase parameters
Activation of the server• Sometimes it is not convenient to have all server objects running waiting for a client• RMI provides an activation schema for remote object servers • There is only one “server” running (the rmideamon), who will “wake up” the server when a client requests a service• It is necessary then to write and run a set-up program, which will register the “sleeping” server with the rmid• For the client, there is no difference
Steps for writing an activable server
• Rewrite the server so it extends the activable class´instead of RemoteUnicastObject import java.rmi.activation.*; public class MyRemoteClass extends Activable implement MyInterface
• Remove the original constructor and write one which receives two parameters: public MyRemoteClass(ActivationID id, MarshalledObject data) throws RemoteException {
super(id, 0); }
• Compile with javac and rmic• Write and compile the set-up program which will register the activable class to the rmi daemon• See under RMI/ rmid
Steps for running this • Start the ClassFileServer and rmiregistry• Start the rmid
rmid –J-Djava.security.policy=policy.txt
• Run the Setup programjava -Djava.security.policy=policy.txt –Djava.rmi.server.codebase=http://hostname:port/ Setup
• Run the clientJava -Djava.security.policy=policy.txt –Djava.rmi.server.codebase=http://hostname:port/ client
• Look where the output of the server program is given• The code of the client does not change. Activation is strictly a server-side implementation decision !.
Architecture of a generic file server
Client Module
Aplication Directory service
Flat file service
Components• Flat File Service: Implements the operations which work
directly on the files. It uses a Unique File Identifier (UFID). A new one is generated for each new file
• Directory Services: is a FFS client , provides a mapping between the UFID and the textual names of the files. It also porvides the necessary functions for managing directories and obtain UFID.Directories are stored as plain files.
• Client module: Runs in every clinet computer, integrates and extends the FFS and DS operations in an interface application used by programmers. Contains information for localizing files over the network. Provides efficiency by implementing a caché
A model for an FFS interface• read(FileId, i, n) : attempts to read up to n bytes from a file
starting from the byte in the position i.
• write(FileId, i, Datos): writes a data sequence starting from the position i into the specified file
• create() : creates a new file (empty) and returns its UFID
• delete(FileId) : deletes the file
• getAttributes(FileId) : returns a structure containing the file attributes
• setAttributes(FileId, attr) : sets the file attributes according to what is stored in the structure
Model for the Directory interface
• Lookup(Dir, File) localises the name of the file in the directory UFID
• AddName(Dir, Name, File) If Name was not in the directory, the pair(Name,File) is added modifying the corresponding file
• UnName(Dir, Name) the pair (Name, file) is deleted from the directory
• getNames(Dir) turns the list of names in the directory
Access Controls• On a local file system it is necessary check the access rights
of the file user only when it is opened and the rights are kept until the file is closed
• On a distributed system the checking are made at the server side. There are two strategies used in order to keep the server stateless:– The checking is done when the filename is converted to the UFID and
the result is packed as a “capacity” which is returned to the client. The client uses this capacity for each further access.
– The checking of the user’s rights is made every time the file is accessed.
• The second one is the most used (in NFS & AFS) because its simplicity
The NFS
Application
Virtual System
SistLocal
ClientNFS
Virtual System
ServerNFS
SistLocal
Caracteristics of the NFS• Communication is implemented over RPC and is open. Resides in the
server’s kernel • The identification of the files is by file handlers containing following
information:
• Filesystem identifier• i-node number or file• i-node generation number
• The “state” is kept in the client in a v-node• Client authentication is done in every access.Client provides ID and
group ID• Flat file & directory services are integrated• The mount service provides a link to a remote system
Cache in NFS• Unix provides standard Cache mechanisms: buffer cache, read ahead,
delayed write
• NFS Cache on Client’s side: data for writing are stored in the cache memory and are written when a commit takes place (buffer full or closing the file)
• NFS Cache on server’s side: results form read, write, getattr, lookup and readdir are stored locally. This can introduce some inconsistencies with the versions stored at the different clients’ machines because writings in one client are not distributed at the moment to the others. Clients are responsible for maintaining their caches updated. This is done with the help of timestamps: – Tc= time of last synchronization of the cache, – Tm= time of modification
– At a certain time T the cache will be still valid if (T - Tc < t) o (Tmcliente = Tmserver). Normally t will be 3-30 secs for files and 30-60 for directories
The AFS• Aims to a better performance in situations of scalability • Principles
– Whole-file serving: the content of the whole file is transferred to the client (even if the client has requested a small part of it)
– Whole-file caching: The file transferred are stored in the local cache memory. The cache is almost permanent.
• Procedure– When the client opens a remote file, the whole content is ttransferred if
it was not there already – Read/write operation are done locally– With a close, a copy of the file is transmitted to the server
The AFS Architecture
Application
Unix Kernel
LocalSist
Venus
Vice
Unix Kernel
Consistency of the Cache• Every time a file is transmitted from the server to a client a callback promise is
provided which guarantees that if other client modifies the file, this one will be notified
• The callback status can be either valid or cancelled • When the file is transferred to the client the callback is put on valid. When a
callback is received from the server (another client did modify the file) the callback promise is put on cancelled
• Every time the client wants to open a file, it searches it first in the cache. It if is there the callback promise status is looked, if it is still valid, the cache is used by the client, if it is not there or the callback is cancelled, a new version is transferred from te server
• If the client’s computer reboots,it asks for a timestamp for every file in the cache to the server. If it is consistent with the local timestamp the callback is put on valid, if not on cancelled
Homework• Implement an unifyed RMI-based FFS and directory server based on the
interfaces shown before• The remote object shuold implement the following methods:
– read(FileId, i, n) : attempts to read up to n bytes from a file starting from the byte in the position i.
– write(FileId, i, Datos): writes a data sequence starting from the position i into the specified file
– create() : creates a new file (empty) and returns its FileId
– delete(FileId) : deletes the file
– Lookup(Dir, File) : localises the name of the file in the directory UFID
– AddName(Dir, Name, File) : If Name was not in the directory, the pair(Name,File) is added modifying the corresponding file
– UnName(Dir, Name) : the pair (Name, file) is deleted from the directory
– getNames(Dir) : returns the list of names in the directory
• It is up to you how to implement the FileId