Win2k - no application can connect to server

[TemporalBeing]

I have a test environment where I have two computers - both running
Windows 2000 Professional SP3 - are connected directly via a cross-over
ethernet cable at 100 Mbps full-duplex. I have a server application
that I developed on one, and the client version on the other.

I was performing a stress-test over the weekend whereby the client
dumps a lot of data (35k units - each unit is on average between 10k
and 1 MB or so; size is randomly distributed to test the system) to the
server. However, on Saturday - while I was gone for the weekend, it's
an unsupervised test - the software stopped sending data and entered
its "retry" mode, where it has been until I found it today.

I tried to telnet to the server from the client system, and got a
failure. I tried it on the server system using both "localhost" and its
IP address and it worked fine. I also tried ftp'ing to the server from
the client using the Windows FTP command-line too, and got a "No
buffers available" error message. I then developed a little tool to
open a port and write a message to it, and got back the WSAENOBUFS
error message. So, I know this isn't just my program that is being
affected, however, I can't find anything in the event logs, or anywhere
else suggesting there is even a problem, or anything in the MS Kb about
it either.

Has anyone seen this kind of thing happen before? Does anyone have any
recommendations for how to try to solve the problem or find more
information on what the actual problem is?

(We're using SP3 because we wanted a clean install as would come
straight from MS and that's the CD we were given. These systems are
also not on our network, so they don't receive updates - they're purely
test systems and have nothing but a base install as is off the Windows
CD.)

Thanks,

Ben

 

[Alexander Nickolov]

This hints at some sort of leak in your server. The kernel is
starved for buffers. One possibility is leaking socket handles.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: (e-mail address removed)
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

 

[TemporalBeing]

Quote:

This hints at some sort of leak in your server. The kernel is
starved for buffers. One possibility is leaking socket handles.

Response:

The previous version actually used more handles than this version, and
it worked fine in the stress test. I will admit there are some handles
out, but they are not socket handles. (All of 1 socket open, as
reported by SysInternal's Handle program - it did say there were ~45k
event sockets open; we use to have about 90k handles - namely thread
handles - after the test and are now down to ~45k.) This also happens
on the client side, not the server side. (Sorry if I forgot to say
that.) The server itself is still happy to accept new clients.

The majority of the open handles are thread handles and event handles.
(The rest are in less than 20.) However, I've cleaned up the thread
handles all I can as they are generated from the CWinThread class when
AfxBeginThread is used, and don't seem to be cleaned up reliably or
predictably (rather) - they seem to be around 1500. I'm not sure why we
have all the event handles - but as I said, that hasn't changed since
the last version, and we are actually using less resources than a test
that did pass in the previous version. (Same computers were used for
that test, with the same installation.)

A reboot of the system did fix things, but I still can't figure out
what caused it. Just exiting the client software itself did not solve
anything, which usually does when it is a handle issue, or at least so
I've seen - as Windows will then usually clean up the handles that the
software fails to report were cleaned up (which an OS _should_ do).

BTW - telnetting from the server system to the server works just fine.
The problem is on the client system. I also restarted the server
severals time trying to solve it (for various reasons - both restarting
the software itself, and the entire server computer) but it did not
solve anything, so I know the problem is on the client side. (Again,
sorry for forgetting to clarify that.)

I will look into seeing if I can clean up the handles any more, but as
I said...the remaining handles are socket handles and there is all of 1
socket open.

TIA,

Ben

 

[Sergiu Cojocaru]

I have a test environment where I have two computers - both running
Windows 2000 Professional SP3 - are connected directly via a cross-over
ethernet cable at 100 Mbps full-duplex. I have a server application
that I developed on one, and the client version on the other.

I was performing a stress-test over the weekend whereby the client
dumps a lot of data (35k units - each unit is on average between 10k
and 1 MB or so; size is randomly distributed to test the system) to the
server. However, on Saturday - while I was gone for the weekend, it's
an unsupervised test - the software stopped sending data and entered
its "retry" mode, where it has been until I found it today.

I tried to telnet to the server from the client system, and got a
failure. I tried it on the server system using both "localhost" and its
IP address and it worked fine. I also tried ftp'ing to the server from
the client using the Windows FTP command-line too, and got a "No
buffers available" error message. I then developed a little tool to
open a port and write a message to it, and got back the WSAENOBUFS
error message. So, I know this isn't just my program that is being
affected, however, I can't find anything in the event logs, or anywhere
else suggesting there is even a problem, or anything in the MS Kb about
it either.

Has anyone seen this kind of thing happen before? Does anyone have any
recommendations for how to try to solve the problem or find more
information on what the actual problem is?

(We're using SP3 because we wanted a clean install as would come
straight from MS and that's the CD we were given. These systems are
also not on our network, so they don't receive updates - they're purely
test systems and have nothing but a base install as is off the Windows
CD.)

Thanks,

Ben

Can you check if your port is still openned ( netstat -a in console will
help you!)

 

[TemporalBeing]

If you are talking about the 1 socket that handles reported open, then
unfortunately I cannot now since I closed the software and rebooted the
computer; however, knowing how the program works, that port should have
been closed, and the server recognized it as being closed too - i.e. it
didn't record anyone as being logged in. If I see it again, I will
definately check that. I'm going to try the test again, identically -
but it'll be a few days before I'll have any results...

If you are meaning on the server (e.g. the port the server is listening
on), then yes - it was still open. There were no routing rules, port
closed, etc - just standard out of the box install of Win2k Pro.

 

[Alexander Nickolov]

It's not due to handles, it's due to kernel buffers in the TCP driver.
These are associated with sockets, that's shy I suggested looking
for socket leaks. These buffers are used for socket I/O - reading
and writing through sockets.

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: (e-mail address removed)
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================