On Tue, Apr 01, 2003 at 09:40:06AM +0800, [EMAIL PROTECTED] 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/ -)----- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/ -)----- [EMAIL PROTECTED]