2 ms·
Sun ONC RPC was used to implement the (famous) stateless NFS server over UDP. NFSv3 added TCP (and brought minimal network state) into the protocol. NFSv4 rol
by chasil 8y ago
Sun ONC RPC was used to implement the (famous) stateless NFS server over UDP.
NFSv3 added TCP (and brought minimal network state) into the protocol.
NFSv4 rolled all the external stateful services (stat, mount, idmap) into the main protocol.
Bearing in mind this progression, are stateless services difficult to maintain in production, and will there be a strong tendency to reintroduce state?
- ben509 8y agoWhat they're doing is not making these stateless. I think labelling it stateless is a bit misleading and diminishes what they've done: worked out consistent mechanisms to decouple the state from the devices. You can't run NAT without tracking what device and port the return ports map to. So what they're doing is working out how to distribute that. And, naturally, mapping port numbers to devices is highly amenable to circular hashing. They've also identified some algorithms that require only very transient state or whose "state" can be determined dynamically. Load balancers, for instance, are inherently tolerant of errors, and they load balancing is well understood to perform better when you don't track load closely. If you send work randomly, it will pile up on some nodes, but if you ping two nodes at random to see who is less busy, that additional information is enough to balance the work. I think the difference between these and NFS is that for NFS to do its job, it has to be fully implemented on the client to work. I would definitely anticipate people wanting to add additional features, but if those can be factored out as separate components, you limit the issue. And, further, if they can manage their state in a distributed fashion, the network components themselves would remain decoupled, and you still get the elasticity.