《最新Omnet下使用Inet官方demo说明.docx》由会员分享，可在线阅读，更多相关《最新Omnet下使用Inet官方demo说明.docx（30页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、精品资料Omnet下使用Inet官方demo说明.A Guided TourContentsIntroductionThe purpose of this tutorial is to get you familiar with the INET framework, a simulation model suite for TCP/IP and Internet-related protocols, written for the OMNeT+/OMNEST simulation environment. This tutorial is based on the ARPTest examp
2、le simulation. To try it, you need a binary (executable) version of this simulation. The easiest is to download and install the Windows demo for INET. Alternatively (or if your platform is Linux or some other OS), you may download and compile the OMNeT+ and INET source packages. Launching the ARPTes
3、t simulationWhen you start the INET demo package (if you installed the Windows demo, youll find the INET demo on the Start Menu; if you compiled INET yourself, find and run Examples/rundemo.bat), youll see a window like this: Click the button which says ARP Test on the left - a description of the mo
4、del should appear in the main window. Click the large Launch button on the bottom, and the ARP simulation model should start. The GUI at the first glanceThe picture you see will look like this. The window in the back is the main OMNeT+/OMNEST window, closing it will exit the program. The large text
5、window on the right side displays log messages from the simulation model (output from ev statements in the C+ code will write there), and the left-hand displays the model objects in a foldable tree form. Theres a 3-line status bar at the top (well look at it later), and a toolbar to access frequentl
6、y used functions of the GUI. The front window displays the simulation model. If you happen to accidentally close it, you can open it again by clicking the Inspect network toolbar icon. Lets run the simulation!Click on the Run button on the main windows toolbar, or hit F5. First you should see messag
7、es labelled autoconf being exchanged by the nodes, as part of the Ethernet model autoconfiguration process: Then, at about 1ms simulation time, autoconfig finishes, and simulating the network operation begins. In the model scenario, the client computer (laptop icon) opens a TCP connection to the ser
8、ver (server icon) at 1s, and starts sending a large data stream. The server will just echo the data sent by the client. Since the underlying network is Ethernet, before being able to send the TCP SYN packet the client has to perform an ARP request to learn the MAC address for the default router. Aft
9、er some more messaging, the TCP connection will be established and data transfer begins. Well explore these happenings in the network later, but for now just sit back and watch the simulation. You can make the animation faster or slower by adjusting the slider at the top of the network window. You c
10、an stop the simulation by clicking the red STOP traffic sign icon (or by hitting F8), and resume it (Run icon or F5). The Fast icon or (F6) will turn off message animation and update the graphics only every 10 events or so (the exact number can be configured in the Simulation Options dialog, Options
11、 menu, accessible from via the toolbar as well). The Express icon provides the highest speed: it turns off all GUI functions while the simulation is running, even writing to the log is turned off. Express mode updates the display every 1000 events or so (also configurable in Simulation Options). In
12、Express mode you can only stop the simulation by clicking the Big Red STOP Button (see below). Simulation speed in Express mode may significantly depend on the state of the auto update inspectors checkbox. You can read the speed of the simulation on the 3rd line of the main window status bar. Ev/sec
13、 tells you how many events your CPU crunches in a second - this depends on the strength of your hardware, on the amount processing (C+ code) to be done for an average event (refer to the handleMessage(cMessage *) functions in the model source), and on the run mode (Normal, Fast or Express). It is no
14、t unusual for the Express mode to be 100-200 times faster than Fast mode. The other two readings on that status bar are simsec/sec (how many simulated seconds the model progresses in one real second) and ev/simsec (how many events your model contains per simulated second). The simsec/sec value is us
15、eful for estimating how long your simulation will take. Ev/simsec is independent of whether you use Normal, Fast or Express mode, and it only depends on the nature and size of your model (ATM cell-level simulations will have a few magnitudes higher ev/simsec values than call center simulations.) Ove
16、r? You can restart it!While in Expess mode, youll probably get the following dialog after a while: No more events is one way a simulation can terminate normally (i.e. not with an error). It means that theres nothing more to simulate - in our simulation this occurs when the client has successfully cl
17、osed the TCP connection and finished its operation, and therere no more packets underway and no timers running anywhere in the whole model. Other simulations may end with the Simulation time limit reached - simulation stopped message which means that the simulation time configured in omnetpp.ini has
18、 been reached. (For completeness: other possibilities include CPU time limit reached, and Simulation stopped with endSimulation() meaning that some component in the model called the endSimulation() C+ function - for example when it detects that desired statistical accuracy has been reached). In both
19、 cases you can restart the simulation using the Rebuild network command on the Simulate menu. In fact, you can do that any time to start over. Note that some simulation models (none in INET, hopefully) may crash when you restart the simulation. This is usually due to badly written destructor code in
20、 the model C+ sources. Now that weve dealt with the basics, we can go back to our ARPTest network model. OK, but what are those flashing link colors?Youve probably seen something like this: If a link is yellow, that means the node is transmitting on the link. If a node has collided and while its bac
21、king off, the link is colored red. Link coloring has been programmed as part of the Ethernet model (the EtherMAC module). The wandering red frame (around router5 on the screenshot) has nothing to do with Ethernet - it simply indicates the location of the current/next event in the model, as dictated
22、by the basic event processing algorithm of discrete event simulation. What is inside the hosts and routers?I bet youve found it out already, but here it is for the record: you can double-click on a node (client, server, router) to see its internals. Bottom up, the client model contains: an Ethernet
23、interface (eth0); network layer (networkLayer, a further double-click will reveal its basically IP); a pinger application (pingApp, defunct in this model); UDP model (udp), also not used in the ARPTest model (no applications configured); TCP model (tcp). The number of connections in various TCP stat
24、es are displayed in blue above the icon; an application model (tcpApp0) the routingTable module contains, well, the routing table (number of unicast+multicast routes displayed above the icon) blackboard is there for future extensions (it will be used in in the future as a storage place for various p
25、arameters and state variables different protocol layers need to share) A router is similar, but obviously it has nothing from L3 up. (You also see no routing protocols - routing is static in this model.) If you further double-click on these components (TCP, UDP, etc.), most of the time youll get an
26、inspector window like this. It means that the component is implemented in C+, and cannot be subdivided any further (it is a simple module, as opposed to compund modules which are composed of submodules). The inspector window exposes the internals of the module and well use it a lot later in this wal
27、kthrough, but lets just leave it for now. The ARPTest simulation is quite complex in that it has TCP, IP, ARP and Ethernet in it. In this walkthrough well go for ARP, but the steps you learn will be useful for exploring other protocols as well. Steps towards exploring ARPIf we are interested in ARP,
28、 its a bit annoying that we have to wade throught all those Ethernet autoconfig messages until we get to the first ARP request at 1s. Luckily, you can use the Run until. function to fast-forward past them. Restart the simulation (Simulate|Rebuild network), then click the Run until. icon on the toolb
29、ar. We know autoconfig finishes at around 1ms simulation time and first ARP request is around 1s, so you can safely enter 2ms in the Run until dialog. After clicking OK, the simulation progresses past the autoconfig period in no time. Then, both the red frame around the laptop icon (the next event m
30、arker) and the top line of the status bar will show that the next event is going to take place in the client PC, at t=1s simulation time. Opening scheduled-events in the object tree (left side of main window) will also reveal that we have only one event, and it is going to occur in the client applic
31、ation (client.tcpApp0). Pressing F4 (single-step) repeatedly will take you though the next events. Youll see as the application tells TCP to open a connection, as TCP obeys and sends a SYN (TCP connection request) packet, as IP encapsulates SYN into an IP datagram, and sends it down to the Ethernet
32、interface. We could actually peek into those messages and find out about TCP ports and IP addresses and lots of interesting things, but lets resist the temptation and concentrate on ARP. You probably noticed that the IP datagram has disappeared in the Ethernet interface. This indicates that eth0 is
33、a compound module, and if you open it (double-click), youll find that it consists of 3 submodules (arp, encap and mac) and the IP datagram is sitting on the input of the arp module. Here we are at the beginning of the interesting part. You may actually take a note that we are at event #94 (its displ
34、ayed in the top line of the main window status bar) so that next time you can quickly get here using the Run until. dialog (it can stop either at a simulation time or at an event number - or if you enter both, itll stop at whichever comes first.) ARP beginsThe arp module will tell us whats going on
35、by writing a log. These log messages (output via ev from the C+ code) will appear in the main text window, but thatll soon be useless because other modules dump their output there too. Luckily, we can open a window which contains arps messages only. Right-click on the arp module, and select Module o
36、utput from the context menu. A new text window, titled (ARP)arpTest.client.eth0.arp will appear. Then press F4 (or click the Step icon on the main windows toolbar) to perform the next event and let arp process the datagram. Youll see that: the datagram disappers inside arp; arp sends an ARP request
37、the arp text window comments what happened At this point your screen will look something like this. ARP maps L3 addresses (IP address) to L2 addresses (Ethernet MAC address). It uses a lookup table (ARP cache) for this purpose, but if an IP address is not found in the table, ARP has to ask around by
38、 sending a broadcast ARP Request. Thats what we have seen here. Lets check it in detail! The ARP Request packetDouble-click on the ARP request packet to open its inspector window, then click the Fields tab. The Fields page shows the contents of the ARP packet: source MAC address, destination MAC add
39、ress, source IP address, destination IP address. The source MAC and IP addresses are our own addresses (in the model, autoconfigured MAC addresses begin with 0A AA); the destination IP address contains the address to be resolved, and the destination MAC address is empty because thats what were reque
40、sting. The ARP packet is a single C+ object, with its class ARPPacket having an int _opcode data member, int opcode() and setOpcode(int) functions, and similar data and functions for the other data fields as well. However, the class was not hand-coded but generated from a .msg file, which has a very
41、 concise format: / file: ARPPacket.msgmessage ARPPacket fields: int opcode enum(ARPOpcode); MACAddress srcMACAddress; MACAddress destMACAddress; IPAddress srcIPAddress; IPAddress destIPAddress;Definition via a .msg file not only saved a lot of programming effort, but it was also necessary for the pa
42、ckets content to be displayed in the Fields page. So far so good, but how do lower layers (Ethernet) know which MAC address the ARP request should be sent to? Thats not part of the packet! This information is attached to the packet in small data structure called control info. Control info is also a
43、C+ object and similarly to packets, its C+ source is generated from .msg files. You can view the contents of the control info attached to this ARP packet by clicking the Control info tab in the window. / file: EtherCtrl.msgclass EtherCtrl fields: MACAddress src; / used with ETHCTRL_DATA MACAddress d
44、est; / used with ETHCTRL_DATA int etherType; / used with ETHCTRL_DATA and EthernetIIFrame int ssap; / used with ETHCTRL_DATA and EtherFrameWithLLC int dsap; / used with ETHCTRL_DATA/REGISTER_DSAP/DEREGISTER_DSAP int pauseUnits; / used with ETHCTRL_PAUSE;It says that source MAC address is not specifi
45、ed (all zero - in this case itll be filled in by Ethernet) and the destination MAC address is all FFs (the Ethernet broadcast address). SSAP and DSAP are unused here (theyre for 802.3 frame type but we use Ethernet II frames in this simulation), and pauseUnits has also no significance (only used for
46、 telling MAC to send PAUSE frames). etherType is set to zero here. The pending queueWhile ARP resolution is pending, IP datagrams which wait for it have to be buffered somewhere. Theres a q=1 label next to the arp icon - if you double-click on it (on the q=1 text, not on the icon!), an inspector win
47、dow will open displaying the queue of buffered datagrams. You may double-click on the SYN line again, to view the datagrams contents (source and destination IP address, TTL, encapsulated protocol, etc.) in an inspector window, much the same way as it worked with the ARP request packet. One extra is
48、worth mentioning, however: on the General page youll find the Encapsulated message button which will take you to the TCP packet in the datagram - and you can continue exploring the TCP header fields. The ARP cacheYouve noticed the blue letters 1 cache entries, send req:1 repl:0 fail:0 above the arp icon, a