Login  
Search All Forums
Dart Home | PowerTCP Winsock for ActiveX | Custom Development Reply | PowerTCP Winsock for ActiveX Topics | Forums   
AuthorForum: PowerTCP Winsock for ActiveX
Topic: tcpClosing/tcpClosed not being fired ?
roofrack
gary.roussak@tyrrellsystems.com

From: Leigh, United Kingdom
Posts: 23
Member Since: 06/08/06
posted July 2, 2009 12:22 PM

Hi,

I have a web server application written in VB6 which uses a PowerTCP Daemon control to hand off HTTP connections to a pool of 'worker' classes.

As each new connection is made, the worker class initializes with a unique id and gives itself a TCP control which handles the socket traffic - all fairly standard stuff.

In addition, I keep a little table of workers currently in memory. When I receive either a tcpClosing or tcpClosed event from the TCP control for that worker, I use it to mark the worker as 'dead'. I regularly scan the table and, if a worker has been dead for a few seconds (and thus hasn't been re-used), I remove that worker and its TCP control from memory to avoid excessive memory usage. I do everything by the book, i.e. close() calls, setting objects to nothing, and so on.

This all APPEARS to work just fine.

However, I also use those tcpClosing and tcpClosed events to control a different set of program resources -- to avoid lengthy explanations, lets just call them widgets. The reasoning seems logically sound - if I know when a worker and its socket are created (which I do), then I borrow a widget. If I know when a worker and its socket are destroyed (which I do via the tcpClosing and tcpClosed events), then I have the opportunity to be sure I return the widget.

However, what I'm finding is that, over a period of a few days execution, I am running out of widgets, i.e. I am occasionally not returning one I have borrowed.

I have looked at vast acres of logs to help diagnose the problem. The only thing I can think of is this: if the user drops their browser connection before my server finishes returning its HTTP response, then I see my TCP worker fire a 10054 error (VC reset by remote side). On this occasion, could it be that tcpClosing/tcpClosed never gets fired ? If so, this might explain the problem, because my TCP_Error event handler doesn't do any tidying up of the worker table I just described, and thus things would get out of step.

Can anyone confirm this behaviour of a TCP control ?

Thanks

Jason Farrar (Admin)

From: USA
Posts: 223
Member Since: 07/24/07

Extra Support Options
Custom Application Development

posted July 9, 2009 5:27 PM

I did some quick tests using the Web Server sample and couldn't reproduce the problem. I also saw the state being reported correctly in the state event and wasn't able to produce a 10054 (WSAECONNRESET)error.

At any rate, I would suggest that when you get this error you should close down the connection and do clean up as you would if the connection were closed.

------
-Non-current subscribers must contact sales@dart.com to update subscription and receive continued support as needed.
------

BrendanM

From: Durban, South Africa
Posts: 80
Member Since: 07/11/02
posted July 22, 2009 11:18 AM

Hi,
We have seen this type of behaviour with some of our customers. In some cases the tcpClosed event never fires and our application thinks the connection is still up & running. What we found was these customers were sending us data via a serial to TCP converter (a Moxa unit). To work around this we set the KeepAlive property after we have accepted their connection, and with the appropriate registry settings.
Reply | PowerTCP Winsock for ActiveX Topics | Forums   
This site is powered by PowerTCP WebServer Tool PowerTCP WebServer for ActiveX