On Mon, Feb 18, 2002 at 08:43:04AM +0100, Rene Rebe wrote:
> On: Mon, 18 Feb 2002 00:54:38 -0500, Jan Harkes <jaharkes_at_cs.cmu.edu> wrote:
> > On Mon, Feb 18, 2002 at 06:23:55AM +0100, Rene Rebe wrote:
> > > > As long as the client remains disconnected, it won't 'really' discard
> > > > the user's tokens so that you continue to have whatever access
> > > > permissions were cached at the time of disconnection.
...
> But when you use suspend - your token get also invaild after 25 hours

The client isn't the one that really decides on the token's validity.
i.e. the token won't be discarded until the server rejects it. I saw
Steffen's response, which unfortunately enough shows how wrong
tokenfiles really can be, i.e. someone can get access to cached objects
at any given time during a disconnection.

The very very insecure part here is that venus has no way of checking
whether the token has been tampered with, as that requires access to the
secret auth2.tk, so only Coda servers can do this. To access any given
object in the Coda cache without being root on the machine, disconnect
the network cable and futz with the contents of the token that is passed
up to venus.

The only way we could block non-root users from seeing the cache is by
encrypting the tokenfile with the user's password and some additional
randomness provided by venus. Then if we pass up the token and the
password, venus can decide if it is a unchanged token and whether it
trusts the userid. The servers can still be used to check the validity.

> The stange thing is, that direct coping to the server (in the moment
> when the files gets closed) are much slower compared to the copy
> during reintegration after a manual cfs disconnect.

Ah, but that is easy to explain. When we are reading files, we are at
the 'pull' side of the SFTP connection, similarily during reintegration,
the server is 'backfetching' the modified files, again the pull side of
the connection. However, when we're fully connected, the client 'pushes'
the data to the server.

The difference between push and pull in SFTP is dependent on whoever
made the initial RPC2 call that starts the SFTP transfer. It is the
side that sent the RPC2 call that is the passive side, while the
receiver (RPC2 server) is the active side that controls the timeouts.

So we're faster when the data sending end is controlling the transfer.
while we slow down when the receiving end is in control.

> After some sleep I'll take a look into the source.

Ok, quick overview (of the server side of the transfer,

when sending a file (i.e. server handling a fetch)

InitSE()
CheckSE()
    PutFile()
     	sftp_SendStrategy()			# sends several data packets
	while (!done)
	    AwaitPacket()
	    if (ack)
		sftp_AckArrived()		# moves window
		    sftp_SendStrategy()		# sends more data
	    else 
		sftp_SendStrategy()		# resend data
		

when receiving a file (i.e. server handling a store)

InitSE()
CheckSE()
    GetFile()
	sftp_SendStart()  			 # tell other side to start
	while(!done)
	    AwaitPacket()
	    if (DataArrived)
		sftp_DataArrived()		 # writes data to disk
		    if (last packet in batch)
			sftp_SendAck()		 # we only ack the last
						 # packet in a batch
	    else
		sftp_SendTrigger()		 # resends ack


The worst case problem when the receiving end is the controlling side,
is that we only ack the last packet in a batch. However this last packet
is the first packet that is lost due to congestion. So we hit a timeout,
and ask for a retransmission, this one will typically send 9 packets,
one of the unacked ones and then some more because we have a window of
up to 32 packets that can be unacked. This becomes worse and worse as
more packets are not acknowledged, and we'll not see the packet that
normally triggers the ack, so all acks are really generated by timeouts.

This occurs until the window is full, and then the client only sends
single packets, which have the ACKME flag and so we end up doing a
stop-and-wait style transfer. This ofcourse is the possible worst case
scenario, and not too typical.

But you can 'twiddle' the number of packets we send in a batch and the
window size, on the client side.

 -sa sendahead,  normally 8 you can reduce this to f.i. 4.
 -ws windowsize, normally 32, should really be a problem.
 -ap ackpoint,   which packet in the outgoing sequence has the ackme flag
		 maybe setting this to 6 and keeping the sendahead at 8
		 could at least counter the scenario I described above.
 -ps packetsize, currently 1024, which means that we send about 8KB of
		 data with the default sendahead of 8. Increasing this
		 will cause IP-level fragmentation, but on a reliable
		 network should improve performance.

On the server these values can be set in the server.conf configuration
file, i.e windowsize, sendahead, although I don't see the ackpoint and
packetsize settings there.

I believe the client and server always negotiate to the lowest of these
settings on either side of the connection.

Jan