hakanson@mist.cs.orst.edu (Marion Hakanson) (11/12/88)
I had occasion to look through the code for setting the socket
buffer sizes (using setsockopt()) in dumprmt.c (used in rdump
and rrestore) and rmt.c, and I'm a bit puzzled. This code seems
to only set the buffers for one-way traffic, i.e. from the dumping
(or restoring) machine to the machine with the tape drive on it.
If you look at rmt.c, for example, in checkbuf(), which is called
for both read and write operations, the RECEIVE buffer size is set
to match the size of the requested operation. This makes little
sense to me in the case of a read operation, when one would expect
the SEND buffer size to be set, and the corresponding RECEIVE buffer
on the other machine (e.g. one doing an rrestore) should also be set
to the new (presumably larger) size.
This conspiracy also includes the rrestore program, which uses rdump's
dumprmt.c code for talking to the remote rmt process. This code sets
its SEND buffer size, even though such an action makes sense only in
the rdump case, and not for rrestore. Certainly having the larger
buffer size for the rrestore case would help make remote reads go as
quickly as remote writes (well, more quickly than now, anyway).
So, if this is a bug, is it fixed in 4.3-tahoe? And if it's not a
bug, perhaps someone would be kind enough to tell me what I'm missing
(:-). For a fix, I'd envision a quick modification to the rrestore
Makefile which would pass ../dump/dumprmt.c through sed, changing
SO_SNDBUF to SO_RCVBUF, for rrestore's half of the bug. Fixing rmt
would also be relatively easy, perhaps adding a read/write flag to
checkbuf(), which would then use the appropriate socket option.
And while I'm at it, has anyone investigated (or implemented) an
extension to the remote tape protocol which would allow a 4.3 system
(which supports the expanded buffer sizes) to determine if the remote
system (rdump/rrestore or rmt, either one) also supports that socket
option? Remote tape transfers really go slowly (in either direction)
when one side has bigger (or smaller) socket buffers than the other.
Such an extension would greatly improve interoperability....
--
Marion Hakanson Domain: hakanson@cs.orst.edu
UUCP : {hp-pcd,tektronix}!orstcs!hakanson