In message <20060622170553.GU11554@multics.mit.edu>"Charles M. Hannum" writes
>On Wed, Jun 21, 2006 at 03:36:53PM -0700, jonathan@dsg.stanford.edu wrote:
>> I am still very peturbed by the XXX comment. If someone like fvdl
>> doesn't grok why the setsockopt() is needed, we need a better
>> explanation. And I'm worried by both the dependency on the strncmp()
>> matching both "inet" and "inet6", when what's really meant is
>> 	"are we running over TCP"?
>
>FTR, I'm not really a fan of this use of strncmp().  

FTR:, me too.  At least four smart people read past my original
message, without comment, until you drow our attention to
the effect of 

	strncmp("inet6", "inet", 4);


>suggestion assumes there will never be an incompatible protocol named
>"TCP" in another protocol family.  Is this a safe assumption? Who
>knows.  I think it's better to test the protocol family *and* protocol
>if you're trying to be "careful".

Equally FTR, I checked yesterday that TUBA (TCP over CLNP) is long
dead in NetSBD and in other OSes which might borrow our code.  I also
looked hard for TCP running over otehr protocols, and found only
defunct attempts to run TCP over raw ATM VCs.

Again, FTR, once I saw Christos' pointer to the second use
of TCP_NODELAY in rpc_vc.c, I reworked my own tree to use the
RPC-internal state.

Equally FTR, yesterday I was actively considering how to support
near-future of RPC over SCTP, where i beleive the conventional
API requires something like:

	...
	setsockopt(fd, IPPROTO_SCTP, SCTP_NODELAY, &one);

so I'd go further than Christos, and (modelled on Christos' code) pass
__rpc_setnodelay() a struct __rpci_sockinfo *si:


int
__rpc_setnodelay(int fd, const __rpc_sockinfo *si)
{
	...
}

called  as:
	if (si.si_socktype == SOCK_STREAM)
	    __rpc_setnodelay(fd, &si);

That way, if we add SCTP support, we don't need to change any calls to
_rpc_setnodelay: updating the body of __rpc_setnodelay() will do.  The
tests for consistency with current expectations (SOCK_STREAM RPC
implies TCP, which implies underlying IPv4/IPv6) that you (and I) both
want can be done inside __rpc_setnodelay().

Are we converging?