[Ns-developers] NS-3 Wifi contributions

[Federico Maguolo]

Hi Mathieu,
sorry for the delay. I modify the patch for the new WifiRemoteInterface as you 
suggested. You can find it at the usual link. Can you check if it is good? 
I'll begin to work to the documentation of the methods after April the 14th  
(at the end of my holydays ;-) )

Federico

Alle 17:39, venerdì 21 marzo 2008, Mathieu Lacage ha scritto:
> hi federico,
>
> On Fri, 2008-03-21 at 16:26 +0100, Federico Maguolo wrote:
> > I think that a better solution is to introduce two new methods in the
> > WifiRemoteStation class:
> > -NeedRtsRetransmission
> > -NeedDataRetransmission
> > This two methods are used when a Rts frame or a data frame fail. If you
> > agree with me I've already done a patch which modify the objects. You can
> > find this patch at the usual link
>
> I think you managed to read what I had in mind despite the bad
> description I gave.
>
> > http://www.dei.unipd.it/wdyn/index.php?IDsezione=5517
> >
> > in the section "New retransmission interface for the WifiRemoteStation".
>
> I believe that the m_ssrc/m_slrc counters should be incremented by
> ReportRtsFailed,  ReportDataFailed, ReportRtsOk, and ReportDataFailed
> (all of which are invoked by MacLow) instead of being incremented by
> NeedDataTransmission/NeedRtsTransmission. And, you should reset them
> from ReportRtsFinalFailed and ReportDataFinalFailed which are invoked
> from DcaTxop::MissedCts and DcaTxop::MissedData.
>
> You will need to be careful about the order in which these methods are
> invoked. It might be a great idea to actually write some documentation
> for these above methods (which would include a description of the
> expected call ordering) in
> src/devices/wifi/wifi-remote-station-manager.h. Yes, I know that I
> should have done that myself.
>
> > Moreover, dealing  with this modification I found a problem the default
> > value of a WifiMode has to be set: When you do not specify an explicit
> > value to the attribute, the default value could be set when an object is
> > created. I discovered that it is not true for the DataMode and the
> > CtlMode of the ConstantRateWifiManager. To understand what I mean I
> > suggest to try to run this example:
> >
> > http://www.dei.unipd.it/~maguolo/example.cc
>
> Can you check that the current tree does not have this problem anymore ?
>
> > In the section "Initatial value problem for WifiMode" at the address
> > http://www.dei.unipd.it/wdyn/index.php?IDsezione=5517,  you could find a
> > fix proposal, but I don't know if there are a better ways. Moreover, the
> > patch that you find here integrates the bugfix on the WifiMode, because I
> > saw that the AllocateUid method has the same problem.
>
> The Object part of the patch above has already been fixed in trunk so,
> you probably should update your tree. The AllocateUid method seemed to
> be buggy indeed. I think I understand why it worked despite being buggy
> but I have a hard time figuring out how it could fail. Anyway, I have
> pushed a version which is hopefully more robust: if it still fails,
> please, let me know.
>
> Mathieu