| Dart Home | PowerTCP Emulation for ActiveX | Custom Development | Reply | PowerTCP Emulation / Telnet for ActiveX Topics | Forums |
| Author | Forum: PowerTCP Emulation / Telnet for ActiveX Topic: Error #10060 in Non-Blocking Telnet App |
| Ron Sipherd From: Oakland, CA USA Posts: 11 Member Since: 11/06/03 |
posted November 6, 2003 12:54 PM I have a Visual Basic 6 application that uses the Dart Telnet control on a Windows XP Home system with a modem and dial-up Internet connection. The Timeout property is set to zero for non-blocking operation. Until about a week ago I was using a version of DartTelnet.dll and DartSock.dll with file dates March 23, 2000. After I downloaded and registered a newer version of the files (11/25/2002 for DartTelnet.dll and 2/28/2003 for DartSock.dll), I began to get intermittent errors immediately at connect time as follows: Error # 10060 The connection has been dropped because of a network failure or because the peer system failed to respond. Also caused when Connect, Send, Receive, Fill or Close methods are used with a Timeout parameter and the operation fails to complete within the specified number of milliseconds. The error appears to occur randomly; I can immediately restart my app and it will sometimes connect OK and sometimes not. Right now I work around the problem by just rolling the dice over and over again till it connects. Once it has connected, there are never any more problems of that kind in the program, at least till I disconnect and try to re-connect. I have not made any changes to the program itself, or to the system that I can think of. Would appreciate any suggestions on fixing this problem. It looks similar to the one just reported by lornemelnyk@shaw.ca, but different enough that I thought it should go in a separate topic (in my program it occurs instantly on executing the Connect method, not after a time lag). I was unable to reproduce it with the Dart telnet demo, but since it's intermittent and apparently random, I'm not sure if that says much; it hasn't occurred today in my program for the last hour or so either. |
Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted November 6, 2003 1:03 PM For something like that, I would need a way to duplicate the problem. Please try to narrow it down to a specific set of circumstances. |
| Ron Sipherd From: Oakland, CA USA Posts: 11 Member Since: 11/06/03 |
posted November 7, 2003 4:21 PM I have some more information. The program gets through the Connect method OK, but fails on a subsequent Search method after connecting. The actual code line is Ix = Telnet1.Search(CmRcvdStr, "ogin: ") where Telnet1 is the Dart telnet control. I also have a trace log of the program up to the failure. vbCrLf + "---> " precedes sent data and vbCrLf + "<--- " precedes received data. It's pretty ugly hex, but the clipboard drops lines if I copy it directly as ASCII: 3C 2D 2D 2D 20 FF FD 18 FF FD 1F FF FD 23 FF FD ; <--- ÿý.ÿý.ÿý#ÿý 27 FF FD 24 0D 0A 2D 2D 2D 3E 20 FF FB 18 0D 0A ; 'ÿý$..---> ÿû... 2D 2D 2D 3E 20 FF FB 1F 0D 0A 2D 2D 2D 3E 20 FF ; ---> ÿû...---> ÿ FA 1F 00 50 00 18 FF F0 0D 0A 2D 2D 2D 3E 20 FF ; ú..P..ÿð..---> ÿ FC 23 0D 0A 2D 2D 2D 3E 20 FF FC 27 0D 0A 2D 2D ; ü#..---> ÿü'..-- 2D 3E 20 FF FC 24 0D 0A 3C 2D 2D 2D 20 FF FE 23 ; -> ÿü$..<--- ÿþ# FF FE 27 FF FE 24 FF FA 18 01 FF F0 0D 0A 2D 2D ; ÿþ'ÿþ$ÿú..ÿð..-- 2D 3E 20 FF FC 23 0D 0A 2D 2D 2D 3E 20 FF FC 27 ; -> ÿü#..---> ÿü' 0D 0A 2D 2D 2D 3E 20 FF FC 24 0D 0A 2D 2D 2D 3E ; ..---> ÿü$..---> 20 FF FA 18 00 74 74 79 FF F0 ; ÿú..ttyÿð |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted November 7, 2003 4:31 PM It's failing in the option negotiation. All those characters you see are the server saying "I want to do this or don't do that" to which the telnet control responds with "Ok, I'll do that" Are you doing option negotiation yourself? Or do you have it set to AutoOption? |
| Ron Sipherd From: Oakland, CA USA Posts: 11 Member Since: 11/06/03 |
posted November 7, 2003 7:40 PM AutoOption is set to True for the Telnet control at design time, and not modified at run time in code. If the Search method blows up, my guess is the received data (if any) may not make it into the trace file; comparing the string to successful login traces, it looks the same up to the point where it failed. |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted November 7, 2003 11:29 PM It's the negotiation. If you decode all the WILLs and WONTs and DOs and DONTs in the trace you just posted, you should have your answer. |
| Ron Sipherd From: Oakland, CA USA Posts: 11 Member Since: 11/06/03 |
posted November 8, 2003 12:27 PM > If you decode all the WILLs and WONTs and DOs and DONTs in the trace you just posted, you should have your answer. I'm not sure I understand. I just compared the traces from a successful logon session with one that crashed, and up to the point of failure they are bit-for-bit identical. As I mentioned, this problem is new with the latest DartSock and Telnet DLLs in a program that has not been changed. |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted November 10, 2003 8:55 AM Is the machine available on the Internet so that I can try to get a login prompt? |
| Ron Sipherd From: Oakland, CA USA Posts: 11 Member Since: 11/06/03 |
posted November 11, 2003 6:40 PM Yes, the telnet server is <well.com>. Here's some more background. When the online form_activate event occurs, the following code runs in it: vvvvvvvvvvvvv Telnet1.Connect "well.com", 23 Do DoEvents If Telnet1.State = tcpConnected Then Exit Do Loop Do DoEvents Ix = Telnet1.Search(CmRcvdStr, "ogin: ") If Ix > 0 Then Exit Do Loop ^^^^^^^^^^^^^ So the Search method is the first telnet action following connection. It's only executed once; all later transactions use the Send and Receive methods but initially there is nothing to send, since the server issues the login prompt on connecting. Also, once the program gets past the Search above, it never fails later in the session with a 10060 or other telnet problem. So I'm guessing that there's something about the Search method, or else the fact that it's the first action after connecting, that triggers the error; and that upgrading from the March 2000 release to the current version of the telnet and Dartsock DLLs created a sensitivity to a condition that existed before occasionally but didn't cause an error. Thanks for your help with this. |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted November 11, 2003 10:54 PM The first thing I have to ask before I look further is why do you surround all the blocking calls with a doevents loop? That's not necessary and may very well be contributing to the problem. |
| Ron Sipherd From: Oakland, CA USA Posts: 11 Member Since: 11/06/03 |
posted November 13, 2003 7:12 PM I'm not sure what you mean by "blocking calls"; I have Timeout set to 0 for non-blocking operation. I was able to remove the Do loop from the Search method, but if I remove it from the Connect, executing the Search method gives me the error: 10057 Socket is not connected. A request to send or receive data was disallowed because the socket is not connected or allocated. Any other type of operation might also return this error. FATAL. In any case, the original code did work for about three years without trouble. |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted November 13, 2003 10:13 PM Sorry, search is usually used when blocking, so I assume you had timeout > 0. If you have timeout set to 0, then you should not be calling Receive until you get a Receive event. See the Tcp Client sample for an example of asynchronous non-blocking usage. |
| Ron Sipherd From: Oakland, CA USA Posts: 11 Member Since: 11/06/03 |
posted November 14, 2003 12:56 PM Thanks! I'll give that a try. I don't explicitly call the Receive method up to that point, but I take it that it's implied in the Search method? |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted November 14, 2003 1:55 PM Search is just a function that call receive over and over until the token is found. When using non-blocking mode, all receive related functions (Search, Fill, Receive) should be called only after getting a receive event. And only one call should be made in the event. |
| Ron Sipherd From: Oakland, CA USA Posts: 11 Member Since: 11/06/03 |
posted November 14, 2003 4:44 PM Here's what I did to ensure I wasn't running Search prematurely. Since I rely on code in the Receive event for some other stuff (the user can optionally stay online after the automated session is done and I unlock the keyboard), I just modified the Receive event to set True a Boolean variable to announce that received data is pending. Here's the new version, and (so far) it's run OK. Let me know if you see any problems with it. Thanks! Telnet1.Connect "well.com", 23 Do DoEvents If Telnet1.State = tcpConnected Then Exit Do Loop Do DoEvents If boRcvPndg = True Then 'if Receive event has fired boRcvPndg = False Ix = Telnet1.Search(CmRcvdStr, "ogin: ") If Ix > 0 Then Exit Do End If Loop |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted November 14, 2003 4:59 PM Personally I don't like any code that has: Do DoEvents Loop It's not necessary. All you are doing is making it block. Why don't you just set timeout to something greater than 0 whenever you need to block. If you need to mix blocking and non-blocking code then you should exit the Receive event if timeout > 0, this will avoid unintentionally receiving more than once. If you are having trouble understanding the differences between blocking and non-blocking take a look at the samples. The Telnet client is non-blocking, the AutoLogin sample is blocking. |
| Ron Sipherd From: Oakland, CA USA Posts: 11 Member Since: 11/06/03 |
posted November 16, 2003 12:47 PM > Why don't you just set timeout to something greater than 0 whenever you need to block I guess I didn't think of mixing blocking and non-blocking in the same app, or chose not to as a matter of simplicity or programming style. Looks like the new code solves the original problem - I must have been getting away with the timing issues under the older release of the DLLs. I think I understand the difference between the two modes. Since the initial receive up to the Login prompt is a small amount of data, I think the danger of multiple Receive events is small. Thanks again for your help! If I get into trouble again, I'll be back. |
| ali ali.a@galnet.dk From: cph, USA Posts: 13 Member Since: 11/06/03 |
posted November 21, 2003 6:24 AM i do confirm this problem after getting the problem randomly it gives me the same error while old files worked even with bad code i changed the code to the one as example on the telnet tool site but still it comes up randomly ! |
| ali ali.a@galnet.dk From: cph, USA Posts: 13 Member Since: 11/06/03 |
posted November 21, 2003 6:26 AM please ignore the first post *working remotly * i do confirm this problem after getting the update it randomly gives me the same error while old files worked even with bad code i changed the code to the one as example on the telnet tool site but still it comes up randomly ! |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted November 21, 2003 9:18 AM I'm sorry, but I don't understand what you are asking. Please start another thread and describe the problem you are having in more detail. Please make sure that you include the steps to duplicate the problem. |
| Reply | PowerTCP Emulation / Telnet for ActiveX Topics | Forums |
This site is powered by
PowerTCP WebServer for ActiveX
|