文件列表:

omneteyes\appselector.cc (4405, 2005-10-17)
omneteyes\appselector.h (861, 2005-09-02)
omneteyes\area.ned (155, 2005-09-02)
omneteyes\areamanager.cc (2601, 2005-09-08)
omneteyes\areamanager.h (471, 2005-09-02)
omneteyes\basicmac.cc (10324, 2005-10-24)
omneteyes\basicmac.h (2626, 2005-09-22)
omneteyes\build (49, 2005-09-02)
omneteyes\csma.cc (3315, 2005-09-02)
omneteyes\csma.h (580, 2005-09-02)
omneteyes\csma.ini (88, 2005-09-02)
omneteyes\csmaack.cc (8725, 2005-09-02)
omneteyes\csmaack.h (1267, 2005-09-02)
omneteyes\csmaack.ini (91, 2005-09-02)
omneteyes\csmaca.cc (11486, 2005-09-02)
omneteyes\csmaca.h (1356, 2005-09-02)
omneteyes\csmacaTest.cc (12648, 2005-09-02)
omneteyes\csmacaTest.h (1429, 2005-09-02)
omneteyes\doxy.cfg (50119, 2005-09-02)
omneteyes\eyes.cc (1178, 2005-10-24)
omneteyes\eyes.h (1093, 2005-09-02)
omneteyes\hoplatency.cc (1363, 2005-09-02)
omneteyes\hoplatency.h (375, 2005-09-02)
omneteyes\idle.cc (458, 2005-09-02)
omneteyes\idle.h (338, 2005-09-02)
omneteyes\intmap.cc (2352, 2005-09-02)
omneteyes\intmap.h (696, 2005-09-02)
omneteyes\lmac.cc (4674, 2005-10-03)
omneteyes\lmac.h (642, 2005-09-02)
omneteyes\lmac.ini (90, 2005-09-02)
omneteyes\localbc.cc (1773, 2005-09-02)
omneteyes\localbc.h (373, 2005-09-02)
omneteyes\localgossip.cc (2092, 2005-09-02)
omneteyes\localgossip.h (465, 2005-09-02)
omneteyes\localuc.cc (1585, 2005-09-02)
omneteyes\localuc.h (384, 2005-09-02)
omneteyes\lpl.ini (59, 2005-09-02)
omneteyes\mac.ned (214, 2005-09-02)
omneteyes\maca.cc (6672, 2005-09-02)
omneteyes\maca.h (934, 2005-09-02)
... ...

OMNeTEyes --------- The omneteyes simulator uses OMNeT++ as a core, which you can find at www.omnetpp.org. To completely understand how to use the omneteyes simulator you will have to familiarize yourself with OMNeT++. It has been tested with OMNeT++ 3.2. This has had limited testing with Visual C++, but not by the core team (we thank Antonio Grilo for his help with this) as we are developing solely on Linux machines. As such, we are able to provide .dsp, .dsw and .vcproj files for the simulator, but there are no guarantees about these working. We advise the use of gcc on all platforms, and Visual C++ is *not* supported at all. In order to create the Makefile for your system, please run the supplied "build" script. You can then type "make" to build the simulator. If you have any problems with running the simulator, we will be able to process your bug report faster if you provide us with details of the command line that you use to run our simulator, as otherwise we may well have difficulties reproducing your bug. We have provided some example programs in the scripts/ directory for providing a more easily understood version of the MAC simulator result. These require Perl to run, and more information about them is available in the "Readme" file in that directory. Different message generation scenarios can be provided by editing the test.scen file The idle and active names are a bit deceptive. An idle pattern is one that is simply turned on for the complete simulation. This can be used like a background load generator (from which the name probably derives). Active patterns are patterns that occur at random times (which is also where the area manager comes in to play I think). Internally the names ACTIVE and IDLE are used for the states of an active pattern (just to confuse things a bit ;-) . An IDLE active pattern does not send any messages, while an ACTIVE active pattern does. Active patterns start out IDLE, so this is what the initialisation does. All MAC protocols are derived from BasicMAC (basicmac.(cc|h)) which has some utility functions and models part of our nodes. In particular it provides the functions setRadioListen, setRadioTransmit, and setRadioSleep for managing the radio, startTransmit for actually sending a message out to the ether, and setTimeout and cancelTimeout whereby a timer can be set in approx. 30 micro second ticks, which is the granularity of our crystal driven clock. Finally the function getRssi gets a received signal strength indicator reading. This can be used to detect other sending nodes in the vicinity. Low Power Listening is also implemented in basicmac.cc On the other hand BasicMAC also defines several functions for notifying the MAC protocol. The MAC protocol has to define these (these are virtuals in BasicMAC): timeout - a timer has fired init - protocol initialization rxFrame - notifies the MAC that a packet has been received (and supplies the packet) transmitDone - notifies the MAC that the packet sent with startTransmit has been sent completely rxStarted - notifies the MAC that a startsymbol has been detected by the physical layer rxFailed - notifies the MAC that the reception of the packet has failed. After a rxStarted event, either rxFailed or rxFrame is called. headerLength - should return the number of bytes used for headers in the MAC protocol For communicating with the higher layers (packet generators) a MAC should also implement txPacket by which the higher layers pass packets to the MAC. Further it can call txPacketDone to notify the higher layers that the last packet passed has been sent completely, and rxPacket to pass received packets to the higher layers. The defines at the top of tmac.cc (and other protocols) define times in approx. 30 micro second ticks (in as far as times are defined). A tick is 1/32768 of a second. Please note that the settings for the frame time and listen_timeout in S-MAC (and T-MAC) are usually overridden from the ini-files, and are normally set to 20000 and 500 ticks respectively (610 and 15 milli seconds).

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：