Winsock & Multithreading with Activex EXE

Ahh, this has been tried in a fashion. The main thread starts a listen-once worker. When that worker gets a request it accepts it and tells the main thread. The main thread starts a new listen-once to "catch" the next client.

If connections ever arrive rapidly you lose some of them.


If multithreading in a socket server has any advantage to a VB6 program, it is probably in keeping some worker threads to do "work." In other words use just one thread to "own" all of the sockets and manage communications, and dispatch any "heavy lifting" non-communication work like database activity, disk I/O, calculations, etc. to a worker.

This isn't so great through if your server mostly does file transfers. If one thread reads a lot of disk data and then passes it to the sockets thread to send it, you get eaten alive with the overhead of cross-thread marshalling of the data blocks.

You have a point there...

But if:
You're in a thread and the socket raises the ConnectionRequest event for an incoming connection.
Before accepting the request, the thread makes the main app run a new thread and gets a confirmation when the thread is up. At that point it would accept the connection and if there were other connections coming in at that moment, they would be queued and redirected to the other thread.
Because I know that winsock doesn't have a time-out when it comes to sockets that aren't open, but it does have a time-out when acceptance is pending.

Correct me if I'm wrong, but I think this is more or less the working of winsock.
Otherwise it should be :D

As soon as a listening socket is closed it's pending connection queue is discarded and all pending clients get a RESET or something sent back.

I suppose if the first socket listening on a port did not Bind to it, the second one might be able to start to Listen on the same port. That might work.

Hi dilettante

Did you ever get any further on your threaded MulTi Chat app?

Just curious

Quote:

---

Originally Posted by dilettante

Ok sports fans.

I am crying "Uncle" on this. I have tried to make a multithreaded VB6 chat server using the Winsock control. It works 99.9% (in other words, it doesn't work). ;)

It multithreads beautifully, with everything in a single process. Something people seem to like to think "can't be done" in VB6.


Symptoms
Clients can connect, get a server thread of their own, and get a response from the server. Then it falls over.

The client gets a Close event almost immediately, which it of course shouldn't unless I have some bizarre error in the client. However the client is almost unmodified from a basic client I have successfully used many times with a regular single-threaded server.

Oddly, the server Winsock controls still seem to think they are connected!

I've added code to display the State after this has happened, and sure enough it comes back as 7 (sckConnected). With some playing around I was on occasion getting an error in the worker threads' Winsock controls:

sckNotSocket 10038 The descriptor is not a socket


Guesses
I have come to the conclusion that either (a.) I have some bug I just can't see, or (b.) you can't Accept a requestID across threads much more reliably than processes!

Remember though, the server seems to successfully get a "greeting" message back to the clients after the Accept is done!!!

My guess is that the Accept actually works, but something on the order of a window message needs to come back to the listening socket to let it know the Accept actually happened (???). I tried Spy++ on the worker Form though and didn't see anything likely there in terms of messages.


Try It
To play with this, you need to compile both the server and the client, though the client can run from the IDE. Not the server though!

Also be sure to read the readme.txt for info on unregistering the server before each compile. This helps avoid registry clutter from creating new classIDs each compile (project has no compatibility).

Don't be afraid to use Task Manager to monitor the thread count of the server. As each client connects it should go up.

---

Hi all

I realize that this thread is really old but i came across the exact same problem.
I have a TCP server. I know the maximum number of clients but i dont know when they will connect to my server so when i start the server it loads a total of 100 activex instances.

In this instance there is a winsock control and a timer. The timer periodically orders the winsock to start listening and if the port is busy (another instance keeps it busy) it has an error control so the execution doesent stop.

So far it works great but when a massive connection request happens some clients are forcefully refused the connection.

Googling around i found this thread an i thought maybe someone has found a solution to that.

I really hope that someone would answer......

it would be easier to solve this problem if you guys attach a sample project you are working with.
That way we can individually play with it and probably come up with a solution.
remember that we all have different tools we are working with.

The solution is to create a dummy socket to accept the connection within the listing thread and then destroy the dummy socket before accepting it on another threaded. Use CopyMemory do destroy it so it dose not get the chance to send the connection close.

You have to accept it first with the dummy before the threaded socket.

Code:

---

Dim ServerSockets As New Collection
Public Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (Destination As Any, Source As Any, ByVal Length As Long)

Private Sub ListningSocket_ConnectionRequest(ByVal requestID As Long)
Dim mtSoc As Winsock
Dim dummySoc As New Winsock

    Set mtSoc = CreateObject("MSWinsock.Winsock")
    dummySoc.Accept requestID
    CopyMemory dummySoc, 0&, 4 'Destroy dummySoc
    mtSoc.Accept requestID
    ServerSockets.Add mtSoc 'Add to collection for safe keeping


Exit Sub

---

Assuming that your solution works, since 2005 finally someone posted a solution to this... it's been more than 9 years since I started the thread, and I am not using VB6 for many years!

Anyways... thanks for your reply & solution to this