hi OFs …
i’m stuggling with a problem that i can’t understand …
i’ve added / hacked a ofxTcpServer to Duration / ofxTimeline project from @obviousjim so that data driven by tracks is send from a server to the clients via TCP …
basically i’ve copied the ofxTCPServerExample …
for(int i = 0; i < bangsReceived.size(); i++)
/// SEND TO ALL TCP CLIENTS !!
for(int i = 0; i < tcpServer.getLastID(); i++)
if( !tcpServer.isClientConnected(i) ) continue;
tcpServer.send(i,addressWithoutSlash + " " + bangsReceived[i].getArgAsString(0));
What is driving me crazy is that when i shut down a client that is already connected (as ex. the ofxTCPClientExample one) … most of the times, the server can’t detect that the client has “closed” connection, so the above code crashes on tcpServer.send … and the app is crashing …
Anyone has experienced this kind of problems with ofxTCP ? I’ve seen some messages in the forum about similar issues, but most are from 2011 and seemed like solved …
I’ve experienced the same issue with the ofxTcpServerExample and ofxTcpClientExample … I’m on OSX and OF 0.84 .
If i create several client apps that get connected to the server (as the example does), when i kill any of the processes abruply (like a Force Quit) the server hangs …
This is what i got on the console …
[ error ] ofxNetwork: /Users/eloimaduell/Desktop/OF_MAC14/OF_084/addons/ofxNetwork/src/ofxTCPClient.cpp: 227 ENOTCONN: trying to receive before establishing a connection
drawing client : 1
Also i got to this error & so crash …
[ error ] ofxNetwork: /Users/eloimaduell/Desktop/OF_MAC14/OF_084/addons/ofxNetwork/src/ofxTCPManager.cpp: 286 EPIPE: this socket was connected but the connection is now broken
that arise in the line :
Is this expected to happen ? So it’s me breaking the rules ? Shouldn’t TCP connection stonger to survive that some it’s clients has “died” or “exploted” ? Or there’s a bug ? Or there’s something wrong on the examples ?
Is there any workarround ? It’s quite frustrating to have an app that could crash at any point if some of the clients (that in my case are Raspbery Pis) dies …
@eloi Did you manage to fix this??
I’m having the same issue, driving me crazy as well. When I set a breakpoint in the close() function of ofxTCPClient it doesn’t crash.
I’m on OSX 10.10.3 and oF 0.8.4. Should we add this to github as an issue?
I also get the EPIPE exception and crash:
[warning] ofxNetwork: /Users/javier/Programacion/OpenFrameworks/openFrameworks/addons/ofxNetwork/src/ofxTCPManager.cpp: 196 EINPROGRESS: the socket is non-blocking and the connection could not be established immediately
[ error ] ofxTCPClient: setup(): couldn't connect to 192.168.1.107 9000
[ error ] ofxNetwork: /Users/javier/Programacion/OpenFrameworks/openFrameworks/addons/ofxNetwork/src/ofxTCPManager.cpp: 310 EPIPE: this socket was connected but the connection is now broken
[warning] ofxTCPClient: send(): client disconnected
Yes I’ve faced this issue. What I usually do is that when I close the server, in the close() or exit() function I send a message to close the tcp connection before i close the tcp connection on the server itself. I listen to the message on the client and close the tcp client. The client is no longer listening to the server when it closes so no crash…hopefully
I didn’t try @usama_ solution, but in my case i couldn’t avoid the crash …
It makes TCP stuff very unusefull as it’s crashing when some clients dissapears and reappears …
Very confusing and strange that this is actually on the ofNetwork core … ?¿
I found this on stack overflow (link). It seems to work.
Include this line in your setup:
SIG_IGN means ignore.
Actually scratch that. I’m still getting crashes. But it went 7hrs without crashing, which is why I thought it was safe.
Try with v0.9.3. I think at some point they updated the TCP and I’ve found that it has much better handling for connection issues like devices not being online or locked up and not crashing.
That’s good to know, but I can’t confirm yet. When I upgraded to 093 it
caused my frame rate to drop to around zero, CPU to max out. I’m not sure
why, it’s a large code base. I’ll have to split some parts out and test in
isolation to see what is causing it.
In the mean time I just dropped back to 092 and accepted the intermittent
i had the same problem, and some others with receiving the buffers timely.
this also fixes the issue of connected clients blocking the server port if the server goes down and back up. (not sure if you even had this problem yet).
i took the code in the of core and changed it around to suit my needs, maybe you find it helpful too.
i think it’s almost the same to use as the core tcpserver.
consider it under the same license as OF.