Thanks to Francois, Wilfried and Angus for your kind response.

For monitoring the MySrv application at service level, I have already spawning 
a process periodically to connect to MySrv and in case it fails, an alarm is 
triggered.  What I am trying to do is to find the root cause.

> You can have one TWSocket connect to another one within the same
> application. Just use a TTimer to do it periodically.
The reason why I don't want to debug by test connecting sockets is that MySrv 
is already creating/killing sockets intensively everyday.  Resources 
consumption is rather heavy and there happened several weeks before sockets 
were failed to created for Error 10055 - WSAENOBUFS: No buffer space available. 
 Doing more socket connections for test I am afraid will get the application to 
fail faster.

> It is likely the OS is out of resource, probably because there is a leak 
> somewhere. Very difficult to find actually.
I completely will not deny the possibility of memory leak.  But at the first 
place I would like to isolate the fact that socket listening is proper and 
unrelated to the problem

> There is no reason for a socket to stop listening.
These are very encouraging words that I love to hear

> So I'd suggest your monitoring service itself tries to connect to your
> listening socket once a minute sending dummy data, and then goes into a
> cycle of restarting the service or rebooting the server if there is no
> response over various intervals, I use five minutes for a restart, 30
> minutes for a reboot (after six restarts).
When the app failed it normally takes me 10 minutes to reboot (in case serious 
socket error like WSAENOBUFS), or less than one minute to kill/restart the app. 
 It depends on whether I am lucky or not, if the failure occurred at busy 
hours, even a two minutes service interruption will receive more than 10 
complaints from customers.  As I mentioned before, very demanding.  :~(

> it's unlikely to be an ICS problem, more likely a Windows update has 
> corrupted something in TCP/IP. 
Another good and encouraging thing I love to hear.  I used to do Windows update 
frequently (service is maintained at a backup server of course), but I find the 
wsock32.dll stuff has not been updated since 2003 (the app is being run on 
Win2k sp4)?

Now my thought (please don't mind if it is stupid), after having a glance to 
the WScoket source code.  There is a enum TSocketState to reflect the socket 
status (I think?).  If the TWSocket class is already getting the Windows socket 
status and indicates that by this enum value, then isn't it a way to check 
whether the socket is still listening?  If the enum is indeed the winsock's 
state, then either I can get what I expect, or the winsock says it is listening 
but actually it is not, then it is a winsock problem that I have nothing to do 

Please correct me if I am wrong.

Best regards,
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to