On 26 Jan 1999, Greg Troxel wrote:

> I can comment on several aspects of the callback/firewall issues:
> 
> 1) Using DHCP, or more precisely, having clients have different
> addresses at different times for reasons including DHCP and static
> configurations, seems to work fine.  Yes, you lose the active
> callbacks for recently accessed files when you change addresses, but
> other than introducing some slight delays and chance for conflicts
> (which have not actually bothered me), this has caused me no problems
> in practice.

Coda currently handles changing IP addresses fine, albeit not optimally;
handling multi-homed addresses can cause some problems however.

> 2) Firewalls are problematic.  In my case, the client->server rpc
> (venus->codasrv) works ok, but the side effects don't, since the first
> packet in the exchange is sent from the server (codasrv-se->venus-se).
> Having the client send a venus-se->codasrv-se packet before this would
> probably make most stateful firewalls that allow UDP responses work
> ok.

It also restricts you to one client behind the firewall, as
multiple-clients ends up having the side-effect packets go to the wrong
client the second time :(.  A firewall proxy that understands quite a bit
about Coda is needed, and it may run into problems because of security
features (like encryption and keying).  As such, this would require a
client that knew about speaking to proxies and authenticating
differently...

> 3) Coda seems to use MTU-sized packets, and not do MTU discovery.
> I believe this makes it work suboptimally with IPSEC, Mobile IP, etc.
> When my own project involving IPSEC and Mobile IP-like stuff gets
> farther along, I hope to look into this a bit, and at least make rpc2
> use 1400-byte packets.
> Having rpc2 work on top of TCP could inherit path MTU discovery.
> Otherwise, I think it would be nice if rpc2 did PMTU discovery itself.

My understanding is that it is actually fairly difficult to implement MTU
discovery in userland when making use of a single socket to communicate
with many many hosts.  On the other hand, I agree entirely that there is a
problem: I have been whining about this for over a year now. :)

I wrote a TCP-based side-effect, as presumably the largest impact on
transfer is for bulk transfers.  It's not ready for production use (i.e.,
it works, but chews through file descriptors and doesn't support all of
the features of SFTP yet, including byte quotas), but if people are
interested, I can try harder.  Due to the construction of RPC2, you can
only easily have one side effect in use for a particular service, so
you'd have a Coda server that spoke SFTP or TCP, but not both.

RPC2 itself cannot fragment/reassemble RPC packets, meaning that a) there
is an theoretical limit of 64K for arguments and return values on an RPC
because of UDP, and b) there is a much lower one because of RPC2's
internal packet size limit.  As such, MTU discovery wouldn't help us any,
because we'd have to rewrite parts of RPC2 to support fragmentation to get
the packet sizes down below the MTU :(.  Clearly this arrangement has to
suck on high-loss lines with low MTU :(.  However, some statistical
profiling of RPC packets on a normal Coda server show that in general RPC
packets are quite small (500 bytes or less I think, but I'll go dig up the
traces I made) so are unlikely to fragment in travel.  SFTP is clearly a
different thing altogether.  But SFTP should be able to speak
fragmentation because it already breaks files up into chunks, so maybe
there is hope.

  Robert N Watson 

robert@fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: 03 01 DD 8E 15 67 48 73  25 6D 10 FC EC 68 C1 1C

Carnegie Mellon University            http://www.cmu.edu/
TIS Labs at Network Associates, Inc.  http://www.tis.com/
SafePort Network Services             http://www.safeport.com/