'Continuation' packets in case of NFS READ.

'Continuation' packets in case of NFS READ.

[Tayade, Nilesh]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

Hi,

I am working on NFS packet capturing for NFS version3 protocol. In one
of the scenarios, I tried opening a very big file and in this case the
file data was transferred from server to client in several chunks.

I observed there were some 'Continuation' RPC payload sent from server
to client which carry file data. But even in Wireshark this doesn't
decode any other fields apart from the file contents.

Could someone please advice how client knows which particular file a
specific 'continuation' packet belongs to? The packet doesn't even have
the filehandle/program version data.

I have attached the trace file.


--
Thanks,
Nilesh
x46222
Yahoo IM: nilesh_tayade85



[-- Attachment #2: read_big_file_trace.pcap --]
[-- Type: application/octet-stream, Size: 62723 bytes --]

RE: 'Continuation' packets in case of NFS READ.

[Tayade, Nilesh]

>From: Lyle Seaman [mailto:lyleseaman@gmail.com]
>Sent: Thursday, October 14, 2010 4:23 PM
>To: Tayade, Nilesh
>Cc: linux-nfs@vger.kernel.org
>Subject: Re: 'Continuation' packets in case of NFS READ.
>
>TCP (or UDP) handles that. It's transparent to NFS.

Thanks for the information. But I also observed that if you mount
multiple mount points 
from same server, the packets for different mount points flow through
the same socket. 

Could you please elaborate how TCP/UDP can differentiate? Is this based
on the sequence number etc.? 

>On Oct 14, 2010 3:50 AM, "Tayade, Nilesh" <Nilesh.Tayade@netscout.com>
wrote:
>
>>Hi,
>>
>>I am working on NFS packet capturing for NFS version3 protocol. In one
>>of the scenarios, I tried opening a very big file and in this case the
>>file data was transferred from server to client in several chunks.
>>
>>I observed there were some 'Continuation' RPC payload sent from server
>>to client which carry file data. But even in Wireshark this doesn't
>>decode any other fields apart from the file contents.
>>
>>Could someone please advice how client knows which particular file a
>>specific 'continuation' packet belongs to? The packet doesn't even
have
>>the filehandle/program version data.
>>
>>I have attached the trace file.
>>
>

--
Thanks,
Nilesh

RE: 'Continuation' packets in case of NFS READ.

[Tayade, Nilesh]

> From: Lyle Seaman [mailto:lyleseaman@gmail.com]
> Sent: Thursday, October 14, 2010 5:35 PM
> To: Tayade, Nilesh
> Cc: linux-nfs@vger.kernel.org
> Subject: Re: 'Continuation' packets in case of NFS READ.
>
> Sorry, that was imprecise of me.  I ought to have said "it's an RPC
function".  Distinguishing between the end of one RPC and the next is
easy with UDP.  For TCP it's done with an end-of-record marker.  See the
RFCs.  RFC1057 is the one I remember. Maybe there's been an update, but
that's a good place to start.
> 

Sorry, if question is not clear or I am unable to interpret your
response and cluttering the mailing list. I shall also go through the
RFC1057.
What I wanted to know is -

If I have file1 on mountpoint-1 and file2 on mountpoint-2. Both these
mount points reside on same server and the respective file size is also
big. If we look at the packets for these mount point access, we can see
source port for packet of mount-1 same as that of packet of mount-2
(Ofcourse, NFS port 2049 will remain same, but the other port used for
setting up the connection also remains same).

So if the 'Continuation' chunk comes, how does the client know which
file it belongs to? The RPC packet doesn't have much info and TCP/UDP
packets will show same ip-port pair.


--
Thanks,
Nilesh

Re: 'Continuation' packets in case of NFS READ.

[J. Bruce Fields]

On Thu, Oct 14, 2010 at 08:30:53AM -0400, Tayade, Nilesh wrote:
> > From: Lyle Seaman [mailto:lyleseaman@gmail.com]
> > Sent: Thursday, October 14, 2010 5:35 PM
> > To: Tayade, Nilesh
> > Cc: linux-nfs@vger.kernel.org
> > Subject: Re: 'Continuation' packets in case of NFS READ.
> >
> > Sorry, that was imprecise of me.  I ought to have said "it's an RPC
> function".  Distinguishing between the end of one RPC and the next is
> easy with UDP.  For TCP it's done with an end-of-record marker.  See the
> RFCs.  RFC1057 is the one I remember. Maybe there's been an update, but
> that's a good place to start.
> > 
> 
> Sorry, if question is not clear or I am unable to interpret your
> response and cluttering the mailing list. I shall also go through the
> RFC1057.
> What I wanted to know is -
> 
> If I have file1 on mountpoint-1 and file2 on mountpoint-2. Both these
> mount points reside on same server and the respective file size is also
> big. If we look at the packets for these mount point access, we can see
> source port for packet of mount-1 same as that of packet of mount-2
> (Ofcourse, NFS port 2049 will remain same, but the other port used for
> setting up the connection also remains same).
> 
> So if the 'Continuation' chunk comes, how does the client know which
> file it belongs to? The RPC packet doesn't have much info and TCP/UDP
> packets will show same ip-port pair.

If the two mountpoints are sharing the same tcp connection, then the
server will only transmit one RPC reply at a time.  So "chunks" from the
two replies won't be intermingled.

--b.

Re: 'Continuation' packets in case of NFS READ.

[J. Bruce Fields]

On Thu, Oct 14, 2010 at 03:48:39AM -0400, Tayade, Nilesh wrote:
> Hi,
> 
> I am working on NFS packet capturing for NFS version3 protocol. In one
> of the scenarios, I tried opening a very big file and in this case the
> file data was transferred from server to client in several chunks.
> 
> I observed there were some 'Continuation' RPC payload sent from server
> to client which carry file data. But even in Wireshark this doesn't
> decode any other fields apart from the file contents.
> 
> Could someone please advice how client knows which particular file a
> specific 'continuation' packet belongs to? The packet doesn't even have
> the filehandle/program version data.
> 
> I have attached the trace file.

Without looking at the trace: usually, if it's a complete trace,
wireshark will first show you each individual tcp segment, just labelled
as something like "rpc continutation data", then it will show you at the
end a frame with the actual READ request, the fully assembled data, and
somewhere in the packet-details pane a list of the frame numbers from
which that was assembled.

So you'd want to look for that final frame with the READ reqeust, and
the filehandle on that READ, and then figure out which file that
filehandle was for.

--b.