我有几个问题，但是SO的做法是不要一次提出多个问题，所以我会将相同的介绍和编号按逻辑顺序排列。
我正在编写一个与.NET Win服务通信的业务应用程序。目标受众是工作人员，在有Wi-Fi覆盖的建筑物中工作。该应用程序用于宣布某些事件，最终将要求接收方接受或拒绝（因此传输必须是双向的）。
我已经通过TCP实现了设备注册，然后切换到UDP数据通道。 从架构上讲，有一个启动Application类（配置一些全局设置所必需的），它依次打开LogIn活动，该活动在成功注册后打开Main活动。在启动时，Main启动前台服务（CommSvc），启动UDP-comm线程。
我正在开发VisualStudio 2017 15.5.4，Xamarin 4.8.0.757，Xamarin.Android SDK - 8.1.3.0。
我的测试设备是2部手机LG Nexus 4（Android 4.3，API 18），BLU Vivo 5 Mini（6.0,23），
和三星SM-T377V（6.0.1,23）平板电脑，我正在考虑升级到7.0。
Q1 即可。据我们的内部网络工程师估计，利用TCP将导致移动无线电更快地耗尽电池（相对于UDP）。 那是真的吗？
TCP保证有序传递字节流（假设设备保持在范围内）。 UDP数据包可能会丢失，因此需要某种ACK和重传失败协议。
由于信道的Wi-Fi特性，永远不能保证发送的数据包到达目标设备（例如，它超出范围），因此无论是否重新发送ACK协议都是必要的什么，我是对的？ （有责任方面）
答案 0 :(得分：0)
由于TCP必须做更多的发送和接收以确保数据包传输，它使用更多的流量和更多的wifi时间，因此更多的电池。
如果您希望保证交付，您可以使用TCP，也可以在UDP之上构建模拟，这可能效率较低。
如果您不希望保证交付，例如你发布的数据很快就会过时，并且不介意丢失一些中间值，那么UDP就是一种方法。
如果你发送的数据相当大，我想在传输之前压缩它们，并在接收时解压缩，将在无线电中节省比CPU消耗更多的功率。
未及时从接收方获得ACK必须是TCP流中的错误，可能通过IOException发出信号，因此您可以检测到不完整的通信。但 不会告诉您已发送的内容是否已到达目的地。您的服务器应该准备好检查通信故障，并且可能已准备好重新接收（和丢弃）最近已经收到并执行的命令。序列号，TCP风格，也在这个级别上提供帮助。 OTOH如果设备在重新连接后总是向服务器询问状态，并且服务器提醒最后接受的命令，则不需要。
在上述情况下，如果您的有效负载足够大，并且您不想重新实现fragmentaton / ooo接收/恢复逻辑，则TCP仍然有用。对于保证非常小的有效载荷（低于1kb，我说），最小的常用IP数据包足够大，因此您可以在应用级别重新实现相当简单的syn-ack逻辑。
通常，当连接不稳定时（例如，接收不良的Wi-Fi），具有相当长的值（数十或数百秒）的套接字将很好地工作。但请务必.SetSoTimeout(something_reasonable);默认值为无限！