P
Primoz29
Guest
Hello to everyone!
I'm working on a TCP/IP communication for communicating between industrial robot controller and regular PC, so basically I'm working on a client which will be the part of a program running on a PC.
I did some research and find the event driven asynchronous client example on Daniweb (https://www.daniweb.com/…/user-friendly-asynchronous-event-…). So my client is based on that class with minor changes, like no receive timeout, because if the machine is idle I will not get any messages for a long time.
I tested my client against SocketTest 3.0. At normal conditions everything works fine, but because the software will be used in industrial environments the possible failures needs to be handled correctly and that's what I was excepting from the code.
So I did some further testing...
1. Close server when client is still open and connected.
After a short period of time the ConectionStateChanged event is triggered. The actual event is triggered because of error detected in function cbDataReceived. So is it expected that the absence of the server is detected in the receive part of the code?
2. Disconnect the ethernet cable.
There is actually no reaction to that, even the send command goes through with no problem. So if I press the send test button n times and send x data while cable still unplugged nothing will happen. Then if I plug the cable back nothing will happen until I press the send button again. Then the server will receive x data, n+1 times.
I'm apologizing for my possible bad terminology. My profession is not a computer engineering. I had to know how things works in TCP/IP, but that was a few years ago and it was mostly based on theoretical aspects.
I'm open for any suggestions. Is the Daniweb class solution the right way to do it? How to handle all the problems that can occur with a connection the right way? If there are any libraries available (even the commercial ones) that will help solve me the problems feel free to write them down.
Thank you very much for help in advance.
Continue reading...
I'm working on a TCP/IP communication for communicating between industrial robot controller and regular PC, so basically I'm working on a client which will be the part of a program running on a PC.
I did some research and find the event driven asynchronous client example on Daniweb (https://www.daniweb.com/…/user-friendly-asynchronous-event-…). So my client is based on that class with minor changes, like no receive timeout, because if the machine is idle I will not get any messages for a long time.
I tested my client against SocketTest 3.0. At normal conditions everything works fine, but because the software will be used in industrial environments the possible failures needs to be handled correctly and that's what I was excepting from the code.
So I did some further testing...
1. Close server when client is still open and connected.
After a short period of time the ConectionStateChanged event is triggered. The actual event is triggered because of error detected in function cbDataReceived. So is it expected that the absence of the server is detected in the receive part of the code?
2. Disconnect the ethernet cable.
There is actually no reaction to that, even the send command goes through with no problem. So if I press the send test button n times and send x data while cable still unplugged nothing will happen. Then if I plug the cable back nothing will happen until I press the send button again. Then the server will receive x data, n+1 times.
I'm apologizing for my possible bad terminology. My profession is not a computer engineering. I had to know how things works in TCP/IP, but that was a few years ago and it was mostly based on theoretical aspects.
I'm open for any suggestions. Is the Daniweb class solution the right way to do it? How to handle all the problems that can occur with a connection the right way? If there are any libraries available (even the commercial ones) that will help solve me the problems feel free to write them down.
Thank you very much for help in advance.
Continue reading...