| commit | 836fbadb96a8308e6283eee5c7b3bdae818b58ca | |
| author | J. Bruce Fields <bfields@redhat.com> | |
| Mon, 3 Dec 2012 20:50:38 +0000 (3 15:50 -0500) | ||
| committer | J. Bruce Fields <bfields@redhat.com> | |
| Tue, 4 Dec 2012 12:49:24 +0000 (4 07:49 -0500) | ||
| tree | beb0b70d57d7ac98adbc1931483f2c2ff5d0325f | treesnapshot (tar.gz zip) |
| parent | 8af345f58ac9b350bb23c1457c613381d9f00472 | commitdiff |
svcrpc: support multiple-fragment rpc's
Over TCP, RPC's are preceded by a single 4-byte field telling you how
long the rpc is (in bytes). The spec also allows you to send an RPC in
multiple such records (the high bit of the length field is used to tell
you whether this is the final record).
We've survived for years without supporting this because in practice the
clients we care about don't use it. But the userland rpc libraries do,
and every now and then an experimental client will run into this. (Most
recently I noticed it while trying to write a pynfs check.) And we're
really on the wrong side of the spec here--let's fix this.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Over TCP, RPC's are preceded by a single 4-byte field telling you how
long the rpc is (in bytes). The spec also allows you to send an RPC in
multiple such records (the high bit of the length field is used to tell
you whether this is the final record).
We've survived for years without supporting this because in practice the
clients we care about don't use it. But the userland rpc libraries do,
and every now and then an experimental client will run into this. (Most
recently I noticed it while trying to write a pynfs check.) And we're
really on the wrong side of the spec here--let's fix this.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
| net/sunrpc/svcsock.c | diffblobblamehistory |