| Dart Home | PowerTCP Winsock for ActiveX | Custom Development | Reply | PowerTCP Winsock for ActiveX Topics | Forums |
| Author | Forum: PowerTCP Winsock for ActiveX Topic: Winsock stops receiving |
| chasey chase@inspirednetworking.com From: Jersey City, NJ USA Posts: 11 Member Since: 11/03/00 |
posted May 27, 2003 12:41 PM Tony... I have noticed a disturbing feature of winsock that relates to intermittant outages that I've been experiencing recently... Essentially clients connected via the tcp winsock will stay connected, but all receives are stopped. There is NO indication anything is wrong, its just NOT receiving anything. This behavior is not easily reproducbile since it is intermittant in nature... I have found if a machine's cpu will max out for some period due to heavy load, the connected sockets will get stuck, and reception is stopped. To obviate this problem, I set a timer in the program and on a tick of the timer, I send the program to the receive event, and presto the socket frees up and we are back in business... I thought winsock did this sort of thing automatically ... or at least used to... Regards, |
Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted May 27, 2003 12:51 PM Unfortunately, we won't be able to correct the problem until you can give us the steps to duplicate it. Please let us know if you find a way. |
| chasey chase@inspirednetworking.com From: Jersey City, NJ USA Posts: 11 Member Since: 11/03/00 |
posted May 27, 2003 2:23 PM Tony, Perhaps I can ask an alternative but related question... I remember early on when I first started using winsock, it would often enter the Receive event even when there was no data to be had... I asked you about this at the time, and you said the purpose of this was to keep things moving in the socket.... I am now having to imitate this behavior with the use of a timer in my application... Do you care to comment on this behavior and whether it is tunable at the socket level ? Has this behavior changed in the last 12 months ? Thanks in advance.... |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted May 27, 2003 2:52 PM I'm not really sure what you mean. The Receive event should only fire if there is data to be received. I also don't know what you mean by "I am now having to imitate this behavior with the use of a timer in my application" |
| chasey chase@inspirednetworking.com From: Jersey City, NJ USA Posts: 11 Member Since: 11/03/00 |
posted May 27, 2003 3:15 PM Perhaps you are not aware... but at one time the Dartsock would fire "receive" events even when there was nothing in the buffer... The purpose of these event firings... was to keep things moving in the socket... (or so I was told at the time)... Cheers |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted May 27, 2003 3:29 PM I found the post where I said that and to be honest I don't remember why I said it. It looks like something that was going to be fixed, and that was nearly 3 years ago, so I have to assume it was. Regardless, the event should not fire to "keep things moving" if you are always receiving the data. If you supply a receive event, and then don't receive from within the event, the event will continue to fire until you do call receive. That may be what you are seeing. |
| chasey chase@inspirednetworking.com From: Jersey City, NJ USA Posts: 11 Member Since: 11/03/00 |
posted May 27, 2003 3:45 PM ahhh yes ... it was quite a long time ago... but it stuck in my mind anyway.... The problem is of course the Recieve event is NOT getting fired, and the socket appears hung though it is connected. I put a button in the app that calls the recieve avent manually, which in turn looks at the receivebuffercount... the act of looking at the receivebuffrcount then frees the socket for more communication... Its interesting to note that all the events are simply queued up... and nothing is lost even if it takes me a half hour to free things up... cheers |
| chasey chase@inspirednetworking.com From: Jersey City, NJ USA Posts: 11 Member Since: 11/03/00 |
posted June 19, 2003 8:01 AM Tony, I'm wondering if this intermittant problem of the socket freezing during periods of intense activity... Is due to the installation of Macafee Virus Scan software on the machine in question ? Can you please tell me what promlems if any you have encountered with this ? Thanks in advance... |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted June 19, 2003 9:08 AM Sorry, but we have had no reports on anything like that. |
The_King From: Cedar Falls, IA USA Posts: 17 Member Since: 10/10/02 |
posted September 22, 2003 11:46 AM I am now having this same problem with my Winsock TCP control. All I have been able to tell is that my Winsock control will not fire it's receive event when the packet is over 1200 characters. Is this possible? and if so where can I change a setting to be able to accept larger files? Myles |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted September 22, 2003 11:54 AM Please tell me how to duplicate the problem. If what you say is true, you should be able to use the TCP client to connect to the debug server and send 1200 bytes. |
| The_King From: Cedar Falls, IA USA Posts: 17 Member Since: 10/10/02 |
posted September 24, 2003 3:16 PM Tony: I am sorry but what the State was telling me my tcp control was doing was incorrect. What my control is doing is that it will connect to the State server, send it's information then the State sends back an ACK message and I have to ACK that message with one of my own. Intermitantly (of course) the control will, connect to State server, send information, disconnect, reconnect,(sounds like a reset of the connection actually) and in so doing will miss the ACK message from the state. It most of the time works but sometimes will do this a couple times a day and then work fine for a week. The_King |
| jcooper From: Bethlehem, PA USA Posts: 2 Member Since: 11/10/03 |
posted November 10, 2003 4:29 PM I'm having a similar problem with the recieving end simply stop taking in messages. We have a PowerTCP C++ driver talking with a PowerTCP VB Winsock driver, and what seems to happen is the VB end stops taking in messages, however it continues to send messages, and the C++ end continues to recieve messages and TRIES to send messages to the VB app. When we looked at the C++ side, the Dart driver was continuously buffering all the messages we were trying to send, as they were not going out. Chasey, let me know if this is the same problem you're having. It wasn't clear which side of the connection the messages were getting backed up on, the sending or recieving end. Thanks in advance guys. |
| rklenotiz From: Rochester, NY USA Posts: 19 Member Since: 08/08/03 |
posted November 11, 2003 12:42 PM Just posted on this...I am seeing the same situation. |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted November 11, 2003 12:50 PM Several people have reported this, but we have been unable to duplicate the problem. As soon as you narrow it down, please let us know. |
| jcooper From: Bethlehem, PA USA Posts: 2 Member Since: 11/10/03 |
posted November 11, 2003 3:43 PM It's EXTREMELY obscure, almost impossible to duplicate. It happens often enough that it's consistent (i.e. the VB end stops receiving) but we cannot force it to happen. I ran a stress test on 2 PC's and bombarded the connection with data overnight and the error did not occur. The scenario I told you about is a C++ end of the driver and the VB end. Both are in non-blocking mode, and both are configured to keep the connection alive. The C++ end is running on a separate thread, and the VB app waits for an Event to be risen to accept the data. Right now we're implementing a fix on the VB end to try retreiving the message manually if we haven't gotten the event in a while. I'll post again if that fixes the problem. Thanks again. |
| rklenotiz From: Rochester, NY USA Posts: 19 Member Since: 08/08/03 |
posted November 11, 2003 3:55 PM We are working on a workaround that involves a timer. There doesn't seem to be another other choice. This does occur at least once a day although there do not appear to be any obvious conditions which cause it to occur. I have watched this closely and I do see the "ReceiveBufferCount" increasing slowly as data comes in but the receive event never fires. Eventually the count reaches the max (our case 8192) and then nothing further appears to happen. I too have run this overnight and it won't necessarily fail. Sometimes it will fail less than a minute after the connection is opened. Have also noticed that data sometimes gets garbled too, which should not happen with TCP. |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted November 11, 2003 3:57 PM Neither of these things should be happening. I would sure appreciate it if someone figures out a way to reproduce this problem so that we could fix it. |
| rklenotiz From: Rochester, NY USA Posts: 19 Member Since: 08/08/03 |
posted November 11, 2003 4:00 PM Have tried to put together a small project to simulate but, of course, that never fails. |
| ronid From: Migdal Haemek, Israel Posts: 14 Member Since: 12/20/02 |
posted December 11, 2003 3:02 AM Hello, Well sadly , I have to report the same problem. I have seen it when CPU was busy (100%) for a long time, and when several clients for connected to with different TCP connection to specific machine. I will try to reconstruct on a small program, Please, try to solve this problem as soon as possible. Thanks Roni |
| Van^ From: Blacksburg, VA USA Posts: 17 Member Since: 09/04/03 |
posted February 4, 2004 6:48 PM I may be experiencing something similar, but I'm not sure. My application will go to 100% cpu when transferring large amounts of data peer to peer over TCP and UDP. I was not contributing it to this control, but it may be the same thing you guys are experiencing. Both applications have dynamically created TCP/UDP objects and are both in asynchronous mode. I do not have any re-entrancy protection code placed around the send/receive events. I built a wrapper class around the TCP object which receives the control's events. It then tosses the data into a com object written in c++ that parses and buffers the incoming data to reassemble packets. One side note, all data types used with the controls are byte arrays within VB. Sometimes I do get a receive event that fires and I get no data after calling the receive function. -- Dave |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted February 4, 2004 11:00 PM We'll work on this via email after you send the info I requested in this thread: http://support.dart.com/postings?topicid=3902#15612 Thanks. |
| eMatters From: Melbourne, Austria Posts: 3 Member Since: 05/31/03 |
posted March 23, 2004 11:07 PM I also am having the same problem, but cannot narrow it down or reproduce it. I am connecting a VB6 app to a remote TCP server, sending a string of 96 characters and then receiving 167 characters. It often works for around 200 messages and then stops receiving. It still does send, though (which causes a HUGE problem as we don't get the response back from the server). Can anyone tell me how to creata a simple "If no response in 60 seconds then kick the tcp connection and go back to waiting" ?? Thanks Chris Dwyer eMatters |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted March 24, 2004 9:23 AM If you know exactly how the string should end, use the Search method to cause an error when the token is not received. If you know exactly how long the data is supposed to be, use the Fill method. Both of these methods will close the connection if the error occurs. |
| rklenotiz From: Rochester, NY USA Posts: 19 Member Since: 08/08/03 |
posted March 25, 2004 1:41 PM Suggestion. Since this seems to be happening for several of us, perhaps we can provide some info on our applications/environment to see if there is anything in common that we can focus on to reproduce this. The problem for us occurs quite frequently now. We are using a timer to "kick" the control and make it start generating receive events. Our info: VB6+SP5. CLient/server using TCP controls. Buffer size: 8196. Have timers in the application, have several 3rd party controls as well (none related to TCP functions). Problem occurs in a stand-alone EXE and the IDE. Windows 2000+all latest patches. Problem occurs on Server or Professional versions. ALl machines P4 class. Dell computers, various brands of NICs. Well, thats a start. |
| BrendanM From: Durban, South Africa Posts: 80 Member Since: 07/11/02 |
posted May 1, 2004 5:50 PM I can reproduce the problem. On my 2 TCP clients I am calling the Search method in a While loop from within the Receive event. I use the Search method because my TCP packet contains multiple messages which I want to extract one by one. I think this causes some type of re-entrancy problems on the Receive event which stops the other TCP Client from firing its own Receive event. If I use instead the Vb InStr function in the While loop to get my messages out of the TCP packet then no problems occur but it is very slow (guess the Search is optimised). Also that Receive event loves to fire with 0 bytes in its ReceiveCount. Tony if you give me an address I can send a small VB app that replicates it 100% of the time on my PC |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted May 1, 2004 7:01 PM See my reply in your other thread. |
| rklenotiz From: Rochester, NY USA Posts: 19 Member Since: 08/08/03 |
posted June 5, 2004 5:26 PM This problem has been haunting us for over a year. Have been trying to narrow down. This may be old news but it's all I have as of today: Sender: sends 100 bytes Sender: the Bytes accepted count is always different from what was requested when the error occurs. Error occurs randomly. accepted=tcp1.send array(), 100 Accepted will NOT be 100. But the sendBuffer=0. Receiver: Gets the # of bytes that were accepted. No other events fire. Nothing else is sent. Receiver's receiveBufferCount=0 after it accepts the data from sender. This is quite easily reproduced on a small project with an ARRAY on TCP controls. Sadly, we are looking at other products as this is a severe problem and seems not fixable. Dart products are easier to use than others but we simply have no choice. Best Regards, Rick |
| Tony Priest From: Utica, NY USA Posts: 8466 Member Since: 04/11/00 |
posted June 7, 2004 9:23 AM I'm having a hard time understanding what you are describing. I think at this point it would be best if you sent the sample app to us at support@dart.com Make sure the app is simple enough that I can understand what to do with it and that it does not contain any code that does not directly relate to the problem. |
| wkchung From: New York, NY USA Posts: 1 Member Since: 04/08/11 |
posted April 8, 2011 3:02 PM Has this problem been resolved or any updates relating to it? |
| Jamie Powell (Admin) From: Rome, NY USA Posts: 448 Member Since: 03/13/07 Extra Support Options Custom Application Development |
posted April 11, 2011 2:48 PM Thank you for your post. We have researched this issue and it does not appear to have ever been reproduced in our facility. We would be happy to re-open a support ticket if necessary. Please send reproduction steps to support@dart.com. Thank you. |
| BrendanM From: Durban, South Africa Posts: 80 Member Since: 07/11/02 |
posted April 12, 2011 12:20 AM Sadly both myself and rklenotiz back in 2002/3 could reproduce some of the issues but no-one at Dart asked for sample code ..... |
| chpw From: Germany Posts: 5 Member Since: 09/27/06 |
posted July 24, 2012 9:05 AM I've noticed exactly the same behaviour. A client sends data packets over an established TCP/IP connection. The controls receive() event does not fire but the data is available. Calling the receive(...) method finally delivers it and the receive() event fires for a while signalizing new incoming data. Investigating that further I found the following: 1.) The missed data packets are shown in a TCP/IP sniffer protocol made using wireshark 2.) The missed data packets are NOT shown in a trace generated by the controls trace feature until the receive(...) method is called 3.) The problem arises under Windows 7. The same application was running under Windows 2000 for several years without those problems I need help solving that problem because the customer is going to change all its machine using actual operating systems. Best regards, Chris Werner f+s software gmbh Berlin, germany |
| Nick B (Admin) From: Utica, NY USA Posts: 619 Member Since: 05/25/10 Extra Support Options Custom Application Development |
posted July 24, 2012 3:37 PM Hello, We've still been unable to reproduce the issue; if you can send in a self-contained project that can reproduce the issue, or provide specific steps that consistently reproduce the issue, we can start looking into it. |
| mhampton From: irving, TX USA Posts: 2 Member Since: 10/29/14 |
posted October 29, 2014 2:26 PM Add me to the list. We just upgraded from version 2.8.2.0 to version 2.10.2.1 hoping to resolve an issue with DEP on windows 7+ and now our program that uses this component stops responding after making a couple of calls to the server. Has anyone been able to create a stand-alone project that recreates this? |
| mhampton From: irving, TX USA Posts: 2 Member Since: 10/29/14 |
posted October 29, 2014 2:27 PM Forgot to mention that this is an activeX exe in single-use mode built in VB6 |
| BrendanM From: Durban, South Africa Posts: 80 Member Since: 07/11/02 |
posted October 29, 2014 2:40 PM Hi. If I recall tere was never a solution to this problem. All we did on our TCP connections was to use an ActiveX timer to call the receive. For example on TCP servers this gets done every 10 secs: For Each Child In DS.Children If Child.State = tcpConnected Then If Child.ReceiveBufferCount > 0 Then Call DS_Receive(Child) End If Next Child For TCP Clients: If RXBusyProcessing = False And TCP.ReceiveBufferCount > 0 Then Call TCP_Receive |
| Jamie Powell (Admin) From: Rome, NY USA Posts: 448 Member Since: 03/13/07 Extra Support Options Custom Application Development |
posted October 30, 2014 4:22 PM Thank you for your post. Unfortunately we have not yet received a project capable of reproducing this issue (either internal or from a customer). If you are able to do so, please feel free to send your project to support@dart.com for review. If not, perhaps you will find the suggestion posted by another forum user helpful. Regards, Jamie |
| Reply | PowerTCP Winsock for ActiveX Topics | Forums |
This site is powered by
PowerTCP WebServer for ActiveX
|