通信 tcp wifi-多节点状态同步机制设计

问题描述

多节点状态同步机制设计

一个例子 A通过wifi 控制B B通过串口控制单片机C C的每个io控制一个灯 一共20个灯

应用 ABC 上面都有指示的东西 表示哪个灯亮了

问题1:比如A要控制最终的某个灯 怎么能保证 A B C 上的 指示是同步的不会错?
问题2:A,B,C都有自己的数据库 比如A想改C的某些配置 怎么能保证长时间使用过程中数据库不出错 他们几个的数据库版本是一致的 如果整条链路间做应答机制应该怎么做

问题3:概念问题 怎么确认通信是成功的
A发给 B B回复收到 A回复收到B的应答收到==>这样B也不能确定A收到 所以B又发收到A回复收到B的应答收到A的回复 .......你懂的 那么怎么确认成功呢

解决方案

问题1:A请求B,B收到请求后,请求C,C处理完后返回消息给B,告诉B成功了,B再返回消息给A告诉A成功了。
问题2:如果传输协议可靠,数据本身是可靠的
问题3:A的请求直到收到B的响应后才表示请求成功,若没有收到B的响应,A重试,知道收到响应;给每次请求分配一个唯一的ID(UUID),这样当B由于响应网络问题照成A没有收到response时,A重发,B能判断出这是重发的数据,而不用再次请求C,直接响应给A即可。。。B和C通讯类似

时间: 2025-01-26 18:31:15

通信 tcp wifi-多节点状态同步机制设计的相关文章

Redis内核基于时间点的备份恢复和基于AOF日志的增量同步机制设计

直播视频回顾 Redis内核支持基于时间点的备份恢复 Redis内存数据库,须有一种机制能够把内存中的数据持久化到硬盘上,再将硬盘中数据备份到备份系统中,才能去做恢复.Redis原生的持久化机制包括RDB持久化和AOF持久化两种. RDB持久化 RDB持久化触发方式有两种: 手动触发:执行BGSAVE命令: 自动触发:配置SAVE选项,在指定时间内发生指定次数的key修改,自动进行后台RDB SAVE. RDB持久化流程如下: 在做RDB SAVE时需要fork一个子进程,每次RDB SAVE生

MongoDB原理:复制集状态同步机制

MongoDB复制集(3.0版本)之间通过心跳信息来同步成员的状态信息,每个节点会周期性的向复制集内其它的成员发送心跳信息来获取状态,如rs.status()看到的复制集状态信息. 一次心跳请求分3个阶段 (主动发起心跳请求的节点称为源,接受到心跳请求的成为目标) 源向目标发送心跳请求 目标处理心跳请求,并向源发送应答 源接受到心跳应答,更新目标节点状态 接下来将介绍这3个阶段里的主要状态同步逻辑 阶段1 默认配置下,复制集的节点每隔2s会向其他成员发送一次心跳请求,即发送replSetHear

线程同步机制的区别与比较及进程通信方法

http://hi.baidu.com/wobash/blog/item/4c1de9464899c40f6a63e500.html 线程同步机制的区别与比较及进程通信方法 2008-08-29 14:07 有关多线程的一些技术问题: 1.   何时使用多线程? 2.   线程如何同步? 3.   线程之间如何通讯? 4.   进程之间如何通讯? 先来回答第一个问题,线程实际主要应用于四个主要领域,当然各个领域之间不是绝对孤立的,他们有可能是重叠的,但是每个程序应该都可以归于某个领域: 1.  

udp-手游moba游戏 UDP通信 状态同步

问题描述 手游moba游戏 UDP通信 状态同步 手游moba游戏 UDP通信 状态同步一般同步哪些数据,包括坐标吗?(??_?`) 解决方案 http://www.zhihu.com/question/26795968 解决方案二: 网络通信--UDP

Linux网络文件系统的数据备份、恢复及同步机制

本文将详细介绍针对该网络文件系统的数据备份.恢复及同步机制在内核的具体实现,给广大系统管理员和研发人员提供技术参考.网络文件系统(NFS)协议是由 Sun MicroSystem 公司在 20 世纪 80 年代为了提供对共享文件的远程访问而设计和实现的,它采用了经典的客户机/服务器模式提供服务.为了达到如同 NFS 协议通过使用 Sun 公司开发的远在本机上使用本地文件系统一样便捷的效果,NFS 通过使用远程过程调用协议(RPC Protocol)来实现运行在一台计算机上的程序来调用在另一台远程

MySQL · 引擎特性 · 从节点可更新机制

背景 主从集群,指由一个主数据库实例和多个从数据库实例组成,其中主数据库实例提供读写功能支持,而从数据库不提供对外服务或只提供只读功能支持,但也有从数据库提供读写功能支持,下面就这几种集群架构做详细的解读,并就如何实现从节点可更新机制进行探讨. 主从集群概述 主从集群的实现方式主要有以下几种: 基于磁盘镜像的主备集群 基于Proxy中间件的主从(多主)集群 基于共享磁盘的主从集群 基于日志重放(物理日志或逻辑日志)的主从集群 一.基于磁盘镜像的主备集群 基于磁盘镜像的主备集群是最早出现的一种高可

8天玩转并行开发——第五天 同步机制(下)

         承接上一篇,我们继续说下.net4.0中的同步机制,是的,当出现了并行计算的时候,轻量级别的同步机制应运而生,在信号量这一块 出现了一系列的轻量级,今天继续介绍下面的3个信号量 CountdownEvent,SemaphoreSlim,ManualResetEventSlim.   一:CountdownEvent      这种采用信号状态的同步基元非常适合在动态的fork,join的场景,它采用"信号计数"的方式,就比如这样,一个麻将桌只能容纳4个 人打麻将,如果

iptables的状态检测机制

1.什么是状态检测 每个网络连接包括以下信息:源地址.目的地址.源端口和目的端口,叫作套接字对(socket pairs):协议类型.连接状态(TCP协议)和超时时间等.防火墙把这些信息叫作状态(stateful),能够检测每个连接状态的防火墙叫作状态包过滤防火墙.它除了能够完成简单包过滤防火墙的包过滤工作外,还在自己的内存中维护一个跟踪连接状态的表,比简单包过滤防火墙具有更大的安全性. iptables中的状态检测功能是由state选项来实现的.对这个选项,在iptables的手册页中有以下描

原子变量与非阻塞同步机制(第十五章)

原子变量与非阻塞同步机制 与基于锁的方案相比,非阻塞算法在设计和实现上都要负责得多,但它们在可伸缩性和活跃性上拥有巨大的优势. 原子变量提供了与volatile类型变量相同的内存语义,此外还支持原子的更新操作,从而使它们更加适用于实现计数器.序列发生器和统计数据收集等,同时还能比基于锁的方法提供更高的可伸缩性. 独占锁是一种悲观技术----它假设最坏的情况. 现在,几乎所有的现代处理器中都包含了某种形式的原子读-改-写指令,例如比较并交换(Compare-and-Swap)或者关联加载/条件存储