Is your VB software up to date?? (Note that this is NOT causing your problems; it's just something that could cause you problems in the future as you succeed with your servent!)

FIX: Winsock Control Leaks Memory When Unloaded
Last reviewed: February 18, 1998
Article ID: Q171843
The information in this article applies to: Microsoft Visual Basic Professional and Enterprise Editions for Windows, version 5.0

SYMPTOMS
The Winsock control may cause the system to lose memory and system resources, eventually causing the system to stop responding due to running out of memory.

CAUSE
System resources are not properly replenished when a Winsock control is unloaded from memory. If your application often loads and unloads a Winsock control, you may eventually experience this problem.

STATUS
Microsoft has confirmed this to be a bug in the Microsoft products listed at the beginning of this article. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available. This bug was fixed in Visual Studio 97 Service Pack 3.

Workaround
You can load a fixed number of Winsock controls, or a Winsock control array, on program load and only unload them on program shutdown to work around the memory leak problem. This approach is similar to implementing a Winsock server in SDK using a fixed-sized thread pool and is a more scalable solution than loading a new Winsock control to handle each new client connection. Under the one control per request model, if there are a large number of clients making connections to the server at the same time, the server will soon have too many threads to function at all.
Having a fixed "pool" of Winsock controls can ensure that the server functions properly under a relatively heavy load. A large number of simultaneous client connections will not be able to bring down a server machine. If there are unused controls left in the Winsock control pool when a client connection request comes in, you will assign one control from the pool to handle the client request. After the client request is served, the control is "returned" to the pool. If a client request comes in and all controls in the pool have been assigned out at the moment, you will have to choose to either have the client wait until there are available free controls in the pool, or accept the connection request right away, send a busy message, and then close the socket.
If you are planning a server that could experience really heavy loads, the Winsock control may not be the best tool to use. You should consider overlapped socket I/O with Windows NT I/O Completion Port in a C/C++ SDK program.



Thank you for buying Micro$oft! Don't ya love it!?