| Dart Home | PowerTCP Sockets for .NET | Custom Development | Reply | PowerTCP Sockets for .NET (Secure and Standard) Topics | Forums |
| Author | Forum: PowerTCP Sockets for .NET (Secure and Standard) Topic: Losing Data upon disconnect from remote host |
| anengin From: Farmington Hills, MI USA Posts: 7 Member Since: 08/25/03 |
posted August 25, 2003 5:22 PM We seem to be losing data with the .NET version of the TCP control. We have a client that opens a connection and sends a message to a remote host and expects to receive two messages back. The remote host sends both messages and then terminates the connection. (Apparenly the termination is not very gracefull since the client receives the exception "An existing connection was forcibly closed by the remote host.") But only one message comes thru the EndReceive() event and the other message appears to be lost. At least we can't figure out how to receive it and it doesn't matter if we use synch or asynch receive. Is there any help you can offer. This has been working fine for years with the ActiveX version of the control. Thanks in advance. -Bill |
Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted August 25, 2003 6:52 PM Do you have a server I could connect to? I could write a test server, but chances are it will work and that won't help you figure out what's going on with yours. |
| anengin From: Farmington Hills, MI USA Posts: 7 Member Since: 08/25/03 |
posted August 26, 2003 12:16 PM I have a server but you would have to connect using our VPN and it might change the timing. I suspect the remote host is sending the second message and then immediately sending a close(abort). The client end receives the second message then the close(abort) and generates an exception for the close(abort) before calling EndReceive() to deliver the second message. I know it’s legal for the sending end to purge unsent messages when told to close(abort). I don’t know if the receiving end should do that. Can you check to see if it is possible to lose (or purge) received but undelivered messages on the client if a close(abort) arrives. Is there anything I can do to insure I get any messages received? Thanks in advance. -Bill |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted August 26, 2003 3:59 PM When the close "arrives" the connection is gone, but if the close was graceful, any data sent prior to the close would be received first. I have an idea that might help. Try modifying our echo server sample so that instead of echoing, it sends out the same two strings your server sends, then does a close. Now connect to it with your client and see if it still fails. If it does, send the server and a stripped down version of the client to support@dart.com so that we can look at it. |
| anengin From: Farmington Hills, MI USA Posts: 7 Member Since: 08/25/03 |
posted August 28, 2003 10:27 AM I tried your idea and will send the code. I couldn’t reproduce the problem with the .NET echo server. But I was able to reproduce the problem using the Dart echo server from an ActiveX version. I modified the server to echo two messages and then close(abort). I delayed the close(abort) until I knew the messages had time to be sent before the close(abort). On the .NET client side, if I read() the messages before the close(abort) there is no problem. If I attempt to read() the messages after the close(abort), an exception is thrown and the messages that came in before the close(abort) can’t be read. I also tried using an ActiveX version of the client. The ActiveX version of the client will read() the messages either before or after the close(abort). This difference in the way the two version work is going to greatly affect our conversion to .NET. It would be better if they worked similarly. |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted August 28, 2003 10:46 AM Actually that's not a valid test. If you are doing an Abort then by definition the connection is severed. If you do a Close does it work OK? |
| anengin From: Farmington Hills, MI USA Posts: 7 Member Since: 08/25/03 |
posted August 28, 2003 2:36 PM The test is valid to show there is a difference in the way the Dart product works between the ActiveX and .NET versions. We want to migrate our Dart ActiveX controls to .NET and this inconsistancy will break our code. Of course the link is severed on an abort. That is not in question. The question is: do you still have an obligation to deliver any messages received prior to the abort. The ActiveX version does. The .NET version does not. Which one is working correctly? What does the TCP spec say? Thanks in advance. - Bill |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted August 28, 2003 2:52 PM As far as I can tell from your description, the server is causing the problem by aborting rather than closing. Since I can't have access to the server I have no way of knowing for sure though. As far as the control goes, we give you whatever comes through from Winsock in the order it comes in. Isn't there some way that you can set up a server outside the VPN for test purposes? |
| anengin From: Farmington Hills, MI USA Posts: 7 Member Since: 08/25/03 |
posted August 29, 2003 11:07 AM I'm sure it would be better for the server not to abort the link after sending the messages. But I don't have any control over that. The com version of the product receives the messages anyway. The .NET version does not. I've sent zip files that demonstrate this using an echo server that can run on your pc so you won't have to use ours. Please let me know how I can receive all the messages sent prior to the abort or if that is not possible with the .NET version. Thanks. -Bill |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted August 29, 2003 12:24 PM To eliminate our product from the loop, I did a test with windows Telnet and connected to your server. I typed "x" and I got back "x" and the connection closed. Next I changed your server to do a Close(False) and as expected I got "xx" before the close. I honestly don't know why the old com control works. It may be some kind of timing hiccup that allowed it to work by accident. The bottom line is that the .NET product is working properly. It's your server that is not. If you try with Windows telnet you will see what I mean. |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted August 29, 2003 12:42 PM Further info: Even with the old com app the test only works if the client is run on the same machine as the server. If I move your client test to another machine the behavior is exactly the same as it is in .NET By the way, is this server something commercial or did you write it? |
| anengin From: Farmington Hills, MI USA Posts: 7 Member Since: 08/25/03 |
posted September 3, 2003 9:51 AM When you ran the server on a different machine how did you verify that all messages were actually transmitted to the client and not aborted on the server side? To perform that test try modifying the server to echo back 10 messages and abort. Check the wire with a sniffer to see if 10 (or some number of) messages got transmitted and acknowledged before the reset. Then see if the old client with the activex control receives all messages transmitted. Compare that test to see if the .NET version throws away any messages transmitted. My tests show the activex version behaves differently than the .NET version. |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted September 3, 2003 10:02 AM There's no need to go through all that. If the server aborts then you are going to get unpredictable results. Again, the bottom line is that the server should not be aborting. That is the whole problem. |
| anengin From: Farmington Hills, MI USA Posts: 7 Member Since: 08/25/03 |
posted September 3, 2003 10:43 AM Our existing apps will break if we migrate from your activex to your .NET version of TCP. In the past we've purchased a number of your products and purchased support contracts while performing development. We'd like to migrate to .NET now and perform that development. We need to know if we have to look elsewhere for a new vendor since there is a behavior difference in your products. I am correct in assuming you'll stand by the claim your activex version works by accident, and you claim our server is the problem (which has been communicating for years with VB, Java, Cobol, C++ and others [very predictably])? Sounds to me like you've made up your mind not to bother with this customer anymore and point the finger elsewhere. Sad Support Service. Bye Bye |
Alex Gladshtein From: Rome, NY USA Posts: 131 Member Since: 12/27/00 |
posted September 8, 2003 12:58 PM Hello, One of our technical support representatives spent several hours looking at your situation. Unfortunately, the code you sent us that simulates your situation demonstrates an improperly functioning server. For us to accurately see the problem, we would have to communicate with the server directly. Based on what has been provided to us so far, we can only conclude that the problem is on the server level, and not on the client. Our .NET TCP level code is the underpinning of all our .NET products, and none of our users have reported any TCP-level problems that would indicate we are improperly handling communications on the lower level. Best Regards, Alex Gladshtein Product Manager |
| Reply | PowerTCP Sockets for .NET (Secure and Standard) Topics | Forums |
This site is powered by
PowerTCP WebServer for ActiveX
|