December 4th, 2000.
Suppose you want to create an application which reads and writes
files over the Internet.
The remote file system is in a certain host, while your application
resides in a local host, separated by a network. Your goal is
to make it possible for your local application to be able to read
and write data in a file system at a remote site.
Assuming the network runs TCP/IP (which is usually the case) and using Java, you can achieve your goal by making the following components:
The main thrust of the coursework is for you to realise these two components so that they can offer basic file operations over the internet, however far away a remote file resides.
We ask for (1) to be STATELESS, and (2) to offer a specified
API. In stage 2, (2) should
incorporate cache mechanisms. For details, see the spec.
These are excluded from the requirements, to avoid giving you too much work. In general, adding these mechanisms soundly could result in additional marks. However not having them does not result in any deduction in marks.
The textbook CDK3 and my specification. For caching mechanisms, the textbook has detailed coverage (NFS and Andrew are the two best references).
Stage 2 is about making a cache mechanism. In case you are short of time but you wish to have a clear achievement, I divided this into (A) caching without a cache coherence mechanism (updates may not be reflected) and (B) caching with consistency (updates would be reflected, either by the client-side using last modified time/staleness, or by the server-side using call-backs (or other means if you think appropriate). If you only implement (A), then you should also present the design for (B) on the basis of your implementation.
If (A) and (B) are working perfectly with sound design and
documentation, then that is the best. The next is only (A) with
sound and clear design. Then third best is to do a sound and implementable
design for (A) and (B). In the last case, you should really be
concrete about the design, or you may not get substantial marks.
Yes, in general. On the server side, file handles identify individual files. On the client side, file handles (which clients use) are used for each client to issue their operations without specifying file names. A server can return its own file handle to a client, but this is not in general necessary since a socket identifies a file with which the client-side file system intertacts with the server-side. Returning server file handles is not recommended because it is not secure!
I specified the internal structure of file handles on the client-side (see filehandle.java). This can be changed provided that the same interface is offered to client programs.
No, this is not necessary. Implementing this is not so difficult, and it is good practice, so there could be additional marks for such functionality. In general, I recommend you to concentrate on the main, required, functionalities.
If a server-side file system is issued a write, this should be write-through by default (as you learned). For the client-side, this can vary. The simplest idea is to make it always write-through, both at the client and the server side. When you incorporate caching, you can also write on the cache, and use "flush" method (which you can additionally implement) to do the real writing. Whichever design you choose, specify clearly in the documentation.
It simply moves to the next byte of what you wrote.
Yes, especially in the first stage. This would be different from commonly used file interfaces. A good reference for the standard file interface in Java is the Java 2 class FileOutputStream.
You can make your interface only for writing and only for reading, by specifying it when you open a file. This is not necessary, especially for Stage 1. However this design option is also permitted.
There is no change in the server-side operation. For a client side, as you already learned, it reads from a cache if there is data there and it is not stale.
As I noted in the specification, you can cache the whole file in the client, or only part of it, according to your design choice.
It simply moves as a client reads on, in the same way as in the standard Java file read.
Not necessarily, but if you use call-backs for cache coherence, yes. It depends on your design choice. Note server-side operations (which your client-side file system would use) can be changed, according to your needs. For example, I require them to be stateless (which is one of the aims of this project), but if you have really a very good argument then you would add/replace with stateful operations. In general, however, it is safer to use the stateless operations.
You can use your own client and data, including measurement, but you should implement the same (or almost the same) API for a client as specified in FileSystemAPI. If you deviate from the specification, you should give arguments for your choice.
The bottom line is that your API should work with any client which uses it, with any data provided.
In the final testing, I will add more lines to the data, so that checking takes substantial time.
For the main part of the sotware, you should make your own efforts. However discussions among friends are not dissuaded at all: acknolwedge such discussions. Further, if you do use another's class, you can acknowledge it. If your design is original and you use only a small part and acknowledge it, then it is fine.
Another possibility for code sharing is when you really wish to implement a challenging design. For example, if you want to make a fully functional Internet file system incorporating concurrency control, caching, locking etc., you can share your work and acknowledge which part one did. This is risky in terms of marking since, if this does not go well, I may not be able to give good mark at all. However if you and your friend are quite confident with each other's skills, this would be an option. In this case I restrict the number to two: make it clear about individual contributions, and you should contact me before embarking on this.
I already wrote about this in the specification. I here add:
the total does not exceed 20 marks, it is always better to have
running code, documentation is considered (make it clear about
your design choice).
Simply I did not have much time. It would be better if it read
data line-by-line. Change this as you like!
The read in the client-side API is stateful - it just reads a given number of bytes from the current file pointer. The read in the fileSystemAPI is stateless - it reads a given number of bytes from a given offest in the file.