On Fri, Feb 28, 2003 at 11:42:31AM -0800, Rod Van Meter wrote:
> * Does Coda work over NAT?  I think not, unless the NAT is static and
> includes a specific rule that helps the server contact the client
> (assuming client is NATed but server isn't, such as a client at my house
> on a DSL/NAT and a server elsewhere in the real world).

Works just fine, although you might have to tweak the probe interval of
the client to be more frequent, the masquerading firewall typically
keeps the local<->remote port mapping around for a bit (2-3 minutes) and
as such servers have no problem getting back to the client.

> * Does the server contact the client on a well-known port, or is it
> dynamically assigned at the client and then remembered by the server? 

The server replies to whatever ipaddress/port was listed as the sender
in the udp/ip packet headers. That way a masquerading firewall can
rewrite those headers and replies can actually be sent back to the
client. Instead of the client claiming it has ip 10.10.10.10, port 2430,
which is no use when it is behind a firewall.

> * Does the server correctly recognize that you're the same client when
> your IP address changes (e.g., when I move from the office to home)?

It correctly identifies you as a new 'instance' of the same client. i.e.
the client is forced to reestablish callbacks, but when the client
retransmits any operations because it missed the acks the server will
notice this and not declare it a conflicting update.

> * Is there an RPC or configuration switch you can send/set to force a
> client to always be either weakly or strongly connected, or is it always
> done only with the heuristics?  I'm thinking of environments where the
> client might have a way to directly determine some characteristics of
> its network state (e.g., knowing that it's using a modem); then it could
> inform the server, rather than one or both sides guessing.

No. RPC2 doesn't care about weak/strong, it just uses bandwidth and
latency estimation for the eRTT (expected roundtrip time) of sent
packets and when it should retransmit, or fail with ETIMEDOUT.
Weak/strong is a thing for the client, and servers don't do any
adaptation, so I have no idea why rpc2 should inform the server that it
is behind a modem? Coda servers are dumb.

> * Being UDP based, it should be better off with large numbers of clients
> than TCP, but has this been tested?  Do we know how many clients a
> server can scale to?  Thousands?  Tens of thousands?  Millions?  (I

I don't know, we use the same basis as AFS, and that system has somewhat
proven itself to be reasonably scalable. The advantage that Coda adds is
that when the servers get overloaded, writers will switch to
write-disconnected operation which significantly reduces the load on the
server (as we can then commit 100 operations in a single transaction).

Jan