引用：JackJiang 发表于 2021-12-08 14:53
写代码，从理想情况下来说，当然怎么写都舒服了，但实际上，时间的复杂性往往出在在极端情况下，而这些复 ...

好的，谢谢群主解惑

引用：kpsmile 发表于 2021-12-08 14:40
单独只是用TCP协议的话，理论上是不是监听器的回调方法返回成功后就说明消息已经到达接受端了呢

写代码，从理想情况下来说，当然怎么写都舒服了，但实际上，时间的复杂性往往出在在极端情况下，而这些复杂性又不得不考虑进去。

比如，移动网络下，网络质量跳变的很快，有时候信号很差，tcp丢包重传时间可能会要等很长，如果不能快速决定是不是要放弃，那就影响后绪的传输，以及应用层的用户体验。

另一个，如果没有应用层的确认机制，有时候可能tcp真的送达了，但应用层的某环节导致app奔溃或出了什么错等等。

总之，复杂情况很多，远不是依赖tcp协议本身就能解决的好的。

具体你可以看看这两篇文章《为什么说基于TCP的移动端IM仍然需要心跳保活？》、《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》

引用：JackJiang 发表于 2021-12-08 11:22
你的意思，是不是说，tcp是所谓的可靠协议，由它协议本身保证送达，应用层不需要QoS应答保证机制，是这样理 ...

单独只是用TCP协议的话，理论上是不是监听器的回调方法返回成功后就说明消息已经到达接受端了呢

你的意思，是不是说，tcp是所谓的可靠协议，由它协议本身保证送达，应用层不需要QoS应答保证机制，是这样理解的吗？