I have been trying to make this standalone matlab code that uses the TCP networking commands given by matlab. When I debug the code in the matlab enviornment it connects right away, but when I run it as a stand alone it takes forever to connect or does not connect at all. It basically becomes very unreliable during the connection set up. Once the connection is set up data is sent and received quickly without issue. Does anyone know why this is happening or have a way to fix this?
Related
I have a program using a bi-directional TCP socket to send messages from the host PC to a VLinx ethernet-to-serial converter and then on to a PLC via RS-232. During heavy traffic the socket will intermittently stop communicating although all soft tests of the connection show that it is connected, active and writeable. I suspect that something is interrupting the connection causing the socket to close with out FIN/ACK. How can I test to see where this disconnect might be occuring?
The program itself is written in VB6 and uses Catalyst SocketTools/SocketWrench as opposed to the standard Winsock library. The methodology, properties and code seem to be sound since the same setup works reliably at two other sites. It's just this one site in particular where this problem occurs. It only happens during production when there is traffic on the network and can lose connection anywhere between 20 - 100 times per 10-hour day.
There are redundant tests in place to catch this loss of communication and keep the system running. We have tests on ACK messages, message queue size, time between transmissions (tokens on 2s interval), etc. Typically, the socket will not be unresponsive for more than 30 seconds before it is caught, closed and re-established which works properly >99% of the time.
Previously I had enabled the SocketTools logging capabilities which did not capture any relevant information. Most recently I have tried to have the system ping the VLinx on the first sign of a missed message (2.5 seconds). Those pings have always been successful, meaning that if there is a momentary loss of connection at a switch or AP it does not stay disconnected for long.
I do not have access to the network hardware aside from the PC and VLinx that we own. The facility's IT is also not inclined to help track these kinds of things down because they work on a project-based model.
Does anyone have any suggestions what I can do to try and determine where the problem is occurring so that I can then try to come up with a permanent solution to this issue rather than the band-aid of reconnecting multiple times per day?
A tool like Wireshark may be helpful in seeing what's going on at the network level. The logging facility in SocketTools/SocketWrench can only report what's going on at the API level, and it sounds like whatever the underlying problem is occurs at a lower level in the TCP stack.
If this is occurring after periods of relative inactivity, followed by a burst of activity, one thing you could try doing is enabling keep-alive and see if that makes any difference.
Scenario:
I am using boost::asio::tcp protocol between 2 peers connected over the network. My code runs on Linux, macOS and iOS.
I have a Watchdog ping-pong mechanism implemented on my both sides to check that the socket connection is okay between the peers. This is done by sending a dummy packet every 2 seconds which I think is a known approach.
Challenge:
But, is there are way I can avoid writing this watchdog myself?
Is there a way to enable asio/TCP stack itself to do this for me and trigger an event right when the socket connection is not okay? I have been trying to understand the kepp_alive functionality in TCP stack because it seems to have answer to my question?
But then again it looks like I can tweak the keep_alive parameters but boost::asio::tcp does not seem to give me an API to do that.
Question:
Will tweaking of the keep_alive parameters help me acheive my goal? My goal is to get a notification from the asio or TCP stack when the socket is not connected anymore due any wierd reasons on the peer side. Note that peer can go down in a weird way like kernel panic or something really crazy.
Just setting socket.set_option(boost::asio::socket_base::keep_alive(true)); does not seem to help. The default time running on Linux is too high. I do get a notification even after many minutes after event of peer going down.
I've been scouring for an hour to find an answer on this one -- got close, but not quite there.
The issue is that I'm using this basic approach to implement a socket server, but (of course) it hits the line with the accept() and freezes there. What I want is to be able to have the user click a checkbox control in a Tkinter GUI and have the socket be listening, or closed, on demand. A flag/semaphore to control the while loop doesn't help by itself; in concert with that, I also have to send a 'dummy' connection to get the server to iterate through the loop instead of just sitting at the accept() forever. Which would work of course, but it just feels klunky.
After much effort I found this article but the solution -- while it's a nice one -- still seems to still depend on the connection handler to raise the event that triggers the exit. Which in turn means that I'd still need some kind of dummy connection to make it happen, instead of being able to interrupt/destroy/whatever the server socket while it's stopped at the accept().
So is there any way to get around needing a connection before you can get the server socket closed?
I have written one client socket program using linux sockets only. Here is the information giving picture what I am doing in my program
Creating the socket
Making connection with server socket
assigning that socket to read set and exception set for select.
using the select method giving the timeout value NULL in a separate thread
Server is running in one external device.
this program is working fine for reading and all.. Now I am facing problem when I unplug the power cable of that device.
I assumed that when we remove the power cable of the device all the sockets will abruptly closed and connected client sockets will get read event. when we try to read we receive number of bytes read as zero that means connection closed by server.
But in my program when I unplug the power cable of the device, Here in my client program select is not coming out means client socket is not getting any event. I don't understand why..
Any suggestion will be appreciated on how we can come to know that connection is closed by server or any information on whats the sockets behaviour when shutting down the power supply.
I need your help, its very critical.
thank you.
When a remote machine is suddenly cut off the network (network cable unplug or power loss), there is no way it can inform the other side of the connection about that. What is more the client side that performs only reads from a half-open socket (like in your case) won't be able to detect this either.
The only way to know about a connection loss is to to send a packet. Since all data being sent should be acknowledged by the other side, TCP on a client computer will keep retrying to send an unconfirmed portion of data till the number of attempts is exhausted. Then a ETIMEDOUT error should be returned (via a socket that is expecting read events). You can create one more socket for sending these messages periodically to detect a peer disappearance (heart beat connection) on the client side. But all this retries might still take some time.
Another option could be to use SO_KEEPALIVE socket option. After some time a connection has been idle, TCP starts sending probe messages to the server and can detect its disappearance. The default values for idle item are usually enormously huge, so they need to be modified. Some of other parameters that might be related (TCP_KEEPCNT, TCP_KEEPINTVL, TCP_KEEPIDLE). It appears, this option might be implemented differently on different systems or can be simply absent.
I've never personally tried to solve this problem so all this is just a bunch of thoughts that might give some ideas. Here is one more source of ideas.
We're attempting to network between an iphone and a computer (windows 7) using TCP/IP over Wifi. We are having a lot of difficulty setting up this basic network and we were hoping to get some guidance.
Server side:
Currently, we are trying to use MATLAB's tcpip protocol to set up the connection on the computer. We have determined the IP addresses of the phone and the computer and we picked a port number (501), that we are trying to read and write from. We allowed that port number in windows firewall.
In simulink we set up a TCP/IP send block to send out a constant, by double-clicking on that block and selecting the "verify address and port connectivity" button we get the error message:
"The remote address '140.180.....' has been found. However, we are unable to connect to the server at the specified port.
Specify a different port or wait for the current port to become available"
We have tried other port numbers, but gotten the same message.
We have tried using an ad hoc connection between the computer and the iphone to the same effect.
We have also tried other MATLAB scripts to set up the connection (e.g. http://www.mathworks.com/matlabcentral/fileexchange/24524) but we always get and error in the connection
Finally, we tried sending and receiving info over TCP/IP with the same computer using two MATLAB instances running in parallel, but we generally get the same error message.
We even tried UDP...no dice.
Client side (iphone)
We're using NSStream exactly as per this tutorial: http://www.devx.com/wireless/Article/43551/1954
The stream is opened upon a toggle action, and we immediately send a string to the server. We also tried sending a continuous sequence of data with the run loop. One strange bit of behavior is that, after the stream is open for a little while (~1 min), the handleEvent method does seem to get triggered (implying something is received from the server??) because we get a log message corresponding to case NSStreamEventErrorOccurred.
We think the issue lies on the server side, but really don't know enough to be sure or to debug properly. Any help would be very much appreciated.
A long overdue answer to this one: don't network with Windows. We eventually thought to switch over to a mac and lo and behold everything worked properly.