Transport and caching

My filesystem uses UDP protocol. As it's not reliable, simple timeout-retransmit mechanism is provided for ensuring delivery. Every request sent to server is to be acknowledged. UDP datagrams are either broadcast on the local network [4,5] or multicast [3] on an administratively-assigned multicast address. Using full multicasting, mmsnfs can also span multiple subnets interconnected with multicast routers. All datagrams sent by clients are called requests and they are unicast directly to server (if its IP is known, they're multicast otherwise). Responses are always multicast, but they have unique receiver ID attached, which is then used for matching requests and replies. Upon receiving a response packet by a client, two scenarios can take place:

1. Receiver ID of the packet matches client's ID, so this is a reply to previously originated request, so a started operation may continue its work.
2. Packet is not addressed directly to the client, but since it contains some information about filesystem state (for example, updated file information), received data can be cached on disk, so it won't be needed to request it separately introducing unwanted traffic.

In fact both scenarios can be handled similarly. Finally mmsnfs caches all the information on the disk, using mechanisms based on existing distributed filesystems like Coda [2] or Andrew [6]. After transferring entire filesystem, mmsnfs enters silent mode and listens only for updates sent by the server.