The specific goals my filesystem is going to meet are:
The use of multicasting is motivated by rapidly increasing network bandwidth, and also by commonly used star-topology of networks. A quick observation reveals, that in such a networks the most common communication scheme is client-server one, with one dedicated machine being server and all the others being clients. Since client-to-client transactions are very rare, all the data passes the physical link between server machine and its neighbour switch/hub device, making this link eventually congested. Other physical links are usually either idle or moderately loaded. Heavy use of multicast packets for transferring data between server and clients does not introduce any additional overhead on the critical link, since unicast packets still would have passed it. But additional overhead is put on the other links. It won't hurt, because most of the data passing them sooner or later will pass the critical server link. The cost of filtering unwanted packets by clients is very low.
By using multicasting for transferring filesystems, this task can be accomplished efficiently even with 100BaseTX 100Mbit Ethernet, which is very widely used in small networks. Using gigabit Ethernet hardware will increase transfers considerably and such a link can be saturated only by fast enough harddisk. Nevertheless mmsnfs is not designed to be a scalable solution for large networks. It's intended to be a flexible solution for small ones.