hi mike-
> Every once in a while, we see complaints that nfs mounts are
> failing due
> to there being no more reserved ports available for outbound rpc
> communication. This often happens when using TCP transports,
> because all
> outbound connections that are closed go into a TIME_WAIT state.
i know that steved has also been looking at this problem. he found that
user-land uses TCP connections with abandon and has put it on a diet.
and, the client side should take care to avoid using reserved ports
unless it is absolutely necessary.
> For various reasons, avoiding the TIME_WAIT state using connect(fd,
> {AF_UNSPEC}, ...) or doing SO_REUSEADDR may not be the safest way to
> handle things.
i have a patch for the kernel RPC client to use AF_UNSPEC to reuse the
port number on connections. before i head into the wilderness, what's
unsafe about that?
> rpcproxyd will create outbound connections and multiplex the
> transports
> with any number of simultaneous clients. There is no support for
> re-binding your transport once created. It will also cache outbound
> server connections for 30 seconds after last use, which
> greatly helps keep the number of ports used down in a mount-storm
situation.
the typical RPC client-side connection timeout is 5 minutes. any reason
not to use that value instead of 30 seconds?
you will also need a unique connection for each program/version number
combination to a given server; ie you can't share a single socket among
different program/version numbers (even though some implementations try
to do this, it is a bad practice, in my opinion).
to support IPv6 you will need support for rpcbind versions 3 and 4; but
that may be an issue outside of rpcproxyd.
> rpcproxyd is written as a single-threaded/no-signals/select-based
daemon.
will using select be a scalability issue? you might be better off with
something like libevent or using epoll.
_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs
