Sender: richdawe AT bigfoot DOT com Message-ID: <39F1B782.5186F686@bigfoot.com> Date: Sat, 21 Oct 2000 16:34:26 +0100 From: Richard Dawe X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.17 i586) X-Accept-Language: de,fr MIME-Version: 1.0 To: Peter Remmers CC: DJGPP newsgroup , libsocket Mailing List Subject: Re: libsocket: problems with receiving large amount of data References: <8srp88$7tj$01$1 AT news DOT t-online DOT com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD7B8C539F123B0DB175F48DE" Reply-To: djgpp AT delorie DOT com This is a cryptographically signed message in MIME format. --------------msD7B8C539F123B0DB175F48DE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello. Peter Remmers wrote: > I'm currently writing a telnet program and now have the problem > that when I receive a relatively large amount of data (such as > with "ls -lR /") after a few seconds it hangs, because > the library thinks there is no data to read. It sounds like you've hit the 32K maximum total data transfer limit. See bugs.txt from the 0.8.0 pre 1 distribution: Winsock 2.x Interface - csock ============================= [snip] * SOCK.VXD seems to have problems receiving/sending more than 32K through a stream socket. The symptoms are that the DOS box blocks in SOCK.VXD (i.e. Ctrl+C will not kill the program and the DOS box has to be forcefully closed). > select() hangs (or times out), recv() either blocks (blocking > mode) or fails with EAGAIN (nonblocking). Just out of interest, how do you know what the library is doing? I mean, have you set breakpoints, etc. inside it? There are actually two different kinds of blocking behaviour that you will see with libsocket: * A call blocks within libsocket. This should be interruptable with Ctrl+C. * A call blocks within a virtual device driver (VxD). This is uninterruptable. If the call hangs, the DOS box hangs and you have to kill the program by closing the DOS box. Where possible, libsocket tries to block within itself. In the case of reads, this means that it does not call the VxD until it knows some data is ready (by calling the VxD's "select" call). The problem with reading greater than 32K with SOCK.VXD is very annoying. I think there is some kind of deadlock within the VxD's circular buffer code. You say that non-blocking recv() returns EAGAIN. This is interesting, because in my experience of doing non-blocking reads, it hangs the DOS box. I use httpget, httpgetn as examples of this. Retrieving a document < 32K works fine; just above 32K blocks. Reading data in small chunks with/without pauses does not seem to help either. > On my linux box (where I do the "ls -lR /") netstat says the > send-Q of the connetion fills up to like 40k or so. This confirms my suspicion that you've hit the 32K bug. > I'm using Win98SE with libsocket 0.8.0p1 and CODA's sock.vxd. I have the same configuration as you. If you don't mind sending me your source, I could try debugging libsocket with it. In the meantime, there's not much you can do. I'm not a VxD programmer, I don't have the software to fix it and the Coda folks stopped replying to my mails a long time ago. There may be some hope - WSOCK2.VXD's interface is known. It's just a question of me sitting down and writing some code, but I probably won't have time for that until December. BTW there are some DNS problems due to a bug in gethostname() in libsocket 0.8.0 pre 1. A symptom of this is that doing a lookup on say 'foo' does not work, unless you put a 'search' line in resolv.conf for your DNS domain. To fix this, edit hstnm.c and remove the check for size > MAXHOSTNAME at the start of gethostname(). I hope to release libsocket 0.8.0 STABLE within the next month or so. It will still be affected by the SOCK.VXD bug, but it should otherwise be OK. Bye, Rich =] -- Richard Dawe [ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ] --------------msD7B8C539F123B0DB175F48DE Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIHFQYJKoZIhvcNAQcCoIIHBjCCBwICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BY0wggLMMIICNaADAgECAhB2D2twnX9wqhegGKLtJkJmMA0GCSqGSIb3DQEBBAUAMFgxJzAl BgNVBAoTHkJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYzEtMCsGA1UECxMkQlQgVHJ1 c3R3aXNlIC0gQ2xhc3MgMSBJbmRpdmlkdWFsIENBMB4XDTAwMTAxNTAwMDAwMFoXDTAxMTAx NTIzNTk1OVowggERMScwJQYDVQQKEx5Ccml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGMx LTArBgNVBAsTJEJUIFRydXN0d2lzZSAtIENsYXNzIDEgSW5kaXZpZHVhbCBDQTFGMEQGA1UE CxM9d3d3LnRydXN0d2lzZS5jb20vcmVwb3NpdG9yeS9SUCBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVs bCBTZXJ2aWNlMRUwEwYDVQQDEwxSaWNoYXJkIERhd2UxIzAhBgkqhkiG9w0BCQEWFHJpY2hk YXdlQGJpZ2Zvb3QuY29tMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAMJ3LQ1fxlYpzsChuJ16 J9dwyZIkhexC8uW2RGyxJVOG6643weIDoATk515qu8G91CS85rLDRFIB0u2N4ezCUCkCAwEA AaMgMB4wCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCB4AwDQYJKoZIhvcNAQEEBQADgYEA llCoL5Afa66m9bxGh/gMgwUCCCOb6DdKHmJw9Q5h0xoEHuHOcEEjNPqQug5ZQaKioEIJM7DS gsuSPrEy5Z521OzNWxN8nRv9YAlV3fVHQxcNlsjaAZru6zJxZ0+0uAKKFKOjJLTdfXFUqdcH kcY2syIZo6DRSIap9pCqC+HYOoIwggK5MIICIqADAgECAhEA0zBJnvKZLVDb03kHStQNPTAN BgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x NzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkwHhcNOTgwMjEyMDAwMDAwWhcNMDMwMjEyMjM1OTU5WjBYMScwJQYDVQQKEx5Ccml0aXNo IFRlbGVjb21tdW5pY2F0aW9ucyBwbGMxLTArBgNVBAsTJEJUIFRydXN0d2lzZSAtIENsYXNz IDEgSW5kaXZpZHVhbCBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0QG30oEW28L0 Z/5fC03tfZ+a2ahBQYehZ6hrcb1PW6ZIXuqm5y8KpzYJ9rLhRkMA3BzH8eACTVhkn/qAJmqC m2GTDa7eueV8q6A/0I/p9KwahkjEgG4exysZ9svlo21+HWn0yFtrHAraKuNoZOPpFnNP5dOp AuObV5lKytU5AlkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYL YIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQBS Acma9vqkvYS4miXj6t5jPDVao9pIjdxWTjRoiRPRRi7wz0On9jUzqVK8sVcrPIpwxmvnlOyv jM8KpZaJVXECrgclfNlGR58eSiyTSHyBO0XUK4XLJkwkBXyBmiHc+32l5gvC+QXuGccUEdg8 WZ/OOeoRMbCdGuw1+LeE55h4JzGCAVAwggFMAgEBMGwwWDEnMCUGA1UEChMeQnJpdGlzaCBU ZWxlY29tbXVuaWNhdGlvbnMgcGxjMS0wKwYDVQQLEyRCVCBUcnVzdHdpc2UgLSBDbGFzcyAx IEluZGl2aWR1YWwgQ0ECEHYPa3Cdf3CqF6AYou0mQmYwCQYFKw4DAhoFAKB9MBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMTAyMTE1MzQyNlowHgYJKoZI hvcNAQkPMREwDzANBggqhkiG9w0DAgIBKDAjBgkqhkiG9w0BCQQxFgQUOpwftomRCJvDwO9t JgSlTjMQMj4wDQYJKoZIhvcNAQEBBQAEQKyZwHnvje2O14MvDEDRm1NbfDs6SnxSlDwD/W1d bXWHoffqnmdxx5xMCCcIL1qOe9nn1d+COzOlmqSJyITROgo= --------------msD7B8C539F123B0DB175F48DE--