［摘抄］游戏中socket断网重连＋心跳包

可以引起网络连接关闭的情况有以下4种：

• 直接调用Socket类的close方法。
• 只要Socket类的InputStream和OutputStream有一个关闭，网络连接自动关闭（必须通过调用InputStream和OutputStream的 close方法关闭流，才能使网络连接自动关闭）。
• 在程序退出时网络连接自动关闭。
• 将Socket对象设为null或未关闭最使用new Socket(…)建立新对象后，由JVM的垃圾回收器回收为Socket对象分配的内存空间后自动关闭网络连接。

通过心跳包判断socket是否连接

在利用socket写通讯程序的时候，想检测服务器是否还活着。

从网上找了很多资料，都没有自己合适的，最后自己想了个办法，不过也相当于截取了心跳检测的一部分。

这里检测的是远程server的连接，而不是本地是否连接成功。首先想到socket类的方法isClosed()、isConnected()、isInputStreamShutdown()、isOutputStreamShutdown()等，但经过试验并查看相关文档，这些方法都是本地端的状态，无法判断远端是否已经断开连接。
(isConnected方法来判断Socket对象是否连接成功。但是，isConnected方法所判断的并不是Socket对象的当前连接状态，而是Socket对象是否曾经连接成功过，如果成功连接过，即使现在isClose返回true，isConnected仍然返回true。)

而有一个方法sendUrgentData，查看文档后得知它会往输出流发送一个字节的数据，只要对方Socket的SO_OOBINLINE属性没有打开，就会自动舍弃这个字节。

或者，其实如果断开连接了，你发送过去的数据会收不到，最后client会抛出io异常。（判断socket是否断开，还是得通过心跳包来确定，当连接断开时，发生心跳包就出出现异常，这样就可以知道掉线了）

try {
socket.sendUrgentData(0xFF);//心跳包                                         
} catch (IOException e) {
    e.printStackTrace();

　　}

上面两个方法，抛出异常的时间长达15秒！

一、双方拟定心跳（自实现）

一般由客户端发送心跳包，服务端并不回应心跳，只是定时轮询判断一下与上次的时间间隔是否超时（超时时间自己设定）。服务器并不主动发送是不想增添服务器的通信量，减少压力。
但这会出现三种情况：

情况1.

客户端由于某种网络延迟等原因很久后才发送心跳（它并没有断），这时服务器若利用自身设定的超时判断其已经断开，而后去关闭socket。若客户端有重连机制，则客户端会重新连接。若不确定这种方式是否关闭了原本正常的客户端，则在ShutDown的时候一定要选择send,表示关闭发送通道，服务器还可以接收一下，万一客户端正在发送比较重要的数据呢，是不？

情况2.

客户端很久没传心跳，确实是自身断掉了。在其重启之前，服务端已经判断出其超时，并主动close，则四次挥手成功交互。

情况3.

客户端很久没传心跳，确实是自身断掉了。在其重启之前，服务端的轮询还未判断出其超时，在未主动close的时候该客户端已经重新连接。
这时候若客户端断开的时候发送了FIN包，则服务端将会处于CLOSE_WAIT状态；
这时候若客户端断开的时候未发送FIN包，则服务端处还是显示ESTABLISHED状态；
而新连接上来的客户端（也就是刚才断掉的重新连上来了）在服务端肯定是ESTABLISHED;这时候就有个问题，若利用轮询还未检测出上条旧连接已经超时（这很正常，timer总有个间隔吧），而在这时，客户端又重复的上演情况3，那么服务端将会出现大量的假的ESTABLISHED连接和CLOSE_WAIT连接。
最终结果就是新的其他客户端无法连接上来，但是利用netstat还是能看到一条连接已经建立，并显示ESTABLISHED，但始终无法进入程序代码。个人最初感觉导致这种情况是因为假的ESTABLISHED连接和CLOSE_WAIT连接会占用较大的系统资源，程序无法再次创建连接（因为每次我发现这个问题的时候我只连了10个左右客户端却已经有40多条无效连接）。而最近几天测试却发现有一次程序内只连接了2，3个设备，但是有8条左右的虚连接，此时已经连接不了新客户端了。这时候我就觉得我想错了，不可能这几条连接就占用了大量连接把，如果说几十条还有可能。但是能肯定的是，这个问题的产生绝对是设备在不停的重启，而服务器这边又是简单的轮询，并不能及时处理，暂时还未能解决。

移动平台下的Socket几个问题

长连接是比较消耗资源的，但是通常情况下，一方断了另一方会较为及时的收到消息，业务逻辑上是比较简单和及时的。

移动设备上面临的主要问题是频繁的掉线

TCP连接使用的是三次握手
TCP断开使用的是四次握手

解释：就连接使用三次握手，这个不多说了，主要原因是为了保证二端都能确认连接已经建立(SYN、ACK)。而断开为什么是四次？因为socket是双工（双向通信），相当于存在二条通讯的线路，一条用于接收，一条用于发送。一方主动关闭时（写通道被关闭了，但此时读通道还是正常的），它会发送FIN，另一端收到时会响应FIN+1（表示我收到你的关闭请求啦~），然后另一端处理完自己的逻辑后，告诉发起请求关闭的一方，我同意了你的关闭请求（不会再向你发送数据啦~），此时发起关闭的一方的读通道才是正常被关闭了。发起请求关闭的一方会在2MSL（报文最长生命周期的两倍 Maximum Segment Lifetime）后释放掉它所占用的端口（连接记录此时才会被清除）。

假设服务器突然断电了，客户端是不知道服务器端已经无法连接了的，还会认为可以发送数据给服务器端。通常都是使用心跳包进行检测来双方的连接是否还存在。

通常一款游戏是有二个socket长连接的：游戏主逻辑、聊天服务器.

后端处理是这样的，建立socket时会随机生成一个密钥串，当客户端断开连接时，拿这个密钥串向服务器进行验证，但是服务器验证时有个特殊的判定，如果请求生成密钥串的客户端IP与重连时的客户端IP不一致，则认为是非法请求。也就是说2G切换至WIFI时，IP变了，服务器其实是直接将连接断开了，但为什么没触发关闭的回调函数，这个或许是那个Android系统版本的bug吧

后来想的办法有二个：

1、针对Android平台，记录连接时的网络类型，然后切换至前台时再获取网络类型，如果发现二次的网络类型不一致就提示需要重新登录游戏了；

2、记录建立连接时的IP地址，当切换至前台再获取IP，如果这二个IP不致，也认为是需要重登录游戏了，因为无论你拿什么密钥串都将无法再登录游戏，服务器认为这个请求是非法的；

TCP的socket本身就是长连接的，那么为什么还要心跳包呢？

• 内网机器如果不主动向外发起连接，外网机没法直连内网
• 心跳包主要也就是用于长连接的保活和断线处理, 应对中间节点故障
• 需要心跳连接主要是判断当前连接是否是有效的、可被使用的, 方便主动关闭socket

1.如何知道谁在线？
Server维护一个list就ok了（存所有人的ip,名字，在线等）
2.如何让服务器随时能找到你？
前提：内网机器如果不主动向外发起连接，外网机没法直连内网的，这也是内网机安全的原因之一吧，又因为路由器会把这个关系记录下来，但是过一段时间这个记录可能会丢失 ，所有每一个客户端 每隔一定时间就会向服务器发送消息，以保证服务器可以随时找到你，这东西被称为心跳包。
3.如何跨内网直连
Nat打洞（难）：
我简单说下原理，有两个客户端A,B ，当然必须有Server啦（他可以随时连接A，B）
当A想连B时，A就回从Server那要B的ip,然后与B建立连接（第一次不能成功的，因为看红字）。
这时A告诉Server，我找不到B，你替我告诉他一声,我想与它连接，服务器就告诉B，你给A下一个请帖（B发请求向A）！
这时A再向B发起连接就可以成功了（以后就不用server帮忙了）。
4.如何保证数据的可靠性（难）
滑动窗口协议，这个一句话两句说不清楚啦，自己google下。
5是否在线。
我的设计是每隔40秒客户端把Server中存自己的信息中的在线改为真，而服务器每过45秒就检查这个在线变量是否为真，真的话把他改成假，如果假的话就说明这个人在45秒没有向Server报到＝>他网络出现异常了，掉线了，向其它人发这个人的掉线通知。（这么设计原因在于当用户网断了没有发下线通知,我们也能知道他不在线了）
6文件传输（难）
把文件读到buf里，然后每次发1024b（当收到接收方确认后再发下一个1024b）。

摘抄出处:
Tcp通信中服务器处理客户端意外断开！
Java android Socket通信检测（server）连接是否断开(适用于发送数据次数少的检测)
移动平台下的Socket几个问题
【Socket】关于socket长连接的心跳包（重要）