联通网管协议框图

由于协议框架相同 / 但是涉及到的传输方式不同,所以就 不能使用 Google RPC C++ 的服务框架, 而且作为基础协议, 属于应用层的协议, 只能手写代码, 真正的南向网管

由于各厂家的 都使用同一套协议,但是实际的内部逻辑的实现,是区别, 所以在设备维护, 网管维护中, 涉及的问题最多, 如果,用统一的框架逻辑, 网管协议问题的发生,也会响应减少

本身协议难度不大, 协议很完善,所有情况已经考虑到, 只需要实现就可以

国内的运营商不知道会不会再将来使用 NetConfig 作为直放站 基站 BBU的 网络管理的方案

剩下的就是分析 定时器 ，异常处理 ， 告警处理 ，兼容性的设计考虑

轮询的方式 作为定时器 （poll_timeout 实现方式太多了）
告警处理使用 bitmap 的算法 (各种告警屏蔽会很容易, 而且性能也会提高)
对于整个网管的要求, 如果是BBU,基站,RRU,AU,EU 中涉及到的业务模型 很少且单一,开发难度低一些
如果是真正的监控管理中心, 开发难度就大的多了，一般会选择现成的高并发框架，不会自己手写的, 涉及到的业务模型,就多种多样了

我做一个低并发的 监控管理中心, 用做设备的调试,测试,管理, 问题收集,还能练习练习常规算法,（hash map sort stack list queue … …）业务模型的较少,开发起来也较为容易,就是耗时间, 作为第二个个人项目作为合适(x86_64 平台，限制少，第一个 arm平台,其实就是为了方便兼容所有的硬件接口, 做管理,底层处理上还可以,应用处理明显有短板, 而且有过分设计的痕迹,不明确, 框架模型出来了, 但是还得给,而且大概,c++11 标准的语法, 在应用层软件上,应该深入挖掘了)

linux 内核的特点, 面向对象, 常规算法, 流程性的东西已经熟了, 硬核的东西,由基础慢慢深入 ， 常规算法 -> 核心算法
linux 内核驱动子系统 + 网络子系统 才是我的目标
驱动框架+数据结构+芯片规格书+常规算法 = 嵌入式软件开发的核心

纯应用软件的同学,关注的是上层应用, 所以对算法要求高,其实是为了优化处理复杂的业务模型
嵌入式开发的同学, 是呈上启下的 作用, 工作重心,可以偏硬件也可以偏软件，但是是底层开发，因为没有复杂的业务模型, 所以算法要求不高,
随着深入学习发现,系统底层,设计的业务模型很复杂, 没有一个逻辑是多余的，所以也到了学习内核中常规算法+核心算法的阶段