Hello,
I am employing an HTTP server built into a VB6 application, and I have it built around Winsock components that transparently handle all the protocol below the HTTP layer (namely, TCP and IP). The server typically serves an HTML page containing 10-30 PNG images, plus other stuff. The client browser receives the HTML page and comes back with requests for the page's content, requesting 5-6 images in parallel. My VB6 server application is designed to handle any number of simultaneous requests, using methods taken from the web and described below, and all usually goes well. But far too often, multiple image requests will fail, and the browser will display broken links in place of the images. When this occurs, the server application's Winsock components fire no events, indicating that the problem is occurring at the TCP/IP levels, transparent to the application. Using a network protocol analyzer (WireShark), I determined that network transactions are indeed occurring for all the failed images, but that the one Winsock component assigned to listen to the port and hand off connection requests to an array of other Winsock components is replying to the initial TCP SYN packet with an ACK/RST packet instead of a simple ACK packet. In response, the client backs off for ~500 msec and then retries. Sometimes the second try is successful and appears normal to the application, but sometimes the second attempt, and even a third, is rejected. On the third failure, the browser abandons the request and declares the link broken. The behavior is the same with IE 8, Firefox 15, Chrome 21, Safari 5 and Opera 12.
I thought that perhaps the failure occurs because the server could not respond quickly enough to connection requests (via the Winsock's ConnectionRequest event) due to CPU load, and it was rejecting when some buffer became full, but when I added a tight 2-second loop in the ConnectionRequest event handler, or the DataArrival event handler, or in a separate VB6 app, the problem was no worse -- the response was just slower. Also, I should point out that when the problem occurs, it occurs on a burst of up to 5-6 images (which just happens to be the number of parallel TCP streams that the browsers set up).
As I said, the method for handling multiple simultaneous requests was modeled after multiple designs I found on the web: one Winsock component is dedicated to listening to the assigned port (which is not the usual port 80, since my ISP blocks that port as a guard against a particular virus), and one of an array of Winsock components gets handed the request for actual processing. The array size usually grows to 5-6, which is apparently the number of parallel TCP streams the browsers set up.
Here are the relevant event handlers:


Private Sub WS_HTTP_Base_ConnectionRequest(ByVal requestID As Long)
Dim SocketIndex As Integer
Static NoOfSockets As Long ' VB6 initializes to zero by default
Do ' used merely to provide exit point for Exit Do -- never loops
For SocketIndex = 1 To NoOfSockets ' search for an idle (closed) socket
If (WS_HTTP(SocketIndex).State = 0) Then Exit Do ' (State = 0) means closed
Next
NoOfSockets = NoOfSockets + 1 ' no idle (closed) socket available, so add one to the array
SocketIndex = NoOfSockets
Load WS_HTTP(SocketIndex)
Loop While False ' i.e., never loop
WS_HTTP(SocketIndex).LocalPort = 0 ' I tried omitting this line or setting it to a fixed port; no difference
WS_HTTP(SocketIndex).Accept requestID ' this hands off the request to one of the array of Winsock components
' Dim I: For I = 1 To 100000000: Next ' this 2-second delay does NOT exacerbate the problem; it just slows the load
End Sub

Private Sub WS_HTTP_DataArrival(Index As Integer, ByVal bytesTotal As Long)
' code here handles the data according to HTTP protocol...
End Sub
Private Sub WS_HTTP_SendComplete(Index As Integer)
WS_HTTP(Index).Close ' I tried having this command just here, or just in the "Close" event, or both; no difference
End Sub
Private Sub WS_HTTP_Close(Index As Integer)
WS_HTTP(Index).Close ' I tried having this command just here, or just in the "SendComplete" event, or both; no difference
End Sub


What I need to know is:
1) Under what circumstances will the Winsock control reply to a connection request with a TCP ACK/RST?
2) Which circumstance causes this particular issue (network congestion, port conflicts, etc.)?
3) could I prevent it by using calls to the Winsock control that the Windows Platform SDK provides, in place of the VB6 Winsock component? Perhaps the Windows SDK Winsock allows more control.

After weeks of wrestling with this problem, any help would be greatly appreciated!