Date: Fri, 14 Oct 2005 16:20:48 -0400 (EDT) From: rick@snowhite.cis.uoguelph.ca To: fs@freebsd.org Subject: FreeBSD NFS server not responding to TCP SYN packets from Linux/SunOS clients Message-ID: <200510142020.QAA26662@snowhite.cis.uoguelph.ca>
next in thread | raw e-mail | index | archive | help
> where is that rule stated? most NFS clients i am aware of retransmit an > RPC after 60 seconds over TCP. For NFSv4, it's in RFC3530, Sec. 3.1.1 (actually applies to RPCs other than NULL). For NFSv2,3 it was never required by the RFCs, so it is questionable what the correct behaviour is. Being the first to do NFS over TCP, I only did retransmits after reconnect. I think I described it that way in the ancient Usenix paper. (http://snowhite.cis.uoguelph.ca/nfsv4, then click on it) When Sun first did NFS over TCP, I believe they did do retries (using a conservative timeout). I think I eventually convinced Sun that it wasn't a good idea and I think that Solaris no longer does them, but I'm not sure. (For this to work correctly, a server is required to disconnect whenever it can't generate a reply to an RPC over TCP for any reason.) So, for NFSv2,3 I don't know of a stated "rule". I don't think it is covered in the NFS interoperability RFC that appeared a while back, but can't remember for sure. The reason I didn't do retries over TCP in the original work are basically what has already been discussed in this thread. I intended that the TCP virtual circuit would apply back pressure to the client to slow/stop sending requests to a congested server. rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510142020.QAA26662>