OpenHome Forum
How do I reduce the probability of a socket timeout? - Printable Version

+- OpenHome Forum (http://forum.openhome.org)
+-- Forum: OpenHome (/forumdisplay.php?fid=1)
+--- Forum: Net (/forumdisplay.php?fid=5)
+--- Thread: How do I reduce the probability of a socket timeout? (/showthread.php?tid=1058)



How do I reduce the probability of a socket timeout? - dough - 12-10-2012 06:41 AM

Hello again,

My colleague is seeing a Socket Timeout error way too frequently on his wifi network. If I'm not wrong, the OhNetInitParamsSetTcpConnectTimeout function of the C API sets the duration of this timeout and defaults to 3 seconds. I have increased this duration to 5 seconds, but even at 3 seconds, it seems incredibly long for the device to respond to an action invoke. I am only Sync action invocations from the control point and, as far as I'm aware, they will just block until they get a response from the device. Does this mean that OhNet DV will make a http response to the Control Point to let it know to keep waiting?

This problem has yet to occur on my wifi network, so I'm guessing it is related to the traffic on the wifi network he is using.

I should point out that miniDLNA (Upnp media server) is also running on the same device as the ohNet device stack. I'm not sure if there would be a conflict of the listening ports, but I would like to hear your advice...

Also, since there is always a possibility of a socket timeout, can you offer any advice on how I should handle this at the control point?


Doug


RE: How do I reduce the probability of a socket timeout? - simonc - 12-10-2012 10:27 AM

There are a couple of places we may see timeout errors - during a tcp connection attempt or after a period of inactivity on a connected socket.
  • Timeouts during tcp connect are relatively short - 3 seconds by default as you say. This can be adjusted using OhNetInitParamsSetTcpConnectTimeout.
  • Timeouts due to inactivity on connected sockets are determined by the host's network stack but will be relatively long - probably several minutes.
Errors on tcp send due to wifi dropping are possible but I don't think would be described as timeouts.

Given this, I'd guess that your colleague is suffering from failed connections (each action invocation will involve the control point making a tcp connection to the device stack). Increasing the value passed to OhNetInitParamsSetTcpConnectTimeout will help reduce the instances of this. As would improving the quality of his wireless network. inSSIDer (from http://www.metageek.net/products/inssider/) can be useful in finding a clearer channel for a wifi network.

If that doesn't answer your question, can you give more info about how you're determining that errors are caused by socket timeouts please?