C++中Secheduler和Events用法（12.27）

继续学习下Secheduler和Events：

事件不能部分执行或者提前执行，event由firing time和handler function组成，从Event衍生的两种类型的对象，分别是：Packets和at events

（1）Scheduler::instance().schedule(&CallBack_handler, &callback_event, CALLBACK_DELAY)

CallBack_handler的原型是：UWALOHA_CallBackHandler，其handle方法：

void UWALOHA_CallBackHandler::handle(Event* e)

{

    mac_->CallbackProcess(e);

}

调用Uwalohamac的CallBackProcess函数，

void UWALOHA::CallbackProcess(Event* e)

{

    callback_->handle(e);

}

Handler* callback_;  // for the upper layer protocol，上层协议

（2）s.schedule(&status_handler,&status_event,txtime+0.01);

status_handler：UWALOHA_StatusHandler，主要包含is_ack布尔型参数，当超时时就会调用handler的handle函数，相当于一个定时的任务。

void UWALOHA_StatusHandler::handle(Event *e){

    mac_->StatusProcess(is_ack_);//UWALOHA_StatusHandler存储了is_ack的信息

}

uwaloha.cc的statusProcess函数如下：

void UWALOHA::StatusProcess(bool is_ack){

    UnderwaterSensorNode* n=(UnderwaterSensorNode*) node_;

    n->SetTransmissionStatus(IDLE);    //设置节点为空闲状态

    

    if( blocked ) {

        blocked = false;

        processPassive();

        return;

    }

    

    if( !ACKOn ) {

        /*Must be DATA*/

        UWALOHA_Status = PASSIVE;

        processPassive();

    }

    else if (ACKOn && !is_ack ) {

        UWALOHA_Status = WAIT_ACK;

    }

}

该函数貌似是为了更新状态所用的，但是会有一定的延迟。在sendPkt中，

if 节点 idle:

    if 包 数据包:

        mac对象进入Wait_ACK

        或 直接进入Passive状态

        status_handler.is_ack() = false;

    else ACK包

        发送ACK

        status_handler.is_ack() = true;

    难道说是记录上次发送包的类型？

    发送数据包后将mac对象状态修改为

    blocked = true;

    s.schedule(&status_handler,&status_event,txtime+0.01)，传输时间后更新状态，调用StatusProcess函数

状态转移还不是很清楚，所以需要调试看看在statusProcess之前是什么状态，之后又是什么状态

今天把昨天没看的东西看完了，说白了一天真正工作地没多长时间，所以这个习惯要改阿。

接下来做什么呢？

（1）RSSI全称是“Received Signal Strength Indication”，是接收的信号强度指示，无线发送层的可选部分，用于判定链接质量，可以用于定位，以及是否增大广播发送强度，通常是通过硬件来测试的。

（2）窦志斌的论文用的是累计ACK机制，ACK携带接收段的RSSI值，从而预测下一个时隙的信道强度，如果要借鉴他的思想就要看在仿真层的RSSI模型是在怎么做的

（3）返回的ACK信息，携带信息包括：上一个时隙接收数据包的RSSI，节点剩余能量，

想想要实现的目标是什么：

（1）节省能量：如果信道不号，多次重传消耗能量

（2）为了获得更高的成功率，解决包冲突，因此采用ACK确认机制，为了保证成功率则需要进行重传，而重传是比较消耗能量的。重传的原因是因为节点移动或者干扰（节点移动比较麻烦，还是先考虑静态，干扰可以在底层做文章，但是直接的方法是“符合某种模型的丢包”，这种模型）。

张钢老师的思路，考虑下一跳节点的信道状态，这种方法的好处是同样还是保持着分布式算法的特性，张蕾老师的思路和张钢老师是一样的，在选路是不是依赖位置信息，而是依赖从我到下一跳节点的信息。（这就是下象棋的思路，既然有思路那就得按照这个思路往下走走看）

（1）建立一个合理的丢包模型（泊松模型），也可以是故意延迟回发包。

（2）记录等待到ACK包的时间，backoff的次数，下一条节点的能量信息。

如果是分布式的还有个问题，就是广播出去，在路由层的判断是：<1>我已经转发过这个包；<2>已经有人转发过这个包了；

既然要统计，肯定有个比较，比较的结果是会不会所有的人都不发了？

我隐约懂了，broadcast其实就是flooding，这就是造成了当两个节点对称时，无法接收到包的情况。那么就要规避这种情况，得设计一个能很好的区分的拓扑，其实就是个“移动节点的路由问题”，难道这个就要建立个树？

节点移动相当于丢包

如图所示：

1正常选择4（因为离目标节点更近），把包发给4，4发给5，而5迟迟未反馈给4 ACK，而因此当4再接收到1来的包时，返回给1的ACK将携带信息告知下一跳并不好，让其选择别的节点（这就意味着是有路由表的），或者自己不转发了，让别的节点转发（这个和自身发给5但是没有成功是一样的），那么节点2会转发节点（本来也会转发）

这个思路简单并且容易实现：

2、这么看来一旦迟迟接收不到任何节点的ACK的话，就增大传输功率，能使更多的节点接收到数据包。