问题标签 [unreliable-connection]

我们需要模拟一个不稳定的网络连接来尝试调试我们的服务器/客户端应用程序中的一些连接问题，我想知道是否有任何程序可以模拟这些条件，例如在微弱的无线网络上。

我指的不仅仅是减少带宽，还包括降低可靠性、频繁开关、短时间的断开连接等。

我可以使用什么技术来管理服务器-客户端应用程序中不稳定的互联网连接。我主要了解 PHP（+Zend 框架），学习 C# 和 ASP.NET MVC。我听说 WCF/MSMQ 可以提供帮助...但是如何... PHP（我更熟悉）可以做什么？但如果它更好，了解 .NET 替代品也很好

的背景：

client***s*** 将连接到服务器数据库以执行 CRUD。但如果互联网连接失败，这将是不可能的。那么我该如何解决呢？

现在使用的解决方案是拥有 localhost db。一天结束时，所有客户端都将上传到服务器，早上从服务器下载“整合”数据库。这并非万无一失，因为上传/下载仍可能失败。并且考虑到传输的大量数据，它实际上增加了机会。

更新：是否有 PHP/Zend 框架/MySQL 替代 MSMQ/WCF？

试图为分布式系统找到一个商业日志框架。此框架必须允许远程服务器上的 .NET 应用程序记录可以在中央位置收集的消息。如果可能，中央位置应将消息存储在 SQL Server 数据库中。

要求：

1. 能够在远程服务器上启动消息记录，即使网络中断阻止消息立即发送到中央位置。
2. 将消息分派到中央位置应由运行 .NET 应用程序的进程以外的进程处理，以防止 ASP.NET 应用程序或 Web 服务的性能下降。
3. 确保最终将消息传递到中央位置。例如，如果远程服务器在网络没有响应的时间快要结束时重新启动，则在远程服务器和正常网络条件恢复时仍应传送记录的消息。

我正在寻找一种通过 HTTPS 实现文件传输服务的方法，该服务使用分块来应对间歇性连接丢失并减少使用流式传输所需的大量超时。因为客户端可能在防火墙后面，所以 MSDN 上的Chunking Channel示例不适合。

微软论坛上有一个关于这个的旧讨论，但不是一个完整的答案，或者至少没有我知道如何实施的答案。

我正在阅读有关可靠 UDP 的实现（即发送 ACK 数据包并再次重新发送非 ACK 数据包）。

我似乎在网上发现了两种主要模式：

1. 客户端为每个接收到的数据包发送一个 ACK​​，其中包含该数据包的序列。服务器假定数据包未送达，除非它收到 ACK。

2. 客户端发送一个带有它认为丢失的数据包序列的 ACK 数据包。服务器假定数据包已交付，除非它从客户端接收到一个 ACK​​ 说它丢失了一个序列，然后它再次重新发送请求的（丢失的）数据包。

简而言之，1.客户端发送接收数据包的序列，而2.客户端发送丢失数据包的序列。

只是想知道每种方法的优缺点是什么，哪个更主流（我假设 1，但 2 似乎是一种非常聪明的方法，因为假设大多数数据包确实到达并且通常只有少数数据包丢失）。

编辑：两种方法的简短示例：

我正在寻找一个需要在不可靠网络中工作的系统的 Hibernate。我们需要对一个中央数据库进行读写访问，但它可以通过一个相当不完整的 wi-fi 网络访问。此外，可能存在无法彻底关闭应用程序的电源损耗，因此任何解决方案都必须具有能够在电源循环后继续存在的持久缓存。最后，这是一个只有适度内存和磁盘空间的嵌入式系统，因此例如对数据库进行全面复制不是一个可行的策略。

我对 Hibernate 2nd Level 缓存有一个基本的了解，我想知道是否可以用 Ehcache 之类的东西来配置它来解决这个问题，但主要的目的似乎是性能而不是可用性，所以我不知道陷阱可能是什么。

我也非常愿意考虑涉及复制到本地数据库的其他策略。我宁愿自己不必做太多繁重的工作来实现这一点。

寻找一些经验或可能的替代方案。

我需要构建一个使用 Publish/Subscribe 总线（例如 Mule、ZeroMQ、RabbitMQ）的系统，但文献都暗示订阅者应用程序可以可靠地接收来自他们订阅的主题的消息，只要 Pub/Sub 总线能够传递消息。

我有一个系统，其中一些应用程序将可靠地连接到发布/订阅总线，但其他应用程序不会一直处于活动状态或连接到总线。

显而易见的解决方案是在不可靠的应用程序和发布/订阅总线之间建立某种“存在”协议，以便“存在”应用程序立即传递它们的消息，而“不存在”应用程序将它们的消息排队在持久缓冲区中某种形式的，一旦他们完成“在场握手”，排队的消息就会被传递给新出现的应用程序。

是否有任何发布/订阅总线内置了这种功能，或者是否有任何开源插件可以做到这一点？你能指出任何描述这一点的网址吗？

我正在尝试在不可靠的通道上制定协议协议。基本上两方（A和B）必须同意做某事，所以这是两位将军的问题。

由于没有防弹解决方案，我正在尝试这样做。

• A 连续发送一个序列为 1 的消息
• 当 B 收到序列 1 时，它会不断回复序列 2
• 此时 A 收到 seq 2 所以它开始发送 seq 3
• ...

我的问题。双方何时可以断定他们可以采取行动？显然，我不能设置条件：“在收到 10 条消息后执行”，因为最后一个发件人无法确定消息 10 是否到达 - 回到第一条。

另一个想法怎么样：

• 在预定的时间内保持这样的沟通。在那个时期结束时，双方都对通道的可靠性有了一个想法。那可以接受吗？

我有一个 Flex actionscript 3 日程提醒应用程序，它通过 wifi 通过互联网与网络服务对话。问题是wifi连接不可靠，经常掉线。该应用程序提醒的时间表不会经常更改。因此，应用程序可以在本地存储数据，而不是每天/每小时调用 Web 服务来查找时间表。此外，如果用户更新应用程序上的计划，则 Web 服务会更新计划中的任务已完成。这些数据也可以存储在本地，这样当用户下次使用应用程序并且有互联网连接时，应用程序可以更新网络服务。在这种情况下，对应用程序设计有何建议？有没有例子？

我的架构会在服务器上使用ActiveMQ，让Android客户端发送和接收消息。网络情况会很不可靠；可能缺少连接数小时。是否有一个框架可以让我在 android 客户端上排队消息并在连接恢复后可靠地传递它们？