| Dart Home | PowerTCP Server for ActiveX | Custom Development | Reply | PowerTCP Server for ActiveX Topics | Forums |
| Author | Forum: PowerTCP Server for ActiveX Topic: Trying to find reason for 10053 in Server object |
| roofrack gary.roussak@tyrrellsystems.com From: Leigh, United Kingdom Posts: 23 Member Since: 06/08/06 |
posted February 3, 2011 6:52 AM Hi, We have a particular application which uses the Dart "Server for ActiveX" control. The version in use is 3.1.3.3 and, whilst this is admittedly not the very latest, the release notes do not seem to imply that the latest version might address the particular problem we are seeing. We have a number of instances of our application running and it only seems to be one particular customer site that is experiencing a problem. The nature of the application is straightforward. When it starts, a Dart Server object ("Server1") is set to listen on a given port number with 'ReuseAddress' set to its default setting of 'False'. On Server1_Receive, the child TCP socket receives the data and processes it. The data comes from a client application (also our software) on a remote host. The server application will start and typically run for weeks on end without a problem. But at this one customer, every few days (typically varies from 3 to 10), the Server1 object will report a 10053 error and thus, obviously, stop listening. We are trying to analyze what might be causing the problem at this one site. We have asked whether anti-virus scanners or firewalls might be getting in the way, but the answer is 'No'. We are getting the customer to investigate the Windows event log and any possible network infrastructure problems. The next time it happens, we also need to try tests like telnetting into the server port to see if it responds. Note that transmission from the client app to the server app is over ADSL Broadband routers, but we have this scenario elsewhere and it works fine. Does anyone have any ideas ? In terms of recovery, one thought is that, when we detect the 10053 error, we should attempt to get Server1 to start listening again. However, I don't know if this is a sensible approach, whether it will work, and the best way to implement it (perhaps a VB6 timer which checks the state of the server socket every so often ?). Thanks |
| Nick B (Admin) From: Utica, NY USA Posts: 619 Member Since: 05/25/10 Extra Support Options Custom Application Development |
posted February 3, 2011 9:41 AM Hello, As defined in the help documentation, this error code represents: "Software caused connection abort. An established connection was aborted by the software in your host machine, possibly due to a data transmission timeout or protocol error. FATAL." One of the possible causes (beyond firewall and AV software) is that too many clients may be trying to connect to the server, and your client's server machine can't handle them. Watching for the error code in error handling seems like it would be the best route. ------ |
| roofrack gary.roussak@tyrrellsystems.com From: Leigh, United Kingdom Posts: 23 Member Since: 06/08/06 |
posted February 3, 2011 10:03 AM Nick, Hi. Thanks for the reply. However, its really not a possibility. We know from the disk log of the server-side app that it is only the one instance of the client-side app that ever sends it data. And even then, the data is only sent every 30 minutes (the results of a real time monitoring process, which is only a couple of hundred bytes). You weren't to know that, of course. What it prompts to say, in fact, is that the 10053 never occurs DURING a packet transmission; it is typically somewhere in the middle of the 30-minute interval, when nothing is happening. |
| Nick B (Admin) From: Utica, NY USA Posts: 619 Member Since: 05/25/10 Extra Support Options Custom Application Development |
posted February 3, 2011 10:30 AM Might the client be connected, but not doing anything? This error shouldn't be thrown if there's nothing to abort. What OS is the server running on? Have you checked the version of all of the dlls on their machine? Maybe one or all are the correct version? ------ |
| roofrack gary.roussak@tyrrellsystems.com From: Leigh, United Kingdom Posts: 23 Member Since: 06/08/06 |
posted February 3, 2011 10:56 AM Yes, it is true that the client will be connected but only 'doing' two seconds of work every 30 minutes (i.e. sending a packet to the server). Maybe this is a weakness ? However .... The client-side app uses a Dart TCP socket. When the app starts, the TCP socket connects to the server-side IP address & port to make sure that the server exists. Then, whenever the client is ready to send something, it always checks the socket state and, if not connected, attempts to open the socket again before the send. Wrapped around the send is also an error handler so we can trap any failed sends and log them to disk. I'm trusting that the above technique allows for the fact that there's 30 minutes between every send. However, I'm beginning to wonder whether this pair of apps might function better together if they were both re-implemented as UDP ! The server side is Windows Server 2003. Checking all DLLs is obviously no small job.... |
| Nick B (Admin) From: Utica, NY USA Posts: 619 Member Since: 05/25/10 Extra Support Options Custom Application Development |
posted February 3, 2011 11:22 AM You may try modifying your client so that it connects to the server only when sending the data; that should at least mitigate the issue. Other than that, modifying the server to re-listen when the error occurs should resolve it as well. I'm sorry, I meant to indicate to check the versions of the Dart dlls. ------ |
| roofrack gary.roussak@tyrrellsystems.com From: Leigh, United Kingdom Posts: 23 Member Since: 06/08/06 |
posted February 3, 2011 12:07 PM Sure. Incidentally, I haven't mentioned that the server sends back a short packet to the client by way of acknowledgment, and it includes the message number that the client originally encoded in the frame. By doing that, the client gets positive confirmation that the packet it sent was received, rather than relying on an error trap not happening, if you see what I mean. With that in mind, we've been looking back thru' some older logs and found a different type of behaviour. We've now seen a case where the server is merrily logging the data it receives from the client, and sending back an ack packet, when suddenly the Server1.Receive event stops being fired. However, the server app is still running and hasn't reported any errors. See log extract at end. At the same time, the client continues to try sending out packets. The client log shows that the acks are no longer coming back from the server (confirming that the server is no longer responding) and yet, when the client calls Tcp.Send, no error trap is being generated. This is REALLY weird. Its like the client packets are going into a black hole -- but the client's Tcp.Send is happy, and continues to transmit at 02:39, 03:09, 03:39, etc...... Some hours later, the server then logs a pile of Child TCP socket connected/closed events. Here's what the server app logs: 01/02/2011 01:09:06:277 - Packet received 01/02/2011 01:39:05:341 - Packet received 01/02/2011 02:09:04:406 - Packet received ...then nothing until... 01/02/2011 20:41:31:855 - Child TCP connected 01/02/2011 20:41:32:027 - Child TCP closed 01/02/2011 20:41:32:792 - Child TCP connected 01/02/2011 20:41:32:808 - Child TCP closed 01/02/2011 20:42:30:933 - Child TCP connected 01/02/2011 20:42:30:948 - Child TCP closed 02/02/2011 08:00:24:847 - Child TCP connected 02/02/2011 08:00:24:988 - Child TCP closed 02/02/2011 08:00:31:613 - Child TCP connected 02/02/2011 08:00:31:628 - Child TCP closed 02/02/2011 08:00:36:691 - Child TCP connected 02/02/2011 08:00:36:691 - Child TCP closed 02/02/2011 08:00:41:831 - Child TCP connected 02/02/2011 08:00:41:831 - Child TCP closed 02/02/2011 08:00:52:878 - Child TCP connected 02/02/2011 08:00:52:878 - Child TCP closed 02/02/2011 08:01:02:456 - Child TCP connected 02/02/2011 08:01:02:472 - Child TCP closed 03/02/2011 10:18:34:029 - Child TCP connected 03/02/2011 10:18:34:217 - Child TCP closed Strange or what ? This is confusing the hell out of me! |
| Nick B (Admin) From: Utica, NY USA Posts: 619 Member Since: 05/25/10 Extra Support Options Custom Application Development |
posted February 3, 2011 1:33 PM Hello, That is very odd; unless we can reproduce this locally, I'm afraid we don't have any suggestions. ------ |
| Reply | PowerTCP Server for ActiveX Topics | Forums |
This site is powered by
PowerTCP WebServer for ActiveX
|