Adding the MacReserver class

[notthetup]

Adding the MacReserver Agent.

[mchitre]

Wouldn't requests get queues in order of arrival, and a new request from this agent be granted only after all previous requests are honored? In that case, the ReserveReq won't start a reservation on time, and transmissions will conflict with the other device.

[notthetup]

I guess that depends on the MAC implementation. But that's what will happen for the default CSMA implementation in UnetStack.

The original idea here was that this agent would effectively "hog" the MAC until the user indicated that they were done using the channel, at which point this agent give up the MAC some time and the re-acquire and repeat.

But you're right if LINK has already requested a reservation while this agent was "hogging" the MAC, LINK will get the reservation before this Agent's reservation is accepted.

One way to work around that, albeit evil, is to keep sending ClearReq to the MAC service to clear it's queues. But it'll cause the higher layers to timeout.

[mchitre]

The ReservationNtf mechanism that we have for other agents to tell MAC of inferred reservation may still work for this use case. Send ReservationNtf with a long duration and that will block MAC. Then send a ReservationNtf with duration 0 and that will unblock it.

P.S. We may want to change the semantics of ReservationNtf in UnetStack 5 as the current semantics are quite restrictive. But this will work for now in UnetStack 4.