??????: When the keep-alive packet sent out,rfc1002 says different things!!

[Christopher R. Hertel]

On Tue, Apr 01, 2003 at 09:40:06AM +0800, Aladdin_Cai at asus.com.cn wrote:
> Thank you all.
> For the case 1.there will be many echo overhead. And I have no way to 
> know the server timeout when I am in client, so I can't determinate when 
> to send echo packet.

Well, it shouldn't really be needed anyway since the first packet of a 
READ RAW or WRITE RAW should reset the server timer anyway.  I thought of 
it as a way to force a timer reset, but it should not be necessary.

As for overhead, though, I was suggesting sending it just before the READ 
RAW or WRITE RAW request.  That would be minimal overhead.

> For case 2, I have though over it. suppose there is such a situation:
> when I WriteRaw data to server and server will send me a "writeRaw OK"
> response.And almost the same time,keep-alive is sent.Now I take the
> stuff out from socket buffer, which is a mixture of "writeRaw OK" and
> keep-alive packet.

...but they will be in sequence, not mixed.  The WriteRaw OK message will 
be a complete SMB message, so you will not have any trouble parsing them.
Just read the number of bytes specified in the NBT header's length field.

The READ RAW, as you point out below, is the real problem...

> And it is worse when it happens during the ReadRaw,
> as you know, the data in the ReadRaw has no protocol header, when a
> keep-alive packet is inserted into the stream, or if the raw data might
> be also something like {0x85 0 0 0},simply discarding will do the wrong
> thing. (although the possibility is very low.)

See, this is where I'm confused.  The initial SMB message (READ RAW or
WRITE RAW) sent to the server should reset the timer.  The timer should 
have a timeout on the order of minutes.  Even a READ RAW or WRITE RAW 
should be completed before the timeout, so there should never be a 
keepalive mixed in with the data.

I have never seen a READ RAW, though, so I don't know for sure how it 
works.  I know there isn't an SMB header, but is the NBT header also 
bypassed?  If it is, and if the READ RAW request doesn't reset the 
timer, and if the timeout is too short...then you're absolutely right.  
The keepalives will wind up in odd places in the data stream and mess 
things up.

I'd call it a bug, but I would have to see a trace before I would believe 
that Samba has this bug.  Samba is written such that it should complete 
one operation before starting the next, so even if we did fail to reset 
the timer the keepalive message would follow the READ RAW, and not be lost 
within it.

Chris -)-----

-- 
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org