Subject: filexfer, SSH_FXP_READ

From: [email-masked] (Niels M�ller)
Date: 11 Jan 2001 15:17:20 +0100

The spec says "For normal disk files, it is guaranteed that this will
read the specified number of bytes, or up to end of file. For e.g.
device files this may return fewer bytes than requested."

I'm interested in the case of reading from something that resembles a
character special file like a serial port or tty. The above text seems
to allow the server to reply with a SSH_FXP_DATA containing *zero*
bytes.

I'd think it would make a lot of sense to disallow this case. I think
a server should be required to keep a SSH_FXP_READ request in the
pending state until it can send a SSH_FXP_DATA reply containing at
least one byte. Or send a SSH_FXP_STATUS of SSH_FX_EOF.

Some other cases also need to be clarified: A SSH_FXP_READ with length
= 0, can that return immediately, or should it stay pending until some
data is available? The latter behaviour makes it possible to implement
poll/select over the filexfer protocol.

What happens if a client sends a SSH_FXP_CLOSE on a handle that have
pending read or write requests? The spec requires the server to send
replies for the read and write requests, in order, before sending a
reply to the close request. What should the replies be? Some kind of
status=interrupted, or an SSH_FXP_DATA with zero bytes data?

/Niels

---

From: Tatu Ylonen <[email-masked]>
Date: Thu, 11 Jan 2001 23:12:37 +0200 (EET)

> least one byte. Or send a SSH_FXP_STATUS of SSH_FX_EOF.

I would tend to agree with you.  However, no-one has ever tried to use the
protocol for anything useful with anything other than disk files, so there
may be special issues that we haven't seen yet.  Thus, I would consider
the use of the protocol with devices as "experimental" (regardless of what
we write in the spec).

> poll/select over the filexfer protocol.

Again, I didn't think about this when writing the spec.  My first reaction
would be to disallow length=0 rather than giving it poll semantics.  My
reason for this that the protocol has been designed so that it would (at 
least in theory) be possible to use it for implementing a remote
file system.  If it is ever used for that, and if select() is to be
supported in a reasonable manner, we might want to implement it as a new
feature (negotiated using the extensions in the initial version exchange)
so that it allows polling multiple handles simultaneously.  On the other
hand, select() does not make much sense unless one support devices and/or
sockets in some reasonable manner.  For this reason, I would leave the use
with devices/sockets/etc and the implementation of select open until
someone comes up with real experience and a working implementation in a
practical application.  If that ever happens, I would then make it a
separate RFC that amends this one.

> status=interrupted, or an SSH_FXP_DATA with zero bytes data?

Again good question.  My opinion is that the server MUST complete
any earlier read/write requests before processing the close.  Reason:
provide an illusion of the operations being performed sequentially.  If I
recall correctly, the protocol placed a similar constraint on the order in
which read/write operations are processed.  I don't like the area of later
operations affecting earlier ones unpredictably.  Also, if close can be
sent after write without waiting for wait completion first, we save one
roundtrip per each file copied to the remote server.  While not a big
saving, other things being equal it is probably worth doing.

    Tatu

---

From: [email-masked] (Niels M�ller)
Date: 15 Jan 2001 01:15:12 +0100

> saving, other things being equal it is probably worth doing.

You have a point about pending writes. But I'm not sure about reads.
It makes sense to me to close a handle when you don't want to complete
pending read requests. The client can't really know if a file is
special like /dev/tty, or has long or infinite response times for some
other reason, and it still needs to be able to kill the handle.

Perhaps we need two messages, one for friendly closing, and one for
abrupt closing (somewhat like the SSH_CHANNEL_EOF and
SSH_CHANNEL_CLOSE in the connection protocol)? If so, the behavior you
describe should be assigned to the "friendly close" operation, and the
abrupt close operation can perhaps wait until we have some experience
with special files.

What do other file sharing protocols do?

/Niels

---

From: Tatu Ylonen <[email-masked]>
Date: Tue, 16 Jan 2001 09:25:13 +0200 (EET)

> other reason, and it still needs to be able to kill the handle.

This is also a good point...

> What do other file sharing protocols do?

I think at least Unix systems interpret Unix devices at the client (i.e.,
if you have a device i-node on an NFS file system, it refers to that
device on the client system).  This means that operations never block on
the server.

In my opinion we shouldn't worry too much about file sharing.  It is just
a wild future possibility, which might never become real with this
protocol.  I wouldn't want to complicate the protocol because of that; if
someone needs extensions later, they can be negotiated.

Perhaps we should say that the file transfer server SHOULD NOT open files
that are actually devices or sockets?  There is also a denial of service
risk here if server implementations are not careful.  If someone actually
tries to do something useful with devices, we could write a new draft/RFC
at that point to describe the extensions that were made.

    Tatu

---

From: [email-masked] (Niels M�ller)
Date: 17 Jan 2001 19:39:37 +0100

Tatu Ylonen <[email-masked]> writes:

> risk here if server implementations are not careful.

I think it would be inappropriate to make a strong recommendation
either way (SHOULD/SHOULD NOT). Just say that servers MAY refuse to
open devices and special files. Or say nothing about it.

/Niels

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 17 Jan 2001 15:14:37 -0500

>open devices and special files. Or say nothing about it.

        Disagree.  While you and Tatu will be able to apply
common sense and come up with something reasonable, in the
modern IETF lots of folks who read the RFCs later on will do
so slavishly without applying common sense.  So it is sensible
for the RFC to make some sensible recommendations SHOULD/SHOULD NOT, 
for the benefit of naive implementers (and their user base).

Regards,

Ran
[email-masked]