On Tue, Jul 02, 2019 at 05:55:10AM -0400, Benjamin Coddington wrote: > > As far as I understand it, for a particular xid, there should be a > > call and a reply. The approach I took then was to pull out these > > fields from my capture and ignore RPC calls where both are present > > in my capture. It seems this is simplistic, as the number of RPC > > calls I have without an attendant reply isn't lining up with my > > incident window. > > Does your capture report dropped packets? If so, maybe you need to increase > the capture buffer. > I'm not certain, but I do have a capture on both the NFS server and the NFS client--comparing them would show me if I was under most circumstances. Good catch. > > In one example, I have a series of READ calls which cease > > generating RPC reply messages as the offset for the file continues > > to increases. After a couple/few dozen messages, the RPC replies > > continue as they were. Is there a normal or routine explanation > > for this? > > > > RFC 5531 and the NetworkTracing page on wiki.linux-nfs.org have > > been quite helpful bringing me up to speed. If any of you have > > advice or guidance or can clarify my understanding of how the > > call/reply RPC mechanism works I appreciate it. > > Seems like you understand it. Do you have specific questions? > Is it true that for each RPC call there is an RPC reply with the same xid? Is it a-priori an error if an otherwise correct RPC call is not eventually paired with an RPC reply? Thank you, -A -- Alan Post | Xen VPS hosting for the technically adept PO Box 61688 | Sunnyvale, CA 94088-1681 | https://prgmr.com/ email: adp@xxxxxxxxx
