在进行无线通信时，比如2.4G（并非蓝牙和WIFI这样有协议栈的通信），因为没有协议栈的存在，要求用动态的方式使得两个设备进行配对。
我的想法是这样的：
开始：假设两个设备同时启动（实际是有时间差异），都向外部轮询的丢包和收包，包的内容包括：标识符、请求匹配命令、自身ID
这事就会碰撞了，那么，在等待接收包时进行一个范围内的随机数延时，这时应该是不会接收到包的，但是取随机数之后，因为延时的不同，导致了两个发包时间和收包时间存在差异和交错，就会使得存在一个设备刚刚发送完毕，另一个刚好在等待接收数据包。这样就能正常通信了。
但是，肯定会存在两个设备都能接收到对方的包，然后，识别后，可能都会发送确认包进行确认，包内容包括：标识符、确认握手命令、自身ID和对方ID。
这种情况，当如果只有一方收到，那么另一方再发送握手成功的包，就标识握手成功了，那么“握手成功数据包”发送者理所应当的为主机了，而另一方为从机。
那么这样主机再发送一个开始通信的包进行通知从机，等待从机确认“已准备好”，这样就正式进入了数据的通信。
但是可能事情没有想象的这么好，因为都能正常的收到对方发的包，那么应该如何进行主机和从机的判断呢？或者说怎样让两者自行能够申请到作为主机端或者作为从机端，
能够顺利的握手匹配，不会造成两者因为争抢作为主机而造成死锁现象。
所要讨论的问题如上：目前我并未想好一个比较完善或者说比较好的解决方案！
在无线通信上面，俺是小白！还望大家积极讨论！看看能否有个比较好的解决方案！或者说，有什么很好的协议。
在进行无线通信时，比如2.4G（并非蓝牙和WIFI这样有协议栈的通信），因为没有协议栈的存在，要求用动态的方式使得两个设备进行配对。
我的想法是这样的：
开始：假设两个设备同时启动（实际是有时间差异），都向外部轮询的丢包和收包，包的内容包括：标识符、请求匹配命令、自身ID
这事就会碰撞了，那么，在等待接收包时进行一个范围内的随机数延时，这时应该是不会接收到包的，但是取随机数之后，因为延时的不同，导致了两个发包时间和收包时间存在差异和交错，就会使得存在一个设备刚刚发送完毕，另一个刚好在等待接收数据包。这样就能正常通信了。
但是，肯定会存在两个设备都能接收到对方的包，然后，识别后，可能都会发送确认包进行确认，包内容包括：标识符、确认握手命令、自身ID和对方ID。
这种情况，当如果只有一方收到，那么另一方再发送握手成功的包，就标识握手成功了，那么“握手成功数据包”发送者理所应当的为主机了，而另一方为从机。
那么这样主机再发送一个开始通信的包进行通知从机，等待从机确认“已准备好”，这样就正式进入了数据的通信。
但是可能事情没有想象的这么好，因为都能正常的收到对方发的包，那么应该如何进行主机和从机的判断呢？或者说怎样让两者自行能够申请到作为主机端或者作为从机端，
能够顺利的握手匹配，不会造成两者因为争抢作为主机而造成死锁现象。
所要讨论的问题如上：目前我并未想好一个比较完善或者说比较好的解决方案！
在无线通信上面，俺是小白！还望大家积极讨论！看看能否有个比较好的解决方案！或者说，有什么很好的协议。
那就静候佳音了
参考已有协议，主要是思路上的参考，实现上不可能完全照搬的。
是在公司的平台上实现的！源码的话，除非得花时间去分离出来！后面看看！
，有时间的话，可以！
已有的协议和一些算法，的确可以参考，但仅仅只是参考，因为对于产品来说，这部分只是功能之一，往往很多协议或者算法，跑起来，对CPU都是有要求的！MCU的话，就别想了，就算能跑，跑起来后，干不了太多事了！这是不合理的！
在不涉及版权和商业机密的前提下，可否开源出来，毕竟大家群策群力会更有益于程序的完善和发展，同时也可以避免后来者走同样的弯路。
另外，已有的成熟协议的实现方式应该作为重点参考对象。
这个是我找的，我也看不懂。你说的和智能家居网络，智能交通有些关系。我想到一个办法就是时间同步法，你事先知道一组数据需要多长时间传输与处理，一个数据传输周期大于2倍的处理发送接收周期，这样你可以在这个定义周期内单工通信，因为mcu的当前状态和实际环境有很大关系，你不能确保这两个设备室同时开启的，所以在开机的时候这两个设备需要时间校准同步。为了能够更好的时间同步，需要每隔一定时间内两个设备时间再次同步（可以使一个小时，也可以使一天，一个月），但时间同步法的前提是两个设备正常工作，且可进行通信协议。
根据数据通信的API协议，你可以将标识符、请求匹配命令、自身ID
添入到你的发送和接受数据包内。
我觉得根据硬件的电路，无线模块会有些中断信号。通过接收端查看中断信号，进入处理函数，也可以实现相互通信的功能。
鉴于此，我还是推荐你看下无线组网相关的资料。