User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091017 SeaMonkey/2.0 If large TCPWindowSize is set in Windows XP registry TCP transfers cease after several seconds because of zero receive window size is indicated by receiving host in TCP headers. Transfer resumes after several seconds and data are successfully transferred but transfer ceases repeatedly always after several seconds. Interval is not constant. Problem has been observed for HTTP/FTP transfers as well as for IMAPS from Linux as well as Windows servers. It has been observed over corporate LAN, corporate high speed Internet connection as well as for home broadband connection (6M ADSL+WiFi). It seems ceasing of one TCP transfer affects other connections from the same instance of application - e.g. new page is not opened until primary ceasing (mail/file etc.) transfer doesn't resume. It has been observed in Windows XP Pro SP2 but probably happens in other versions of Windows XP as well. Data are transferred normally if relatively small e.g. 32kB TCPWindowSize is set. I think it doesn't necessarily happen over really slow link e.g. GPRS/EDGE (I haven't tested it) or over link with speed bellow some ratio to receiving host performance. Another important thing is that even TCPWindowSize is set to e.g. 100kB in Windows system and all TCP transfers initiated by other application has window size 100kB in TCP headers if buffer is empty but transfers initiated by Seamonkey has just 50000B (exactly - not 50kB). It seems Seamonkey doesn't support receive buffers larger then 50000B and if TCPWindowsSize is set to larger value buffers are even handled improperly what causes receive buffers are filled up repeatedly for certain period of time until they are emptied by application. Reproducible: Always Steps to Reproduce: 1.Set GlobalMaxTcpWindowSize and TcpWindowSize in HKLM\SYSTEM\CurrenConrolSet\Services\Tcpip\Parameters to large value e.g. 100kB or more in Windows XP 2.Restart system to apply changes 3.Start transfer of data large enough to be transferred minute or more over LAN or broadband line 4.Catch and observe TCP transfer with e.g. Wireshark Actual Results: Transfer ceases repeatedly due because receive buffers are filled up and zero receive buffer size. TCP receive window size is set to just 50000B if buffers are empty. Expected Results: Transfer is smooth receive buffers are emptied continuously. TCP receive window size is set up to TcpWindowSize value if buffers are empty.

> Actual Results: > Transfer ceases repeatedly due because receive buffers are filled up and zero receive buffer size. > TCP receive window size is set to just 50000B if buffers are empty. Can you get HTTP level/Socket level NSPR log of Sm with time stamp? NSPR_LOG_MODULES=timestamp,nsHttp:5,nsSocketTransport:5,nsHostResolver:5 > http://www.mozilla.org/projects/netlib/http/http-debugging.html > See bug 402793 comment #17 for timestamp

Build of Tb 3.0.4. > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 As seen in Bug 541367, Tb 3.0(1.9.1) properly behaved on dynamic TCP Window Size and used 128KB according to server's request(thus router's bug was exposed. see bug 541367 comment#17). Such functionality possibly doesn't work well if SeaMonkey 2, but I guess works well too with Sm 2. Is there any router problem with large TCP Window Size? Is your router torelant with large number of concecutive packets when TCP Window Size=100KB is used?