标签: unreliable-connection

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

我不只是指降低带宽,还降低可靠性,频繁开关,短时断线连接等.

我正在寻找Hibernate的系统,它需要在一个不可靠的网络中工作.我们需要一个单一的中央数据库进行读写访问,但它可以在一个非常不完整的Wi-Fi网络上使用.此外,可能存在功率损耗,这些功率损耗不会干净地关闭应用程序,因此任何解决方案都必须具有可以在电源循环中存活的持久高速缓存.最后,这是一个只有适度内存和磁盘空间的嵌入式系统,因此例如对数据库进行全面复制并不是一种可行的策略.

我对Hibernate二级缓存有基本的了解,我想知道是否有可能用Ehcache这样的东西配置来解决这个问题,但是主要的推力似乎是性能不可用,所以我不知道陷阱可能是什么.

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

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

我正在阅读有关可靠UDP的实现(即发送ACK数据包并再次重新发送非确认数据包).

我似乎在网络中找到了两种主要模式:

1. 客户端使用该数据包的序列为每个接收到的数据包发送ACK.除非收到ACK,否则服务器假定数据包未送达.

2. 客户端发送一个ACK数据包,其中包含它认为缺失的数据包序列.服务器假定数据包已传递,除非它从客户端收到一条ACK,说它缺少序列,然后再次重新发送请求的(丢失的)数据包.

简而言之,在1.中,客户端发送接收到的数据包的序列,而在2.客户端发送丢失数据包的序列.

只是想知道每种方法的优点/缺点是什么,哪一种更主流(我假设1,但是2似乎是一种非常聪明的方法,因为大多数数据包确实到达而且通常只丢失一些).

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

Method 1: Server sends: 1,2,3,4,5 
Client received: 1,3,5,4 
Client sends back: ACK 1, ACK 3, ACK 5, ACK 4  
Server resends: 2.. maybe more if ACK packets were lost


Method 2:
Server sends 1,2,3,4,5,6,7,8
Client receives: 1,3,2,5,7
Client Sends :ACK (lowest continuous 3,highest received 7,  seem to be missing 4,6)
Server resends: 4,6,8

我需要构建一个使用发布/订阅总线的系统(例如Mule,ZeroMQ,RabbitMQ),但是文献都暗示订阅者应用程序可靠地用于接收Pub/Sub总线上他们订阅的主题的消息能够传递信息.

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

显而易见的解决方案是在不可靠的应用程序和发布/订阅总线之间建立某种"存在"协议,以便"当前"应用程序立即传递其消息,并且"不存在"应用程序将其消息排队在持久缓冲区中在某种情况下,一旦完成"在线握手",排队的消息就会被传递给新呈现的应用程序.

是否有任何内置此类功能的发布/订阅总线,或者是否有任何开源附加组件可以执行此操作？你能指点我描述这个的任何网址吗？

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

要求:

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

我正在寻找一种通过HTTPS实现文件传输服务的方法,该服务使用分块来应对间歇性连接丢失并减少使用流式传输所需的大量超时.由于客户端可能位于防火墙后面,因此MSDN上的分块通道样本不适用.

在微软论坛上有一个关于此的旧讨论,但不是一个完整的答案,或者至少没有一个我有实施的专业知识.

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

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