Speed problem - smbclient doesn't send duplicate ACKs in case of pacekt loss

Derrell.Lipman at UnwiredUniverse.com Derrell.Lipman at UnwiredUniverse.com
Mon Jan 3 20:48:48 GMT 2005

Richard Sharpe <rsharpe at richardsharpe.com> writes:

> On Mon, 3 Jan 2005, Christopher R. Hertel wrote:
>> > Understood: I meant the interaction was with the code that pretended
>> > to be NBT.
>> Hmmm...  but that, in and of itself, shouldn't have any impact on the
>> behavior at the TCP layer.  I think the key is the (mostly)
>> request/response nature of the protocol, as someone else posted.
> Yes, I have asked for a capture of the effect. I suspect that the last
> segment of each READ is slow in being sent :-) However, the capture will
> tell us more.

On a related note...

If the application doing the sending/receiving is using signals for any
purpose, there is a bug in the select() code in samba3 which causes select()
to be re-called with the original wait time rather than the original wait time
minus the amount of time that has already been waited, if select() is
interrupted due to signal.  This means that it's actually possible to never
return from the internal function waiting for data, if signals occur regularly
enough (approximately once every few seconds, IIRC).  This primarily affects
receiving of data (or rather timeouts while awaiting receipt of data), not
sending, so is not likely the cause of the OP's issue.

I have a fix for this along with all of my other libsmbclient additions and
fixes.  I'm pretty happy with my test results (no known problems) at this
point, so I think it's time to package this stuff up for you (Richard) to
check in, if you deem it acceptable.  I'll try to do that this week.  I need
to make sure I've got an up-to-date source tree to make my patch from.
Hopefully there haven't been too many changes to the libsmb and lib
directories in the past couple of months.



More information about the samba-technical mailing list