个人想到的有：（1）若Server处理完密码更改任务完成后，还没发response，连接就因为网络异常断开了，似乎是无解，这个可以暂不考虑。所以以下都是不考虑网络中途异常断开的情况。

（2）超时后，发送cancel指令给server，取消密码更改命令，不过这会大大增加Server程序的复杂度，至少需要缓存之前的旧密码，cancel指令什么时候能达到server也是个问题，server上总不能无期限的保存这个旧密码吧。

（3）写操作不做超时机制，改成异步，一直等到结果返回为止，并且在结果返回前不允许再发送这个写操作命令。不过体验比较差，相当于一段时间内禁用了某功能。

Quote: 引用 楼主 woshinia 的回复:

个人想到的有：（1）若Server处理完密码更改任务完成后，还没发response，连接就因为网络异常断开了，似乎是无解，这个可以暂不考虑。所以以下都是不考虑网络中途异常断开的情况。

（2）超时后，发送cancel指令给server，取消密码更改命令，不过这会大大增加Server程序的复杂度，至少需要缓存之前的旧密码，cancel指令什么时候能达到server也是个问题，server上总不能无期限的保存这个旧密码吧。

（3）写操作不做超时机制，改成异步，一直等到结果返回为止，并且在结果返回前不允许再发送这个写操作命令。不过体验比较差，相当于一段时间内禁用了某功能。

对一个需要密码的网络服务而言，断开了就意味着要重新登录，因此，你的1、2问题应该不存在。而对需要长连的网络双方，都能通过心跳和TCP知道连接状态，发生断开时直接启动重连操作，我在长连网络试验以各种方式断开连接中的任意部分，当连接恢复后程序都能自愈，不会出现你所说的情况，我想问题出在总体设计而不是出在具体细节。

超时处理，

服务端是断开跟客户端连接
客户端是再次请求

针对你上面这贴说的这种情况，如果是我，我就针对这种超时的请求，在下次发命令前先到服务器查询一下，如果上次执行成功，就不再重复发送

Quote: 引用 9 楼 wutaozhao 的回复:

针对你上面这贴说的这种情况，如果是我，我就针对这种超时的请求，在下次发命令前先到服务器查询一下，如果上次执行成功，就不再重复发送

但是下次命令与上次命令参数可能是不同的，server怎么判断“上次执行“是哪一次呢？要精确比较的话，server就需要缓存大量的数据，到底要缓存多少条，这些数据要缓存多久也不知道。

Quote: 引用 10 楼 woshinia 的回复:

Quote: 引用 9 楼 wutaozhao 的回复:

针对你上面这贴说的这种情况，如果是我，我就针对这种超时的请求，在下次发命令前先到服务器查询一下，如果上次执行成功，就不再重复发送

但是下次命令与上次命令参数可能是不同的，server怎么判断“上次执行“是哪一次呢？要精确比较的话，server就需要缓存大量的数据，到底要缓存多少条，这些数据要缓存多久也不知道。

不知道你服务端的数据是怎么组织的，这种问题在很多系统都会是严重问题，比如计费系统，玩家充了钱，服务端也成功，但像你说的，客户端没收到回包，就需要客户端和服务器制定协议来处理这种情况。

正如楼上所说，如果真的这样，就需要由“机制”来保证，而并非你现在所操心的“程序处理流程”。
对于超时而言，如果你的系统设计中为小于1秒的话，估计超过这个值，即使你的程序不断开，TCP也会RET了，TCP中本身存在一个心跳。

在使用GPRS通讯时，会出现这种无响应超时的情况。需要一种事务机制来进行处理判断！

Quote: 引用 10 楼 woshinia 的回复:

Quote: 引用 9 楼 wutaozhao 的回复:

针对你上面这贴说的这种情况，如果是我，我就针对这种超时的请求，在下次发命令前先到服务器查询一下，如果上次执行成功，就不再重复发送

但是下次命令与上次命令参数可能是不同的，server怎么判断“上次执行“是哪一次呢？要精确比较的话，server就需要缓存大量的数据，到底要缓存多少条，这些数据要缓存多久也不知道。

不知道你服务端的数据是怎么组织的，这种问题在很多系统都会是严重问题，比如计费系统，玩家充了钱，服务端也成功，但像你说的，客户端没收到回包，就需要客户端和服务器制定协议来处理这种情况。

Quote: 引用 10 楼 woshinia 的回复:

Quote: 引用 9 楼 wutaozhao 的回复:

针对你上面这贴说的这种情况，如果是我，我就针对这种超时的请求，在下次发命令前先到服务器查询一下，如果上次执行成功，就不再重复发送

但是下次命令与上次命令参数可能是不同的，server怎么判断“上次执行“是哪一次呢？要精确比较的话，server就需要缓存大量的数据，到底要缓存多少条，这些数据要缓存多久也不知道。

不知道你服务端的数据是怎么组织的，这种问题在很多系统都会是严重问题，比如计费系统，玩家充了钱，服务端也成功，但像你说的，客户端没收到回包，就需要客户端和服务器制定协议来处理这种情况。

Quote: 引用 13 楼 wutaozhao 的回复:

Quote: 引用 10 楼 woshinia 的回复:

Quote: 引用 9 楼 wutaozhao 的回复:

针对你上面这贴说的这种情况，如果是我，我就针对这种超时的请求，在下次发命令前先到服务器查询一下，如果上次执行成功，就不再重复发送

但是下次命令与上次命令参数可能是不同的，server怎么判断“上次执行“是哪一次呢？要精确比较的话，server就需要缓存大量的数据，到底要缓存多少条，这些数据要缓存多久也不知道。

不知道你服务端的数据是怎么组织的，这种问题在很多系统都会是严重问题，比如计费系统，玩家充了钱，服务端也成功，但像你说的，客户端没收到回包，就需要客户端和服务器制定协议来处理这种情况。

计费系统好像比较容易解决，就是定时（或者用户打开重新打开充值页面的时候）刷新下客户端的数据就行了。难道我

引用 13 楼 wutaozhao 的回复:

Quote: 引用 10 楼 woshinia 的回复:

Quote: 引用 9 楼 wutaozhao 的回复:

针对你上面这贴说的这种情况，如果是我，我就针对这种超时的请求，在下次发命令前先到服务器查询一下，如果上次执行成功，就不再重复发送

但是下次命令与上次命令参数可能是不同的，server怎么判断“上次执行“是哪一次呢？要精确比较的话，server就需要缓存大量的数据，到底要缓存多少条，这些数据要缓存多久也不知道。

不知道你服务端的数据是怎么组织的，这种问题在很多系统都会是严重问题，比如计费系统，玩家充了钱，服务端也成功，但像你说的，客户端没收到回包，就需要客户端和服务器制定协议来处理这种情况。

比如就这个场景下，客户端没有收到回包，应该怎么处理？
1，直接提示操作失败（显然不可取）
2，超时后，不提示失败，而是发送命令查询结果，若查询也超时，则无限发送查询命令，直到成功为止？
3，不设置超时，一直等待回包，直到下次用户查询余额或者打开充值面板的时候，发送一次查询命令？