Apple

This can be more a philosophical issue than a technical one.

Lets assume I connect to my home WLAN and connect to my server. Then I switch off the WLAN and go into some pubic space. I switch it on there.

Would you want this public space to be able to notice that you where connected beforehand to some specific server because you now send out the FIN packets?

Secondly, those FIN packets now come from another IP as your IP has changed so the remote would not detect them as correct. This would only work in a lab experiment because you connect from the same IP again.

I think what you see under Linux is simply the fact that the FIN packets already make it to the buffer in the kernel to be sent out and get stopped by a switched off WLAN interface and then the buffer gets flushed when you switch it back on. I think the MacOS X behaviour is correct. If the physical interface is gone, the buffers needs to be flushed as upon reconnection, your environment might be totally different.

Its not true that the "socket" remains open as the socket is the interface on your device towards the TCP connection. And if you close connection, you actually terminate the socket. This might not be true from the other side of the connection which has not noticed yet that the client is gone and will keep the TCP connection open for a while. This depends on the options used on the TCP connection. For example if you use TCP keepalives, the TCP stack sends data packets with zero bytes payload every once in a while keeping the connection "open" which results in the other end the capability to detect a dead connection by no longer receiving them. If we talk about mobile devices however this is costing money and battery life. So you have to be careful. As far as I remember such keepalives are set to something like 30 minutes under IOS.

To summarize: Your code on the server and the client side have to deal with network interruptions accordingly and be failsafe. This for sure means that on the server side you must be able to accept multiple concurrent connections in parallel even if you only expect one single device ever (a denial of service attack would be darn simple also) as upon reconnection, the previous connection could be considered still alive.

On 23 May 2014, at 14:45, airwolf <email@hidden> wrote:

Hello,

not sure if this is the right place for my question.
I've found out recently that my iPhone application does not close socket connections under following conditions:
* using POSIX calls
* establish connection
* turn off wifi when in application
* close connection
* enable wifi

I was not sure about what happens, so i tried it on MacOS too -> same behavior.
I tried it under Linux and it works, after reconnecting wifi, TCP stack serves the FIN packets as expected.
That's why I'm posting here, because I think it maybe a kernel issue in TCP stack?
I don't know how to investigate darwin kernel issues...

I wrote some examples to reproduce:
https://github.com/whaupt/tcp_server
https://github.com/whaupt/tcp_client
https://github.com/whaupt/ios_wlan_example

I've also filed a bugreport at bugreport.apple.com but after sending wifi and device logs I did not hear anything
for a while now.

Maybe anyone is interested in testing this or giving me some advice how to create a custom kernel with debug logs?


Kind Regards,
Wolfgang
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

References:
	>Socket remains open (From: airwolf <email@hidden>)