Subject: sftp draft clarification

From: Alok Aggarwal <[email-masked]>
Date: Fri, 22 Jun 2001 11:39:10 -0700 (PDT)

Section 3 (General Packet Format) para 4 of draft-ietf-secsh-filexfer-01.txt
says:

"The maximum size of a packet is in practise determined by the client (the
maximum size of read or write requests that it sends, plus a few bytes of
packet overhead). All servers SHOULD support packets of at least 34000 bytes
(where the packet size refers to the full length, including the header above).
This should allow for reads and writes of at most 32768 bytes."

The header in question looks like this:

uint32			length
byte			type
byte[length - 1] 	data payload

How should the above para be interpreted? I'm a little confused with the part
that says all servers should support packets of *at least* 34000 bytes and then
says this should allow for reads and writes of *at most* 32768 bytes.

Also, why can't the server allow for reads and writes say ~64k bytes?

-Alok

---

From: [email-masked] (Niels M�ller)
Date: 25 Jun 2001 11:01:35 +0200

> says this should allow for reads and writes of *at most* 32768 bytes.

My interpretation is that

1. A server can choose to not support packets larger than 34000
   octets, and still be conforming (say, using a fixed size packet
   buffer). When such a server receives a packet larger than 34000
   octets, it is allowed to simply disconnect the client, or try to
   recover by sending some reasonable err message back.

   I.e. if a server implementation has a limit on packet size, that
   limit must be 34000 octets or larger.

2. A client can rely on being able to send read and write requests
   for up to 32768K of data; a conforming server has to support that.

> Also, why can't the server allow for reads and writes say ~64k bytes?

It can, but a client can't expect a random conforming servers to do that.

/Niels

---

From: Darren Moffat <[email-masked]>
Date: Mon, 25 Jun 2001 08:53:04 -0700

> It can, but a client can't expect a random conforming servers to do that.

Maybe the protocol needs a packet size negotiation step, otherwise
it is going to be very hard for clients and servers that want to have
larger packets to be able to make the correct assumptions about what is
going on.

--
Darren J Moffat

---

From: [email-masked] (Niels M�ller)
Date: 25 Jun 2001 18:04:18 +0200

> larger packets to be able to make the correct assumptions about what is

I don't think any real negotiation is needed. If large packets are
important, we should just invent an extension, and let the server send
the extension and its max packet size (or "unlimited") with its
SSH_FXP_VERSION packet.

/Niels