Hi guys, I have nearly completed the assignment and I hope to submit it within this month. I am listing below the design choices regarding the server. Feel free to comment on any part of the design. Server Design ------------- Note: Both Data class and RemoteData class implement the DataInterface interface. The RemoteData class has the same public method as the Data class, it contains a single instance of Data class. Each of the methods in RemoteData simply pass on the request to the Data class instance. 1. Used RMI over serialization and sockets. No dynamic class downloading is used (although the app works fine with a code base specification and the stub class only on the server side.) 2. Implemented lock/unlock by changing the signature of the lock and unlock methods in the database. An additional method unlockAll() is also added to the Data class, which is invoked whenever the RemoteData class is unreferenced. This method is not included in the DataInterface so it cannot be invoked by the clients. 3. lock and unlock method use client ID to keep track of the lock and unlock operation. 4. No timeout supported for the record locks (since it introduced more issues than it solved). 5. No two clients/threads are allowed to access the low level database file at a time. Each thread has to obtain a mutex lock on the database file instance db before accessing it. So in this way I have implemented thread safety in my Data class. Each of methods of the data class has been modified to implement the sunchronization of the mutex object. 6. When running in networked mode the DataServer class creates a single instance of RemoteData class for each file and binds them to the RMI registry, which can be looked up by the client. 7. Record/Database locks are kept in a HashTable with the record number as the key and the clientID as the value. Since there is only one instance of Data class for each data file so I have implemented the lock/unlock algorithm in the Data class itself. So each clients request to lock/unlock a record is handled properly by the unlock and lock methods of the data class itself. 8. Implemented a complete GUI for the server, complete with menu bar and toolbar and a pane to show messages. I did this because the instructions say that the program should run in a production version i.e. the JRE 2 edition of java. This edition does not permits any output to be routed to the console so a gui is a definite requirement. Although no definite requirement has been directly made in the instructions but the production clause in the instructions simply routed me towards this.
I have tested the FBN assignment on a local computer and in a local area network. It works without any problem and hiccups. However I have no idea as to how to check this over internet with client on one computer at a given location and the server on a different comptuer in another geographically different location. Any suggetions are always welcome
It seems to me like you are playing with one instance of RemoteData to handle multiple clients using the clientID generated in the client side. I don't know how you generate the unique ClientIDs across the server VM from the client but I didn't do it this way. I had a unique RemoteData object for every gui client and didn't use clientId since the RemoteData object itself represents an unique client. You need to use threads on the client side and test your app by creating lot of them and try to access your server. You will learn a lot from it. [ May 11, 2002: Message edited by: Sai Prasad ]
Well, I genereate unique client id by concatenating clients local host ip address + ":" + java.rmi.server.UID. This guranteess my a unique client ID for each and every clients. I have tested this with threads on a single computer as well as well as on 3 computers on a lan. This worked and is running robustly each time I start my client. Any suggetions are welcome.
What if the user doesn't want to shut down the client every time the server is started? In my design, if I cannot find the server, I try to do a lookup again and life goes on. It may not work in your design. Also I didn't want to change the method signatures in Data and also didn't want to put security related code in the Data class. Restricting some of the clients from using the server is purely a server functionality.
Hi, Well I believe in one formulae that is once the server goes down the whole network goes down. If any user wants to retry, simply start the client once again. Moreover if the server is down then there is no reason for the client to be active. Any request to the server causes an error message. In this scenario, in my implementation the client has to restart the app. I know it is a limitation. But the instructions say keep it simple.... Any suggetions are welcome.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop