From: Tim Uckun
>> It may just be me, but this sounds like a bug. Have you looked at the
>> tracker to see if it has already been reported? Since it appears you
can
>> reproduce it reliably, perhaps you should post it there so the
>> developers can take a closer look at it. If you go that route, I
suggest
>> using Wireshark to capture one or more sessions that lock up the
client
>> and attach the raw capture files onto the bug report. This will help
>> them identify the actual problem and insure the fix really works.
>
> I haven't done that because I thought I would post it here first and
> see if somebody had similar experiences.
>
> I can reproduce it fairly regularly although I have taken to logging
> out of the remote sessions immediately after I am done to avoid the
> problem. I'll install wireshark and see if I can get a capture
> tomorrow.
>
> To me the problem smells like a threading issue. The connection is
> timing out and blocking the entire app and the gui locks up until the
> timeout exceeds and the app is responsive again. Unfortunately the
> timeout seems to be set to something really long.
The default TCP connection timeout is around 3 1/2 minutes. This is left
over from the leased line and slow connection days when the protocol was
defined and has never been updated to match the reality of high speed
networks. This may be the timer it is waiting for. Some of the
MS-Windows network drivers in particular are notorious for locking up
the workstation while waiting for events that never happen. Losing a
remote shared drive you have mapped into often causes very similar
symptoms. But I am not one to speculate about the internals when I have
never looked at the code. I find it much better to report the symptoms
with as much supporting data as I can so the people that understand how
it works can do the diagnosis.
Bob McConnell