问题标签 [unreliable-connection]

我使用 SQLYog 社区版几个月来几乎每天将几十个表从生产服务器复制到开发服务器，用于测试目的（“复制数据库”）。它过去一直正常工作，直到上周。我们注意到在表复制过程中缺少行，无论是最后的 32 位版本还是之前的 64 位版本。大多数错误发生在相同的两个 InnoDB 表上，每个表大约有 550 万行。我很惊讶地看到 MySQLYog 没有报告任何错误。该错误是随机的。我在查看结果时发现缺少行（有时只复制了大约 350 000 行，甚至没有 10% 的数据）。

有人在 SQLYog 中遇到过同样的问题吗？情况越来越糟。今天早上，我必须连续复制同一张表 4 次才能得到整个表。最后，我们在 MySQL 日志中注意到一些通信数据包丢失了。但是为什么客户端没有错误？为什么总是在同一张桌子上？它似乎与表格的内容无关（表格的开头没有改变）。

我们需要帮助以可靠的方式传输我们的数据： * 有没有人经历过 MySQL 的通信数据包丢失？MySQL 配置中是否有任何更改以使传输更可靠？* 有谁知道更好的免费工具，可以在服务器之间快速可靠地复制表？

据我了解，如果发送 TCP RST，则发送方（A）关闭套接字并在其末端关闭连接。现在，由于 RST 丢失，预期的接收者 (B) 还不知道发送的 RST。如果 B 现在尝试向 A 发送更多数据，A 将如何反应以及 B 会得到什么响应？

我们开发了一个 Web 应用程序，该应用程序托管在通过 Wifi 供车间人员使用的场所。但是，wifi信号不可靠，无法使用有线网络或改善信号。

我正在寻找解决此问题的解决方案。有没有办法将http请求放入本地队列并在后台异步处理？如果是这样，该怎么做？还是有其他替代方法？

任何想法都非常感谢。

我正在设计一个用于数据收集的 Android 应用程序，该应用程序预计将用于网络覆盖范围不广的户外区域，因此客户端到服务器消息传递的稳健性很重要。如果用户尝试提交某些内容但请求失败或没有网络，则应用程序需要记住这一点并稍后再试，无论是按需还是在连接恢复时。

我们正在考虑将 Firebase 用于我们的数据模型，但也想评估更传统的服务器/数据库/API 解决方案。Firebase 的一大优势是它们通过客户端 SDK 提供的“离线”支持：

无论网络延迟或互联网连接如何，您的 Firebase 应用都将保持响应。在任何数据写入服务器之前，对 Firebase 数据库的所有写入都会立即触发本地事件。一旦重新建立连接，客户端将接收它错过的任何更改，并将其与当前服务器状态同步。

如果我们使用 Firebase，免费获得它是很棒的。或者，什么会给我类似的客户端功能来支持典型的 RESTful API？最好是某种可以为我处理状态而不是跟踪个人尝试的库。

我已经研究过像 SymmetricDS 这样的离线数据库同步解决方案，但在这种情况下这似乎有点过头了。事实上，我宁愿客户端没有直接的数据库访问权限。从应用程序发送的消息将是独立条目，如照片或评论，不需要执行复杂的查询、同步写入等。我只需要确保用户提交的任何内容最终都会发送到服务器一旦连接恢复，并确认它已经恢复。

我使用信号器在我的 android 游戏与统一和服务器之间进行连接，但由于移动数据连接 (3G) 网络套接字连接的不可靠性丢失并定期重新连接。在这种情况下，最好的运输类型是什么？对于不可靠的网络，服务器发送事件是否比 WebSocket 更好？描述：客户端几乎每 15 秒发送一次请求。

我在维持蓝牙连接（从 Android 到我正在开发的设备）超过几分钟时遇到问题。

场景是：

1. 设备配对成功。
2. 设备传输到 Android 的时间在 1-7 分钟之间（因设备或可能的 Android 版本而异）。
3. 尽管设备仍在传输，Android 停止接收字节。

那么：为什么Android BT 停止接收？

这与 bboydflo 对此问题的回答中描述的问题/观察非常相似： Application using bluetooth SPP profile not working after update from Android 4.2 to Android 4.3

更多背景：

• 我正在使用的 BT 设备每秒一次持续发出包含约 200 个字符的测量数据包。我确定问题发生时设备端仍在传输。
• 此症状发生在我的两个 Android 设备上的应用程序中：Android 5.0.1 Acer 平板电脑和 Android 7.1.1 Moto Play X
• 我已经用一个名为 Serial Bluetooth Terminal 的应用程序进行了测试。这个应用程序没有遇到同样的问题；只要我测试过，连接就很稳定。因此，此问题可能是由我的应用程序代码中的某些内容引起的。
• 我已经看到对 Android BT 问题的各种响应，这些问题指示用户使用异步流而不是轮询接收到的字节。这似乎是一条红鲱鱼；如果您觉得在这种情况下线程模型引起了问题，请清楚地描述为什么切换到异步可以解决此问题。

我想先发制人地解决这个问题可能被关闭的原因：

• 这不是重复的。还有其他关于 BT 连接丢失的问题（即Android 上的实时蓝牙 SPP 数据流仅适用于 5 秒），但这不是同一个问题。我已经添加了一个每 1 秒传输一次的保活传出字符，我的问题仍然存在。
• 我不是在询问特定于我的应用程序的问题。SO上的至少一个其他用户遇到了这个问题。
• 我已经详细查看了 Android 蓝牙文档，但我看不出有任何明显的原因会发生这种情况。
• 我不是在征求意见。我要求客观回答为什么停止接收字节。

设想：

给定一个设备，它始终处于开启状态，并且每秒执行一次低功耗蓝牙广告。
我必须为 Android 平板电脑实现一个应用程序，该应用程序通过低功耗蓝牙连接到该设备，发送一些命令，然后断开连接。
最低 Android 版本：效果最好的版本，我可以自由决定。 我从 API 21（Android 5.0、Lollipop）开始

问题：

BLE 堆栈的问题也给我带来了麻烦：我想使用BluetoothAdapter#getRemoteDevice(MACAddress: String)方法检索到的对象发出成功的直接连接，但它总是失败。

我的研究结果：

以下是我发现并且似乎有用的问题/答案/帖子（也许这些会对某人有所帮助）：

• 蓝牙/BLE开发在Android上惨不忍睹。有谁知道有什么特别的技巧吗？
• android ble连接慢
• GattManager 的实现，它有解决方法 - 由挪威的一家公司实现：Nordic Semiconductor
• RxAndroidBle - “RxAndroidBle 是一个强大的止痛药，可以解决 Android 的低功耗蓝牙问题。它由 RxJava 支持，将复杂的 API 实现为方便的反应性可观察对象。”
• 重新/连接的解决方法

问题：

除此之外，我查看了 BluetoothDevice 的源代码，我发现connectGatt()方法的Context参数根本没有使用：https ://android.googlesource.com/platform/frameworks/base/+ /master/core/java/android/bluetooth/BluetoothDevice.java#1899 想知道这是否是 BLE 堆栈存在缺陷的原因之一？

另外，我不明白扫描仪检索到的BluetoothDevice对象与BluetoothAdapter#getRemoteDevice(MACAddress: String)方法检索到的对象有什么区别。如果我在通过扫描获得的设备上
发出直接连接（调用connectGatt()时autoconnect参数设置为false ），连接通常会成功。但是，当使用由getRemoteDevice()检索到的对象时，直接连接总是失败（状态 = 133，超时） 。

由于我要连接的设备每秒都在宣传自己，我希望直接连接始终/大部分时间都能正常工作，就像在扫描的情况下一样。
因为后台连接（autoconnect 参数设置为 true）非常慢，我不能依赖它。
此外，由于扫描不可靠且缓慢，我不能强制用户在每次应用程序启动时等待。

总结我的问题：

• 根本没有使用connectGatt()方法的Context参数- 这可能是 BLE 堆栈存在缺陷的原因之一吗？我想有人把它放在那里是有充分理由的。
• 扫描仪检索到的BluetoothDevice对象与BluetoothAdapter#getRemoteDevice(MACAddress: String)方法检索到的对象有什么区别？

我有一个服务 AAA，每分钟向 RabbitMQ 交换发布 10 到 5 万条消息。一个 .NET Core 服务 BBB 订阅一个队列（所有消息都被路由到该队列），并为每条消息通过 Internet 调用另一个 HTTP 服务 CCC。问题是 CCC 非常不可靠，一天几次它会完全关闭一两分钟，每周至少一次它会死掉一个小时。

我无法控制 AAA 或 CCC。如何使用 RabbitMQ 路由功能可靠地传递所有已处理的消息？

我不时向我们在印度的卫星分支机构发布企业应用程序。连接很差，我很难执行基本的 ClickOnce 发布（VS2017 内置的发布）。系统将尝试发布，但可能会挂起 10%。有时我会达到 90%！

在获得足够的稳定连接来发送文件之前，我必须尝试 5 或 10 次。我们在这里只谈论 150 MB。关于如何使 VS 在不可靠的连接下工作的任何想法？我认为微软会有纠错/重试机制来缓解这种情况。