12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788 |
- //
- // Copyright (C) 2003 CTIE, Monash University
- //
- // This program is free software; you can redistribute it and/or
- // modify it under the terms of the GNU General Public License
- // as published by the Free Software Foundation; either version 2
- // of the License, or (at your option) any later version.
- //
- // This program is distributed in the hope that it will be useful,
- // but WITHOUT ANY WARRANTY; without even the implied warranty of
- // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- // GNU General Public License for more details.
- //
- // You should have received a copy of the GNU General Public License
- // along with this program; if not, write to the Free Software
- // Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
- //
- //
- // @page largenet.html, LargeNet model description
- //
- // The ~LargeNet model demonstrates how one can put together models of large
- // LANs with little effort.
- //
- // ~LargeNet models a large Ethernet campus backbone. As configured in the
- // default omnetpp.ini, it contains altogether about 8000 computers
- // and 900 switches and hubs. This results in about 165MB process size
- // on my (32-bit) linux box when I run the simulation.
- // The model mixes all kinds of Ethernet technology: Gigabit Ethernet,
- // 100Mb full-duplex, 100Mb half-duplex, 10Mb UTP, 10Mb bus ("thin Ethernet"),
- // switched hubs, repeating hubs.
- //
- // The topology is in LargeNet.ned, and it looks like this: there's chain
- // of n=15 large "backbone" switches (switchBB[]) as well as four more
- // large switches (switchA, switchB, switchC, switchD) connected to
- // somewhere the middle of the backbone (switchBB[4]). These 15+4 switches
- // make up the backbone; the n=15 number is configurable in omnetpp.ini.
- //
- // Then there're several smaller LANs hanging off each backbone switch.
- // There're three types of LANs: small, medium and large (represented by
- // compound module types ~SmallLAN, ~MediumLAN, ~LargeLAN). A small LAN
- // consists of a few computers on a hub (100Mb half-duplex); a medium
- // LAN consists of a smaller switch with a hub on one of its port
- // (and computers on both); the large one also has a switch and a hub,
- // plus an Ethernet bus hanging of one port of the hub (there's still hubs
- // around with one BNC connector besides the UTP ones).
- // By default there're 5..15 LANs of each type hanging off each backbone
- // switch. (These numbers are also omnetpp.ini parameters like the length
- // of the backbone.)
- //
- // The application model which generates load on the simulated LAN is
- // simple yet powerful. It can be used as a rough model for any
- // request-response based protocol such as SMB/CIFS (the Windows file
- // sharing protocol), HTTP, or a database client-server protocol.
- //
- // Every computer runs a client application (~EtherAppCli) which connects
- // to one of the servers. There's one server attached to switches A, B,
- // C and D each: serverA, serverB, serverC and serverD -- server selection
- // is configured in omnetpp.ini). The servers run ~EtherAppSrv.
- // Clients periodically send a request to the server, and the request
- // packet contains how many bytes the client wants the server to send back
- // (this can mean one or more Ethernet frames, depending on the byte count).
- // Currently the request and reply lengths are configured in omnetpp.ini
- // as intuniform(50,1400) and truncnormal(5000,5000).
- //
- // The volume of the traffic can most easily be controlled with the
- // time period between sending requests; this is currently
- // set in omnetpp.ini to exponential(0.50) (that is, average 2
- // requests per second). This already causes frames to be dropped
- // in some of the backbone switches, so the network is a bit
- // overloaded with the current settings.
- //
- // The model generates extensive statistics. All MACs (and most other
- // modules too) write statistics into omnetpp.sca at the end
- // of the simulation: number of frames sent, received, dropped, etc.
- // These are only basic statistics, however it still makes the
- // scalar file to be several ten megabytes in size. You can use
- // the analysis tools provided with OMNeT++ to visualized the data
- // in this file. (If the file size is too big, writing statistics
- // can be disabled, by putting **.scalar-recording=false in the ini file.)
- // The model can also record output vectors, but this is currently
- // disabled in omnetpp.ini because the generated file can easily reach
- // gigabyte sizes.
- //
- package inet.examples.ethernet.lans;
|