Wouter Verhelst wrote:
A protocol extension that lets both the server and the client initiate this keepalive probe would deal with both issues (provided we do not somehow swap out nbd-client).
Do we need the server to do this keepalive stuff, though? I mean, it's really the client that cares if the connection goes down. The server ought to be happy to just sit there -- if it's not getting any requests, it shouldn't matter.
There'd probably be an ioctl to enable this ping packet, so you could just call the ioctl and ignore failure (for older kernels). Then there'd be a new packet flag for this ping packet (or maybe just use a zero-length read or write, assuming the nbd-server just ignores those and returns a response). That way it would almost completely backward compatible.Implementing this backwards-compatibly is going to be the hardest part, I guess. Perhaps opening one of the NBD devices to call a specific ioctl to verify whether it supports this interface, and then setting a bit in the field of 'reserved' bits in the handshake could work, but I'm not sure how this would be best done.Sorry, I'm not sure I understand that bit. Could you elaborate?
I was just thinking out loud. Basically, an easy and backward compatible way to do this (client-side) ping is to periodically send a zero-length read or write, and as long as the server just ignores it (i.e., doesn't crash or do something otherwise stupid) and sends a response, everything will work and the protocol doesn't have to change.
-- Paul