>>>>> "D-Man" == D-Man <[EMAIL PROTECTED]> writes:
D-Man> Interesting ... from my understanding UDP is a D-Man> connectionless protocol, and as such packets aren't D-Man> guaranteed to arrive at the destination. It seems to me D-Man> that for a file system, you really want all the packets to D-Man> arrive. How is this not a problem? (BTW, I'm just Well, in theory, all UDP packets could be numbered, much like TCP packets, and you get exactly the same reliability TCP offers. This effectively means you are tunnelling a connection based protocol over a connectionless based protocol (in much the same way TCP uses IP). You might be able to do this with less overhead then TCP, but personally I would just use TCP, as that way, other people are responsible for the tedious tasks of congestion control, etc). I have heard though, that NFS uses RPC, and RPC doesn't do anything this sophisticated. Rather, if the server doesn't respond in time, the client sends the request again. This is OK for requests like "read file", which don't affect the state of the server, as the worst thing that could happen is that the server will reread the file again. For other requests though, like "delete file", confusion could occur. eg. consider the case where the client wants to delete file X, and the file gets deleted, but the response is lost. The client resends the request again, and the server processes that request again, but this time says "file not found" because it no longer exists (it has no way of knowing that this was the same request it just received). The client gets totally confused, because it as far as it was concerned, the file did exist. Could be more serious, I imagine for "append file" operations, where you could get the data appended twice... I once read a book that said care needs to be taken with any RPC call that alters the state of the server, for this reason, but from what I have heard, NFS doesn't care. Conclusion: (if my sources are correct) never use NFS (unless mounted read-only) over a congested network... -- Brian May <[EMAIL PROTECTED]>