CSMA & OMAC interfaces

[WilliamAtSamraksh]

There's been some email interaction on this subject, which I'm posting here so we can track a resolution. I've taken the liberty of doing some minor edits

---

There’s been a lot of work done on OMAC and related classes. I’d like an opportunity to do a review of the interfaces before things are finalized, so that I can bring a user’s perspective to bear. I can, of course, look through the interops on GitHub. Please let me know how best to proceed.

[WilliamAtSamraksh]

From @MukundanAtSamraksh:

I have not looked at any of the recent interface changes. I am writing this email from the “original intent” viewpoint. In the C# dll there is a MAC Interface definition (called IMac or MacI, I don’t remember which), that both CSMA and OMAC implement. In a sense, there should be no change to OMAC interface, if Mac interface definition has not changed. If OMAC offers public APIs not defined in IMac, these must be explicitly justified.

Having said that, when we reviewed interface code (for Dec demo), I remember the initialization of the MAC (both CSMA and OMAC) being too cumbersome. Particularly, changing some of the parameters seemed almost impossible. Also, I remember there being too many similar functions like, Initialize, Configure and Reconfigure, apart from the constructor. One or more of these can be eliminated.

So look at the MAC Interface, that’s the only one that should matter. Ananth, Chris or Bora can point you to the right branch.

[WilliamAtSamraksh]

From @AnanthAtSamraksh:

• OMAC uses the same public APIs as used by CSMA and no new APIs have been added.

• Yes, the MAC interfaces are cumbersome and as Bill pointed out recently, the difficulty is in the way the initialization sequence flows (radioConfig, macConfig and then getting a MAC instance). If the radio type has to be changed in the middle of the program to say Long-Range, then the user has to drop the old radio object, create a new one and pass that to MAC using Reconfigure.

• At present, since the MAC interfaces have not changed, using “Master” is fine. Otherwise, “OMAC_Dev” is the current one for OMAC development which includes some changes to MAC dll’s radio interops.

[WilliamAtSamraksh]

So based on my CSMA experience, my 2 issues are:

1. Be able to produce a class that inherits from CSMA in order to extend the functionality. This is presently possible but awkward since the class CSMA uses a static initializer that emits an instance of CSMA. I realize that we want to restrict CSMA to one instance per radio; but this can be done with a private static field that is checked and updated by the constructor. If we do this it can still be backwards compatible: Initialize and the constructor will do the same thing, and Initialize can be deprecated.
2. Be able to change radio properties without reconstructing the CSMA object. I’d like to be able to instantiate a radio and pass the instance to the CSMA constructor. When a change is made to the radio instance, such as transmit power level, CSMA will adapt automatically. The same for MacConfiguration. So process would be something like this: • Create radio object • Create MacConfiguration object • Create CSMA object based on radio and MacConfiguration objects. CSMA would retain and use the references to the radio & MacConfiguration objects.

[WilliamAtSamraksh]

These are in addition to the Emote.Net annoyances mentioned in #218.

[WilliamAtSamraksh]

I see OMAC in the namespace Samraksh.eMote.Net whereas CSMA is in Samraksh.eMote.Net.Mac.

[WilliamAtSamraksh]

from @AnanthAtSamraksh:

I have modified OMAC to be in the Samraksh.eMote.Net.Mac namespace in the OMAC_Dev branch.

[WilliamAtSamraksh]

From @ChrisAtSamraksh:

As far as number 2 goes, I definitely want that sort of functionality.

What additional functionality do you want to get with 1? What application would it be used for?

[WilliamAtSamraksh]

Re number 1, inheritance. Let’s assume that we’ve sorted out number 2 so that the approach to CSMA instantiation is to create the radio, then the MacConfiguration and then finally CSMA. I’d like to provide, for the user, a ReallySimpleCSMA class that inherits from CSMA and hides the complexity by using defaults for the radio, MAC config, etc. so that all the user would have to do is

var myComm = new ReallySimpleCSMA();

This would create the radio and MAC config objects internally and return the extended CSMA object. Since it would be inheriting from CSMA, it is-a CSMA and could be used wherever a CSMA object is required.

[WilliamAtSamraksh]

And, now there's more. In MacBase there a static Configure method. If I call it twice, it returns a failure value. Here's the method I use:

private void EnactCSMAConfig()
         {
                _macConfig = new MacConfiguration
                {
                       NeighborLivenessDelay = _neighborLivenessDelay,
                       CCASenseTime = _ccaSenseTime,
                };
                _macConfig.radioConfig.SetTxPower(_txPowerValue);

                var retVal = MACBase.Configure(_macConfig, ReceiveHandler, NeighborChangeHandler);
                // Set up CSMA with the MAC configuration, receive callback and neighbor change callback
                if (retVal != DeviceStatus.Success)
                {
                       throw new CSMAException("MACBase.Configure not successful");
                }

                _csma = CSMA.Instance;
         }

Apparently I need to use Reconfigure for the second time, which is odd but OK. However, Reconfigure is an instance method, not a static method. So it looks like I need to create an instance of MacBase int order to reconfigure it. Very strange.

I do hope we can get all this sorted out before the next release.