OldVB6
asked on
WinSock error: 10055 - No buffer space available
Hi All,
I have an app that uses 9 winsock controls in an array to communicate with 2 types of hardware.
Basically due to limitations of the hardware I have to maintain a continuous connection with all devices to monitor and control the devices. Although all aspects of the application fundamentally work, I receive the WinSock: 10055 - No buffer space available after 12 hours or so.
I have been looking for information on this error and see that most people suggest create 1 winsock control at design and the rest at runtime, will this really solve the issue? or is there a better way to manage the buffer.
Running VB6, sp6
Cheers
I have an app that uses 9 winsock controls in an array to communicate with 2 types of hardware.
Basically due to limitations of the hardware I have to maintain a continuous connection with all devices to monitor and control the devices. Although all aspects of the application fundamentally work, I receive the WinSock: 10055 - No buffer space available after 12 hours or so.
I have been looking for information on this error and see that most people suggest create 1 winsock control at design and the rest at runtime, will this really solve the issue? or is there a better way to manage the buffer.
Running VB6, sp6
Cheers
ASKER
Thanks for the comment, hadn't come across anything that explained the difference between design and runtime creation.
In the data_arrival procedure as far as I understand it does retrieve all bytes received..
wsEth(Index).GetData strData, vbString, bytesTotal
How would you test that I am retrieving all the data from the buffer?
The fact that I would still have one control created in designed time, wouldn't it ultimately raise an error as its buffer would potentially fill up. Really surprised there isn't a way to clear the buffer maually..
In the data_arrival procedure as far as I understand it does retrieve all bytes received..
wsEth(Index).GetData strData, vbString, bytesTotal
How would you test that I am retrieving all the data from the buffer?
The fact that I would still have one control created in designed time, wouldn't it ultimately raise an error as its buffer would potentially fill up. Really surprised there isn't a way to clear the buffer maually..
As you are uing GetData, you are cleaing buffer. Do you have this for any winsock control ?
ASKER
All winsock controls are in one array and all data arrival events are processed using the above syntax.
If GetData does clear the buffer, would that suggest a memory leak in the control itself, I know many people mention memory leaks in the winsock control, but thought it had been dealt with.
If GetData does clear the buffer, would that suggest a memory leak in the control itself, I know many people mention memory leaks in the winsock control, but thought it had been dealt with.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Currently testing a version of the app that is only using dynamically created winsock controls, but currently it appears to be chewing up 4k of ram every 30 sec or so once connected.
Well i have looked around for some good info for the API, but struggling to find much relatively recent documentation. Any suggestions, haven't had the need for much API integration, mostly use com controls.
OldVB6
Well i have looked around for some good info for the API, but struggling to find much relatively recent documentation. Any suggestions, haven't had the need for much API integration, mostly use com controls.
OldVB6
4K is the typical size for socket buffer. When you finish using a socket, do you close it ?
ASKER
Well this is an issue, the hardware I am interfacing with will not accept connections for up to 60secs after a disconnect. But the scope of this project requires a status update every <20 secs, which basically means a continuous connection. Rather frustrating.....
Maybe you are using winsock to access to a web server. If this web server is yours, you can customize this max time connection. But configuration of this isdepending the type of web server you are using.
ASKER
Sadly the hardware is actually base stations in a communications rack, it is stated the base stations will not check for incoming connections for up to 60secs after a disconnection, even the manufacturers software has the same limitations.....
If those 4k lumps of memory are being lost then I guess the program is creating new sockets and not closing the old ones. Does the status update process create new sockets every time? Do the base stations drop the socket after each update?
I can't think why closing the sockets is necessary, it would just waste time (unless the base stations are dropping the sockets). You should be able to keep the socket open as long as you want assuming you remove data from the buffer when it arrives.
I can't think why closing the sockets is necessary, it would just waste time (unless the base stations are dropping the sockets). You should be able to keep the socket open as long as you want assuming you remove data from the buffer when it arrives.
ASKER
Basically the system connects to the hardware and the socket is not closed until the app is closed. I have so far created the controls during runtime and tried using csocketmaster as a class for the API calls. But the issue remains.
I would of expected a continuous connection and retrieving all data received from the buffer would take care of the memory consumption. Very frustrating, although ultimately the hardware is forcing the situation.
Love to hear any other comments in regards to this.
Thanks for the comments so far...
I would of expected a continuous connection and retrieving all data received from the buffer would take care of the memory consumption. Very frustrating, although ultimately the hardware is forcing the situation.
Love to hear any other comments in regards to this.
Thanks for the comments so far...
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The data received is of varying lengths, the code always retrieves all data in the buffer. No errors are occuring and there is no change in memory consumption between creating the controls at design time, runtime or using the csocketmaster class.
Apart from the Ethernet coms side of things, this is really quite a basic app. Not much happening besides displaying the state of the hardware.
Will just have to keep experimenting, will be looking closer at the class module api calls and see if I can purge the buffer manually......
Apart from the Ethernet coms side of things, this is really quite a basic app. Not much happening besides displaying the state of the hardware.
Will just have to keep experimenting, will be looking closer at the class module api calls and see if I can purge the buffer manually......
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Issue was in a third party control, the experts help was great, but ultimately it was resolved without a specific solution from them.
Thanks for the points and for explaining what the problem turned out to be.
Also ensure you are getting all data received by any socket, because if you don't get it, the buffer for that winsock will grow until its limit, which seems to be the problem.
Regards.