Mail Archives: djgpp/2000/10/21/11:40:23
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--
- Raw text -