doc: Users Guide, Developers Guide: spelling fixes

immediatelly, modelling, accomodate, etc.

WHATSNEW

@@ -3623,7 +3623,7 @@ STP / RSTP support (802.1d) added to the EthernetSwitch:
      This module allows one to configure network scenarios at Layer 2.
 
    - Replaced the EtherSwitch relay unit with a new, STP/RSTP capable one.
-     The CPU and memory modelling are no longer supported in this relay unit.
+     The CPU and memory modeling are no longer supported in this relay unit.
 
 Nodes automatically pick-up the network configuration on restart:
 

doc/src/developers-guide/ch-sockets.rst

@@ -13,15 +13,15 @@ standard OMNeT++ message passing interface for several communication
 protocols.
 
 Sockets are most often used by applications and routing protocols to
-acccess the corresponding protocol services. Sockets are capable of
+access the corresponding protocol services. Sockets are capable of
 communicating with the underlying protocol in a bidirectional way. They
 can assemble and send service requests and packets, and they can also
 receive service indications and packets.
 
 Applications can simply call the socket class member functions (e.g.
 :fun:`bind()`, :fun:`connect()`, :fun:`send()`, :fun:`close()`) to
 create and configure sockets, and to send and receive packets. They may
-also use several different sockets simulatenously.
+also use several different sockets simultaneously.
 
 The following sections first introduce the shared functionality of
 sockets, and then list all INET sockets in detail, mostly by shedding
@@ -523,7 +523,7 @@ Sending Data
 ~~~~~~~~~~~~
 
 After the connection has been established, applications can send data to
-the remote applica- tion via a simple function call:
+the remote application via a simple function call:
 
 .. literalinclude:: lib/Snippets.cc
    :language: cpp

doc/src/developers-guide/ch-tcp.rst

@@ -164,7 +164,7 @@ There are two additional objects the :cpp:`TcpConnection` relies on
 internally: instances of :cpp:`TcpSendQueue` and :cpp:`TcpReceiveQueue`.
 These polymorph classes manage the actual data stream, so
 :cpp:`TcpConnection` itself only works with sequence number variables.
-This makes it possible to easily accomodate need for various types of
+This makes it possible to easily accommodate need for various types of
 simulated data transfer: real byte stream, "virtual" bytes (byte counts
 only), and sequence of :cpp:`cMessage` objects (where every message
 object is mapped to a TCP sequence number range).
@@ -504,7 +504,7 @@ be :math:`cwnd/2`, :math:`cwnd` will be 1 SMSS.
 TcpReno
 ~~~~~~~
 
-The :cpp:`TcpReno` algorithm extends the behaviour :cpp:`TcpTahoe` with
+The :cpp:`TcpReno` algorithm extends the behavior :cpp:`TcpTahoe` with
 *Fast Recovery*. This algorithm can also use the information transmitted
 in SACK options, which enables a much more accurate congestion control.
 

doc/src/developers-guide/ch-udp.rst

@@ -89,7 +89,7 @@ is -1, then an unused port is selected automatically by the UDP module.
 The localAddress/localPort combination must be unique.
 
 When a packet arrives from the network, first its error bit is checked.
-Erronous messages are dropped by the UDP component. Otherwise the
+Erroneous messages are dropped by the UDP component. Otherwise the
 application bound to the destination port is looked up, and the
 decapsulated packet passed to it. If no application is bound to the
 destination port, an ICMP error is sent to the source of the packet. If

doc/src/users-guide/ch-80211.rst

@@ -78,9 +78,9 @@ are extracted into their own modules.
 
 The new model also separates the following components in the 802.11 standard into modules:
 
--  Coordination function: :ned:`Dcf`, :ned:`Hcf`. The coordination functions control the medium access as specified by the standard.  
+-  Coordination function: :ned:`Dcf`, :ned:`Hcf`. The coordination functions control the medium access as specified by the standard.
 
--  Channel access method as specified by the standard: :ned:`Edca` 
+-  Channel access method as specified by the standard: :ned:`Edca`
 
 -  Channel access function: :ned:`Edcaf`, :ned:`Dcaf`. The channel access function controls channel ownership, etc.
 
@@ -135,7 +135,7 @@ The MAC model has the following replaceable built-in policy submodules by defaul
 
 -  Originator and recipient block ACK agreement policies (e.g. :ned:`OriginatorBlockAckAgreementPolicy`, :ned:`RecipientBlockAckAgreementPolicy`): determine when and what kind of agreements are made
 
--  MSDU aggregation policy (e.g. :ned:`BasicMsduAggregationPolicy`): controls when and which frames are aggregated into an A-MSDU 
+-  MSDU aggregation policy (e.g. :ned:`BasicMsduAggregationPolicy`): controls when and which frames are aggregated into an A-MSDU
 
 -  Fragmentation policy (e.g. :ned:`BasicFragmentationPolicy`): controls when and how fragmentation happens
 
@@ -149,7 +149,7 @@ The MAC model has the following replaceable built-in policy submodules by defaul
 Physical Layer
 --------------
 
-*The physical layer* modules (:ned:`Ieee80211Radio`) deal with modelling
+*The physical layer* modules (:ned:`Ieee80211Radio`) deal with modeling
 transmission and reception of frames. They model the characteristics of
 the radio channel, and determine if a frame was received correctly (that
 is, it did not suffer bit errors due to low signal power or interference
@@ -199,11 +199,11 @@ out these commands by performing the scanning, authentication and
 association procedures, and reports back the results to the agent.
 
 The agent component is currently only needed with the
-:ned:`Ieee80211MgmtSta` module. The managament entities in other NIC
+:ned:`Ieee80211MgmtSta` module. The management entities in other NIC
 variants do not have as much freedom as to need an agent to control
 them.
 
 :ned:`Ieee80211MgmtSta` requires a :ned:`Ieee80211AgentSta` or a custom
 agent. By modifying or replacing the agent, one can alter the dynamic
-behaviour of STAs in the network, for example implement different
+behavior of STAs in the network, for example implement different
 handover strategies.

doc/src/users-guide/ch-apps.rst

@@ -35,7 +35,7 @@ applications use :msg:`GenericAppMsg` objects to represent the data sent
 between the client and server. The client message contains the expected
 reply length, the processing delay, and a flag indicating that the
 connection should be closed after sending the reply. This way
-intelligence (behaviour specific to the modelled application, e.g. HTTP,
+intelligence (behavior specific to the modelled application, e.g. HTTP,
 SMB, database protocol) needs only to be present in the client, and the
 server model can be kept simple and dumb.
 
@@ -99,7 +99,7 @@ arrives on them.
 TcpGenericServerApp
 ~~~~~~~~~~~~~~~~~~~
 
-Generic server application for modelling TCP-based request-reply style
+Generic server application for modeling TCP-based request-reply style
 protocols or applications.
 
 The module accepts any number of incoming TCP connections, and expects
@@ -172,7 +172,7 @@ The application will issue a TCP CLOSE at time :par:`tClose`. If
 TelnetApp
 ~~~~~~~~~
 
-Models Telnet sessions with a specific user behaviour. The server app
+Models Telnet sessions with a specific user behavior. The server app
 should be :ned:`TcpGenericServerApp`.
 
 In this model the client repeats the following activity between
@@ -195,13 +195,13 @@ In this model the client repeats the following activity between
    :par:`reconnectInterval` and the connection is reopened
 
 Each parameter in the above description is “volatile”, so you can use
-distributions to emulate random behaviour.
+distributions to emulate random behavior.
 
 
 
 .. note::
 
-   This module emulates a very specific user behaviour, and as such,
+   This module emulates a very specific user behavior, and as such,
    it should be viewed as an example rather than a generic Telnet model.
    If you want to model realistic Telnet traffic, you are encouraged
    to gather statistics from packet traces on a real network, and
@@ -319,7 +319,7 @@ streaming, it will send UDP packets of size :par:`packetLen` at every
 :par:`sendInterval`, until :par:`videoSize` is reached. The parameters
 :par:`packetLen` and :par:`sendInterval` can be set to constant values
 to create CBR traffic, or to random values (e.g.
-``sendInterval=uniform(1e-6, 1.01e-6)``) to accomodate jitter.
+``sendInterval=uniform(1e-6, 1.01e-6)``) to accommodate jitter.
 
 The server can serve several clients, and several streams per client.
 
@@ -472,7 +472,7 @@ Ethernet applications
 
 The ``inet.applications.ethernet`` package contains modules for a
 simple client-server application. The :ned:`EtherAppClient` is a simple
-traffic generator that peridically sends :msg:`EtherAppReq` messages
+traffic generator that periodically sends :msg:`EtherAppReq` messages
 whose length can be configured. destAddress, startTime,waitType,
 reqLength, respLength
 

doc/src/users-guide/ch-clock.rst

@@ -17,15 +17,15 @@ quantity. All components of the network share the same time throughout the
 simulation independently of where they are physically located or how they are
 logically connected to the network.
 
-In contast, in time sensitive networking, the bookkeeping of time is an essential
+In contrast, in time sensitive networking, the bookkeeping of time is an essential
 part, which should be explicitly simulated independently of the underlying global
 time. The reason is that the differences among the local time of the communication
 network components significantly affects the simulation results.
 
 In such simulations, hardware clocks are simulated on their own, and communication
 protocols don't rely on the global value of simulation time, which is in fact
 unknown in reality, but on the value of their own clocks. With having hardware
-clocks modeled, it's also often required to use various time synhronization
+clocks modeled, it's also often required to use various time synchronization
 protocols, because clocks tend to drift over time and communication protocols
 rely on the precision of the clocks they are using.
 
@@ -53,14 +53,14 @@ The clock API uses the clock time instead of the simulation time as arguments an
 return values. The interface contains functions such as :fun:`getClockTime()`,
 :fun:`scheduleClockEventAt()`, :fun:`scheduleClockEventAfter()`,
 :fun:`cancelClockEvent()`.
- 
+
 INET contains optional clock modules (not used by default) at the network node
 and the network interface levels. The following clock models are available:
 
 -  :ned:`IdealClock`: clock time is identical to the simulation time.
 -  :ned:`OscillatorBasedClock`: clock time is the number of oscillator ticks
    multiplied by the nominal tick length.
--  :ned:`SettableClock`: a clock which can be set to a different clock time. 
+-  :ned:`SettableClock`: a clock which can be set to a different clock time.
 
 Clock Time
 ----------

doc/src/users-guide/ch-collecting-results.rst

@@ -126,7 +126,7 @@ module records all traffic specific to that network interface, and similarly a
 recorder put in the network node records all traffic from the given node. It's
 also possible to put a PCAP recorder module on the network level to produce a
 PCAP file that contains all network traffic. If the traffic of more than one
-network interface is recorded into a signle file, then the newer PCAPng file
+network interface is recorded into a single file, then the newer PCAPng file
 format must be used to also record the data of the corresponding network interfaces.
 
 Recording PCAP traces also supports using packet filters, which in turn allows

doc/src/users-guide/ch-diffserv.rst

@@ -124,7 +124,7 @@ Output Queues
 
 Queue components must implement the :ned:`IPacketQueue` module
 interface. In addition to having one input and one output gate, these
-components must implement a passive queue behaviour: they only deliver a
+components must implement a passive queue behavior: they only deliver a
 packet when the module connected to their output explicitly requests it.
 (In C++ terms, the module must implement the :cpp:`IPacketQueue`
 interface. The next module requests a packet by calling the
@@ -607,5 +607,5 @@ meter and dropping packets that does not conform to the traffic profile.
 There are other queues for AFx classes and BE. The AFx queues use RED to
 implement 3 different drop priorities within the class. BE packets are
 stored in a drop tail queue. Packets from AFxy and BE queues are
-sheduled by a WRR scheduler, which ensures that the remaining bandwith
+scheduled by a WRR scheduler, which ensures that the remaining bandwidth
 is allocated among the classes according to the specified weights.

doc/src/users-guide/ch-environment.rst

@@ -45,7 +45,7 @@ In INET, the physical environment is modeled by the
 instance in the network, and acts as a database that other parts of the
 simulation can query at runtime. It contains the following information:
 
--  geometry and properties of *physical objects* (usually referrred to
+-  geometry and properties of *physical objects* (usually referred to
    as “obstacles” in wireless simulations)
 
 -  a *ground model*

doc/src/users-guide/ch-ethernet.rst

@@ -78,14 +78,14 @@ lengths should be reflected in the delays of the connections.
 Ethernet Bus
 ~~~~~~~~~~~~
 
-The :ned:`WireJunction` component can also model a connection to a 
+The :ned:`WireJunction` component can also model a connection to a
 common coaxial cable found in early Ethernet LANs. Network nodes
 are attached to the :ned:`WireJunction` via a :ned:`DatarateChannel`.
-The :ned:`WireJunction` modules are connected to each other via 
+The :ned:`WireJunction` modules are connected to each other via
 :ned:`DatarateChannel` as well. When a node sends a signal, it will propagate
 along the cable in both directions at the given propagation speed.
 
-The speed of the connection can be set on the datarate channels; 
+The speed of the connection can be set on the datarate channels;
 all connected channels must have the same speed.
 
 .. _ug:sec:ethernet:the-physical-layer:
@@ -142,7 +142,7 @@ of the LLC layer.
 
 Nowadays almost all Ethernet networks operate using full-duplex
 point-to-point connections between hosts and switches. This means that
-there are no collisions, and the behaviour of the MAC component is much
+there are no collisions, and the behavior of the MAC component is much
 simpler than in classic Ethernet that used coaxial cables and hubs. The
 INET framework contains two MAC modules for Ethernet: the
 :ned:`EthernetMac` is simpler to understand and easier to extend,

doc/src/users-guide/ch-introduction.rst

@@ -44,7 +44,7 @@ INET benefits from the infrastructure provided by OMNeT++. Beyond making
 use of the services provided by the OMNeT++ simulation kernel and
 library (component model, parameterization, result recording, etc.),
 this also means that models may be developed, assembled, parameterized,
-run, and their results evaluted from the comfort of the OMNeT++
+run, and their results evaluated from the comfort of the OMNeT++
 Simulation IDE, or from the command line.
 
 INET Framework is maintained by the OMNeT++ team for the community,
@@ -58,7 +58,7 @@ Scope of this Manual
 
 This manual is written for users who are interested in assembling
 simulations using the components provided by the INET Framework. (In
-contrast, if you are interested in modifing INET’s components or plan to
+contrast, if you are interested in modifying INET’s components or plan to
 extend INET with new protocols or other components using C++, we
 recommend the *INET Developers Guide*.)
 

doc/src/users-guide/ch-ipv4.rst

@@ -17,7 +17,7 @@ state information about the individual datagrams, each datagram handled
 independently.
 
 The nodes that are connected to the Internet can be either a host or a
-router. The hosts can send and recieve IP datagrams, and their operating
+router. The hosts can send and receive IP datagrams, and their operating
 system implements the full TCP/IP stack including the transport layer.
 On the other hand, routers have more than one interface cards and
 perform packet routing between the connected networks. Routers does not
@@ -155,7 +155,7 @@ direction, Reverse ARP (RARP).
 The address to be resolved can be either an IPv4 broadcast/multicast or
 a unicast address. The corresponding MAC addresses can be computed for
 broadcast and multicast addresses (RFC 1122, 6.4); unicast addresses are
-resolved using the ARP procotol.
+resolved using the ARP protocol.
 
 If the MAC address is found in the ARP cache, then the packet is
 transmitted to the addressed interface immediately. Otherwise the packet
@@ -216,11 +216,11 @@ IGMP module delivers the IGMP messages not processed by itself to the
 connected routing module.
 
 The :ned:`Igmpv2` module implements version 2 of the IGMP protocol (RFC
-2236). Next we describe its behaviour in host and routers in details.
+2236). Next we describe its behavior in host and routers in details.
 Note that multicast routers behaves as hosts too, i.e. they are sending
 reports to other routers when joining or leaving a multicast group.
 
-Host behaviour
+Host behavior
 ~~~~~~~~~~~~~~
 
 When an interface joins to a multicast group, the host will send a
@@ -241,7 +241,7 @@ Report. When the host receives a General Query on an interface, a timer
 is initialized and a report is sent for each group membership of the
 interface.
 
-Router behaviour
+Router behavior
 ~~~~~~~~~~~~~~~~
 
 Multicast routers maintains a list for each interface containing the

doc/src/users-guide/ch-ipv6.rst

@@ -15,8 +15,8 @@ configuration (address, state, timeouts, etc.) is held in the node’s
 :ned:`InterfaceTable`.
 
 The :ned:`Ipv6NeighbourDiscovery` module implements all tasks associated
-with neighbour discovery and stateless address autoconfiguration. The
-data structures themselves (destination cache, neighbour cache, prefix
+with neighbor discovery and stateless address autoconfiguration. The
+data structures themselves (destination cache, neighbor cache, prefix
 list) are kept in :ned:`Ipv6RoutingTable`. The rest of ICMPv6’s
 functionality, such as error messages, echo request/reply, etc.) is
 implemented in :ned:`Icmpv6`.

doc/src/users-guide/ch-lifecycle.rst

@@ -57,7 +57,7 @@ examples how INET components react to a *crash* lifecycle event:
 While down, network interfaces, and components in general, ignore
 (discard) messages sent to them.
 
-Lifecycle operations are currently instanteneous, i.e. they complete in
+Lifecycle operations are currently instantaneous, i.e. they complete in
 zero simulation time. The underlying framework would allow for modeling
 them as processes that take place in some finite (nonzero) simulation
 time, but this possibility is currently not in use.

doc/src/users-guide/ch-mobility.rst

@@ -446,7 +446,7 @@ assumed to be given as meters, time intervals in seconds and speeds in
 meter per seconds. Attibutes can contain expressions that are evaluated
 each time the command is executed. The limits of the constraint area can
 be referenced as ``$MINX``, ``$MAXX``, ``$MINY``, and ``$MAXY``. Random
-number distibutions generate a new random number when evaluated, so the
+number distributions generate a new random number when evaluated, so the
 script can describe random as well as deterministic scenarios.
 
 To illustrate the usage of the module, we show how some mobility models

doc/src/users-guide/ch-network-autoconfig.rst

@@ -90,7 +90,7 @@ The configurator goes through the following steps:
    most constrained case, the configurator is forced to use the
    requested addresses and netmasks for all interfaces (which translates
    to manual address assignment). There are many possible configuration
-   options between these two extremums. The configurator assigns
+   options between these two extremes. The configurator assigns
    addresses in a way that maximizes the number of nodes per subnet.
    Once it figures out the nodes that belong to a single subnet it, will
    optimize for allocating the longest possible netmask. The
@@ -408,15 +408,15 @@ Multicast routing tables can similarly be configured by adding
    -  a name pattern (e.g. "ppp*") matches the name of the interface
 
    -  a ’towards’ pattern (starting with ">", e.g. ">router*") matches
-      the interface by naming one of the neighbour nodes on its link.
+      the interface by naming one of the neighbor nodes on its link.
 
    Incoming multicast datagrams are forwarded to each child interface
    except the one they arrived in.
 
 The following example adds an entry to the multicast routing table of
-``router1``, that intsructs the routing algorithm to forward
+``router1``, that instructs the routing algorithm to forward
 multicast datagrams whose source is in the 10.0.1.0 network and whose
-destinatation address is 225.0.0.1 to send on the ``eth1`` and
+destination address is 225.0.0.1 to send on the ``eth1`` and
 ``eth2`` interfaces assuming it arrived on the ``eth0`` interface: