ns3-gym rl-tcp代码逻辑梳理

tcp-rl

由于并不知道怎么在understand里面把部分uml折叠起来，所以只能先截成这么小…大了传不上来(最长的那个是TcpSocketBase which其实在这里不是重点…)
左边竖着的，中间的蓝色的是TcpRlBase，继承了TcpCongestionOpns，说明这个类是个拥塞控制的类

• 我们来看看下面三个小图
  
  TcpRL和TcpRlTimeBased分别是基于事件和基于时间的CC ，在这里，CC实际上就是一个Agent的代表了【但实际上C语言部分Agent的动作还是在tcp-env里面实现的】。
• TcpSocketDerived继承了TcpSocketBase说明他是一个TcpSocket，他的用处实际上是在 rl-tcp-env 中被调用(调用它的GetCongestionControlAlgorithm)，用来识别哪个是我们要监视的Agent.

tcp-rl-env

在sim.cc中要创建OpenGym的Object ptr，这个就是ptr指向的两个类，也是基于事件和时间，和两个Agent类相对应。

• 一方面，实现了white paper里面要求的七个接口(GetObservationSpace、GetObservation、ExecuteMyAction之类的)，还定义了一些回调函数和绑定的过程。

• 注意，这里的TcpGymEnv是一个抽象类，只是用于提供一个接口。具体可以看我另一篇博文：纯虚函数与虚函数

总体思路梳理

• ns3 的C脚本给我们创建了一个动态的环境，但是它这个环境的变量和形式和Gym不是一致的，可是很多人习惯使用Gym的类以及python编程，所以ns3-gym实际上是使用了多线程的方式，基于google的protobuf进行c脚本和python脚本的通信，c这边是进行真实的模拟，然后利用中间件ns3Env，将环境封装成Gym的形式传送给python脚本，python脚本中也会则会使用Gym的接口形式(env.step(),env.get_action() 等 )，实际上也通过中间件再把相应的动作和更新传给ns3，ns3就接着在他的小世界中进行模拟了。