a Grid Computing System - Utopia

More documents

Recommendations

Info

3. The Basic Building Block - ONTA (Object Network Transfer Architecture) when a file is downloaded by ONTA from the network. These two situations are different in the sense that when storing an archive after using the object writer, a local temporary file is already created, at it should just be renamed to a unique file name. When downloading a file, first a unique filename should be obtained and than this file name should be used to store the downloaded file. For handling this cases the API consists of two calls: public String put (File f) public String getFileName(AliceURL appl) All the files are stored starting at a root directory that is selected by using a string parameter passed to the constructor of the file manager when the class is instantiated. All the files are stored starting at this directory, which is specified by the user through the use of the GUI. There is an issue of creating too many files inside the same directory and the ONTA file manager uses a hierarchical approach, so there are never more than a maximum number of files inside a directory. If that number is reached, a new subdirectory is created and all the other files with the same root directory start will be stored in that subdirectory. We do this in order to minimize the file system overhead induce by a larger number of files being located in the same directory, thus additional level of indirection being needed. The put (File f) method stores a local temporary file to a unique filename inside the ONTA root directory. This actually just gets a new file name, creates a new directory if needed (if the current one is full - that is the maximum number of files has been reached) and moves the file there. The second method, getFileName(AliceURL appl) should be used by all the client protocols to store a file when it is downloaded. Since all the references contain the application that they are related to inside the object reference taken from the space, the file manager has the ability to store all the files downloaded on behalf of an application in the same directory. This greatly improves the ability to have a good file structure organization and to be able to clean up the unused files much easier. So, given an application ID (in form of an AliceURL), this call will return a unique filename in a directory unique for that application (if this directory does not exists, it will be created). Storing files for different applications in different directories also resolves the issue of files with the same filename being downloaded in the same directory. To clean up files that are not used anymore, the file manager offers two calls to handle this: public void markNotUsed(String name) public void deleteUnused() The first method adds a file with a given name (the name returned by one of the two calls presented above should be used) to a list of files that are not longer needed. When deleteUnused() is called, all the files in the list are physically deleted from the disk. 30
3. The Basic Building Block - ONTA (Object Network Transfer Architecture) 3.7. The Protocols One of the principal focuses of ONTA is on plug-in protocol support. This means that new protocols can be added to the system on the fly and thus security fixes or new security levels for file transfer can be implemented without even restarting the system or any part of it. Developing a new protocol is very straight-forward as all it is needed is implementing two classes, one for the client side and one for the server side. Each of these classes should implement a corresponding interface. In the system there is only one hard-coded protocol needed to transfer new protocols (a protocol before-known by all parties is necessary to permit the communication at first). So, to add a new protocol, the programmer should implement these two classes and to advertise them with the advertiseProtocol method from the object repository. What needs to be implemented in the server and in the client side of the protocol is presented in the following subsections. We stress here that the protocols are identified by their name system-wide, so one should not deploy a protocol if another protocol with the same name exists. Since there is no central informa- tion system yet developed, this is a big flaw into the system, as there is no way to tell if there is another protocol with the same name somewhere else into the system. This could end up in a client side from one protocol trying to communicate with the server side of another protocol. For this reason, adding protocols to the system should be done for now under a centralized human control. 3.7.1. The Protocol Server The server side of the protocol mainly consists of one method, called acceptConnections, which should be implemented in a sever manner, that is it waits for connections and when a connection is requested, it should serve that connection and wait for a new one. Since the connection are initiated by the client side of the protocols, there is no guideline in how to implement the requests or the communication protocol. The interface for the protocol server is actually an abstract class that should be extended (it also contains the name of the protocol, that is set by the system, that is why it is not an interface): public abstract class ProtocolServer { } public abstract void acceptConnections(); public abstract void pushFileSupport (); There is one other method that can be implemented, that is the pushFileSupport() method. This method is called whenever a protocol server is registered and started, together with the acceptCon- nections(). If it is desirable to implement a way so that the connections are initiated from inside, 31
Page 1 and 2: a Grid Computing System Radu Niculi
Page 3 and 4: Abstract ALiCE is a middleware that
Page 5 and 6: Contents 3.4. The Remote Object Loa
Page 7 and 8: Part I. Introduction 7
Page 9 and 10: 1. Introduction the network. In a g
Page 11 and 12: 1.2.5. SETI@home 1. Introduction SE
Page 13 and 14: 2. ALiCE Design Overview At this ti
Page 15 and 16: 2. ALiCE Design Overview can be plu
Page 17 and 18: 2. ALiCE Design Overview The system
Page 19 and 20: 3. The Basic Building Block - ONTA
Page 29: 3. The Basic Building Block - ONTA
Page 35 and 36: 4. ALiCE Architecture and Implement
Page 47 and 48: Result Retrieval Thread 1 Result Co
Page 51 and 52: faster than when using just one res
Page 65 and 66: NO Task generator Execute task gene
Page 67 and 68: 5. Example of ALiCE Applications 5.
Page 69 and 70: ALGORITHM ALiCE_TRACE(m, n) TASK_GE
Page 71 and 72: 5. Example of ALiCE Applications Th
Page 73 and 74: 6. Performance Testing Based on a s
Page 75 and 76: Platform: £ GigaSpace on ws21 £ R
Page 77 and 78: Platform: £ Resource Broker on ws0
Page 79 and 80: Platform: £ GigaSpace on ws21 £ R
Page 81 and 82:
6. Performance Testing Analysis of
Page 83 and 84:
6. Performance Testing The second g
Page 85 and 86:
6. Performance Testing a certain lo
Page 87 and 88:
7. Developing ALiCE Applications 7.
Page 89 and 90:
7. Developing ALiCE Applications ge
Page 91 and 92:
7. Developing ALiCE Applications Th
Page 93 and 94:
7. Developing ALiCE Applications pu
Page 95 and 96:
} } THE RESULT import java.io.¤ ;
Page 97 and 98:
); } } MYRESULT.JAVA import java.io
Page 99 and 100:
DUMMY.JAVA import java.io.¤ ; publ
Page 101 and 102:
8. ALiCE Programming Templates wher
Page 103 and 104:
§ 8. ALiCE Programming Templates T
Page 105 and 106:
£ £ 9. Conclusions Implementing a
Page 107:
Bibliography [10] Sarmenta, L.F.G.
show all

a Grid Computing System - Utopia

Create successful ePaper yourself

Delete template?

Save as template?