From 37ccd2c45b0674a3cfc9c8c8b73b30bda084ada9 Mon Sep 17 00:00:00 2001 From: Andras Varga Date: Sat, 23 Sep 2023 14:25:59 +0200 Subject: [PATCH] doc: Users Guide, Developers Guide: spelling fixes immediatelly, modelling, accomodate, etc. --- WHATSNEW | 2 +- doc/src/developers-guide/ch-sockets.rst | 6 +++--- doc/src/developers-guide/ch-tcp.rst | 4 ++-- doc/src/developers-guide/ch-udp.rst | 2 +- doc/src/users-guide/ch-80211.rst | 12 ++++++------ doc/src/users-guide/ch-apps.rst | 14 +++++++------- doc/src/users-guide/ch-clock.rst | 8 ++++---- doc/src/users-guide/ch-collecting-results.rst | 2 +- doc/src/users-guide/ch-diffserv.rst | 4 ++-- doc/src/users-guide/ch-environment.rst | 2 +- doc/src/users-guide/ch-ethernet.rst | 8 ++++---- doc/src/users-guide/ch-introduction.rst | 4 ++-- doc/src/users-guide/ch-ipv4.rst | 10 +++++----- doc/src/users-guide/ch-ipv6.rst | 4 ++-- doc/src/users-guide/ch-lifecycle.rst | 2 +- doc/src/users-guide/ch-mobility.rst | 2 +- doc/src/users-guide/ch-network-autoconfig.rst | 8 ++++---- doc/src/users-guide/ch-network-interfaces.rst | 6 +++--- doc/src/users-guide/ch-other-network-protocols.rst | 2 +- doc/src/users-guide/ch-physicallayer.rst | 2 +- doc/src/users-guide/ch-ppp.rst | 6 +++--- doc/src/users-guide/ch-scenario-scripting.rst | 2 +- doc/src/users-guide/ch-transmission-medium.rst | 6 +++--- .../tsn/gatescheduling/tsnsched/doc/index.rst | 4 ++-- .../timesynchronization/clockdrift/doc/index.rst | 2 +- .../asynchronousshaper/doc/index.rst | 2 +- .../applications/udpapp/UdpVideoStreamServer.ned | 2 +- src/inet/linklayer/ethernet/common/ChangeLog | 2 +- src/inet/networklayer/arp/ipv4/ArpPacket.msg | 2 +- src/inet/transportlayer/sctp/Sctp.h | 2 +- src/inet/transportlayer/sctp/SctpQueue.h | 4 ++-- src/inet/transportlayer/tcp/Tcp.h | 2 +- .../tcp_lwip/lwip/include/lwip/opt.h | 2 +- .../transportlayer/tcp_lwip/queues/TcpLwipQueues.h | 2 +- tutorials/wireless/README | 4 ++-- 35 files changed, 74 insertions(+), 74 deletions(-) diff --git a/WHATSNEW b/WHATSNEW index e69d61039be..8f87bb78bf5 100644 --- a/WHATSNEW +++ b/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: diff --git a/doc/src/developers-guide/ch-sockets.rst b/doc/src/developers-guide/ch-sockets.rst index 12fa030c50c..0ce19d523c4 100644 --- a/doc/src/developers-guide/ch-sockets.rst +++ b/doc/src/developers-guide/ch-sockets.rst @@ -13,7 +13,7 @@ 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. @@ -21,7 +21,7 @@ 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 diff --git a/doc/src/developers-guide/ch-tcp.rst b/doc/src/developers-guide/ch-tcp.rst index 208b112a226..fe923165c82 100644 --- a/doc/src/developers-guide/ch-tcp.rst +++ b/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. diff --git a/doc/src/developers-guide/ch-udp.rst b/doc/src/developers-guide/ch-udp.rst index c4b9e2bd0bc..6d7f80e92a0 100644 --- a/doc/src/developers-guide/ch-udp.rst +++ b/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 diff --git a/doc/src/users-guide/ch-80211.rst b/doc/src/users-guide/ch-80211.rst index d74298c2661..368b7bfacb2 100644 --- a/doc/src/users-guide/ch-80211.rst +++ b/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. diff --git a/doc/src/users-guide/ch-apps.rst b/doc/src/users-guide/ch-apps.rst index 1ac9c495b04..881c839292e 100644 --- a/doc/src/users-guide/ch-apps.rst +++ b/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 diff --git a/doc/src/users-guide/ch-clock.rst b/doc/src/users-guide/ch-clock.rst index fa460aa1be8..7d39533af04 100644 --- a/doc/src/users-guide/ch-clock.rst +++ b/doc/src/users-guide/ch-clock.rst @@ -17,7 +17,7 @@ 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. @@ -25,7 +25,7 @@ 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 ---------- diff --git a/doc/src/users-guide/ch-collecting-results.rst b/doc/src/users-guide/ch-collecting-results.rst index 935c612b3b8..91546ff0fa9 100644 --- a/doc/src/users-guide/ch-collecting-results.rst +++ b/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 diff --git a/doc/src/users-guide/ch-diffserv.rst b/doc/src/users-guide/ch-diffserv.rst index ba6ce70b085..9bc75e45193 100644 --- a/doc/src/users-guide/ch-diffserv.rst +++ b/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. diff --git a/doc/src/users-guide/ch-environment.rst b/doc/src/users-guide/ch-environment.rst index b70f16f6181..dc68a7be2b1 100644 --- a/doc/src/users-guide/ch-environment.rst +++ b/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* diff --git a/doc/src/users-guide/ch-ethernet.rst b/doc/src/users-guide/ch-ethernet.rst index b5a8d4bb0ba..d7cf2c8f900 100644 --- a/doc/src/users-guide/ch-ethernet.rst +++ b/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, diff --git a/doc/src/users-guide/ch-introduction.rst b/doc/src/users-guide/ch-introduction.rst index d9d8ecbfac4..9ac838c816d 100644 --- a/doc/src/users-guide/ch-introduction.rst +++ b/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*.) diff --git a/doc/src/users-guide/ch-ipv4.rst b/doc/src/users-guide/ch-ipv4.rst index 47c06518254..71b17f20fc6 100644 --- a/doc/src/users-guide/ch-ipv4.rst +++ b/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 diff --git a/doc/src/users-guide/ch-ipv6.rst b/doc/src/users-guide/ch-ipv6.rst index 9b6f9101ff4..f3c1e51af6a 100644 --- a/doc/src/users-guide/ch-ipv6.rst +++ b/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`. diff --git a/doc/src/users-guide/ch-lifecycle.rst b/doc/src/users-guide/ch-lifecycle.rst index 71e76bcdc76..2052b290d63 100644 --- a/doc/src/users-guide/ch-lifecycle.rst +++ b/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. diff --git a/doc/src/users-guide/ch-mobility.rst b/doc/src/users-guide/ch-mobility.rst index a9889e20eab..f3064b45fe8 100644 --- a/doc/src/users-guide/ch-mobility.rst +++ b/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 diff --git a/doc/src/users-guide/ch-network-autoconfig.rst b/doc/src/users-guide/ch-network-autoconfig.rst index 95fa454488f..b37a1fe1e65 100644 --- a/doc/src/users-guide/ch-network-autoconfig.rst +++ b/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: diff --git a/doc/src/users-guide/ch-network-interfaces.rst b/doc/src/users-guide/ch-network-interfaces.rst index 110c845fb1a..aadea4d2e07 100644 --- a/doc/src/users-guide/ch-network-interfaces.rst +++ b/doc/src/users-guide/ch-network-interfaces.rst @@ -98,7 +98,7 @@ type like this: When the :par:`typename` parameter of the queue submodule is unspecified (this is the default), the queue module is a :ned:`DropTailQueue`. Conceptually, -the queue is of inifinite size, but for better diagnostics one can often specify +the queue is of infinite size, but for better diagnostics one can often specify a hard limit for the queue length in a module parameter – if this is exceeded, the simulation stops with an error. @@ -286,7 +286,7 @@ settings, it can approximate basic 802.11b ad-hoc mode operation. :ned:`CsmaCaMac` provides a lot of room for experimentation: acknowledgements can be turned on/off, and operation parameters like -inter-frame gap sizes, backoff behaviour (slot time, minimum and maximum +inter-frame gap sizes, backoff behavior (slot time, minimum and maximum number of slots), maximum retry count, header and ACK frame sizes, bit rate, etc. can be configured via NED parameters. @@ -319,7 +319,7 @@ with :ned:`AckingMac`. encapsulation and decapsulation, but no real medium access procedure. Frames are simply transmitted on the wireless channel as soon as the transmitter becomes idle. There is no carrier sense, collision -avoidance, or collison detection. :ned:`AckingMac` also provides an +avoidance, or collision detection. :ned:`AckingMac` also provides an optional out-of-band acknowledgement mechanism (using C++ function calls, not actual wirelessly sent frames), which is turned on by default. There is no retransmission: if the acknowledgement does not diff --git a/doc/src/users-guide/ch-other-network-protocols.rst b/doc/src/users-guide/ch-other-network-protocols.rst index b29e575ef91..2f7d8548472 100644 --- a/doc/src/users-guide/ch-other-network-protocols.rst +++ b/doc/src/users-guide/ch-other-network-protocols.rst @@ -119,7 +119,7 @@ AdaptiveProbabilisticBroadcast :ned:`AdaptiveProbabilisticBroadcast` is a variant of :ned:`ProbabilisticBroadcast` that automatically adjusts transmission -probabilities depending on the estimated number of neighbours. +probabilities depending on the estimated number of neighbors. .. _ug:sec:networkprotocols:wiseroute: diff --git a/doc/src/users-guide/ch-physicallayer.rst b/doc/src/users-guide/ch-physicallayer.rst index 660eca472d2..a0e5283fbc7 100644 --- a/doc/src/users-guide/ch-physicallayer.rst +++ b/doc/src/users-guide/ch-physicallayer.rst @@ -337,7 +337,7 @@ The layered version, :ned:`ApskLayeredRadio` can not only model the processing steps missing from their simpler counterparts, they also feature configurable level of detail: the transmitter and receiver modules have :par:`levelOfDetail` parameters that control which domains are actually -simulated. These radio models must be used in conjuction with +simulated. These radio models must be used in conjunction with :ned:`DimensionalRadioMedium`. .. [1] diff --git a/doc/src/users-guide/ch-ppp.rst b/doc/src/users-guide/ch-ppp.rst index 51a62581a9d..a439c573403 100644 --- a/doc/src/users-guide/ch-ppp.rst +++ b/doc/src/users-guide/ch-ppp.rst @@ -55,13 +55,13 @@ and requests packets from this external queue one-by-one. The name of this queue is given as the :par:`queueModule` parameter. In hosts, no such queue is used, so :ned:`Ppp` contains an internal -queue to store packets wainting for transmission. -Conceptually the queue is of inifinite size, but for better diagnostics +queue to store packets waiting for transmission. +Conceptually the queue is of infinite size, but for better diagnostics one can specify a hard limit in the :par:`packetCapacity` parameter – if this is exceeded, the simulation stops with an error. The module can be used in simulations where the nodes are connected and -disconnected dinamically. If the channel between the PPP modules is +disconnected dynamically. If the channel between the PPP modules is down, the messages received from the upper layer are dropped (including the messages waiting in the queue). When the connection is restored it will poll the queue and transmits the messages again. diff --git a/doc/src/users-guide/ch-scenario-scripting.rst b/doc/src/users-guide/ch-scenario-scripting.rst index 901bddff122..f1be9c765ea 100644 --- a/doc/src/users-guide/ch-scenario-scripting.rst +++ b/doc/src/users-guide/ch-scenario-scripting.rst @@ -14,7 +14,7 @@ configuration. You can schedule actions to be carried out at specified simulation times, for example changing a parameter value, changing the bit error rate of a connection, removing or adding connections, removing or adding routes in a routing table, shutting down or crashing routers, -etc. The aim is usually to observe transient behaviour caused by the +etc. The aim is usually to observe transient behavior caused by the changes. INET supports the following built-in actions: diff --git a/doc/src/users-guide/ch-transmission-medium.rst b/doc/src/users-guide/ch-transmission-medium.rst index d4e1a5ba88c..12179c0d36e 100644 --- a/doc/src/users-guide/ch-transmission-medium.rst +++ b/doc/src/users-guide/ch-transmission-medium.rst @@ -53,7 +53,7 @@ types: .. code-block:: ned propagation: like IPropagation; - analogModel: like IMediumAnalogModel; + analogModel: like IMediumAnalogModel; backgroundNoise: like IRadioBackgroundNoise if typename != ""; pathLoss: like IPathLoss; @@ -382,7 +382,7 @@ the host’s neighbors on the link, which is usually 1 in modern networks that are dominated by point-to-point links. The wireless medium, however, is a broadcast medium. Any transmission is “heard” by all nodes within interference range, not only the intended recipients. The signal -may be receivable by them (and must be indeeded received before the +may be receivable by them (and must be indeed received before the destination address field in it can be examined), or may interfere with the reception of other transmissions. Whichever the case, the transmission must be evaluated or processed by a much larger number of @@ -393,7 +393,7 @@ effects may further increase the exponent. The medium module provides a set of parameters that can be used to alleviate the scalability issue. These *filter* parameters that can be used to reduce the amount of processing at nodes that are not the -indended recipients of the frame, increasing simulation performance. +intended recipients of the frame, increasing simulation performance. There are several filters that can be enabled/disabled individually: diff --git a/showcases/tsn/gatescheduling/tsnsched/doc/index.rst b/showcases/tsn/gatescheduling/tsnsched/doc/index.rst index 9cae99be3c4..6a8dcbc15d7 100644 --- a/showcases/tsn/gatescheduling/tsnsched/doc/index.rst +++ b/showcases/tsn/gatescheduling/tsnsched/doc/index.rst @@ -39,7 +39,7 @@ The following sequence chart shows a gate cycle period (1ms): .. figure:: media/seqchart3.png :align: center -Note that the frames are forwarded immediatelly by the switches. +Note that the frames are forwarded immediately by the switches. The following sequence chart shows frame transmissions, with the best effort gate state displayed on the axes for the two switches. @@ -53,7 +53,7 @@ The following figure shows application end-to-end delay for the four streams: .. figure:: media/delay.png :align: center -All streams have the minimal possible delay, as they are forwarded immediatelly. +All streams have the minimal possible delay, as they are forwarded immediately. Sources: :download:`omnetpp.ini <../omnetpp.ini>` diff --git a/showcases/tsn/timesynchronization/clockdrift/doc/index.rst b/showcases/tsn/timesynchronization/clockdrift/doc/index.rst index 221c493a0df..7ba0a050ca5 100644 --- a/showcases/tsn/timesynchronization/clockdrift/doc/index.rst +++ b/showcases/tsn/timesynchronization/clockdrift/doc/index.rst @@ -173,7 +173,7 @@ The out-of-band synchronization settings are defined in a base configuration, `` Since we want to use clock synchronization, we need to be able to set the clocks, so network nodes have :ned:`SettableClock` modules. The ``defaultOverdueClockEventHandlingMode = "execute"`` setting means that when -setting the clock forward, events that become overdue are done immediatelly. We +setting the clock forward, events that become overdue are done immediately. We use the :ned:`SimpleClockSynchronizer` for out-of-band synchronization. Synchronizer modules are implemented as applications, so we add one to each source host in an application slot. We set the synchronizer modules to sync time diff --git a/showcases/tsn/trafficshaping/asynchronousshaper/doc/index.rst b/showcases/tsn/trafficshaping/asynchronousshaper/doc/index.rst index f9a8414d903..6cda4676847 100644 --- a/showcases/tsn/trafficshaping/asynchronousshaper/doc/index.rst +++ b/showcases/tsn/trafficshaping/asynchronousshaper/doc/index.rst @@ -283,7 +283,7 @@ queue: :align: center At the beginning, the shaper has a burst reserve available, so all incoming -packets are sent immediatelly. When the burst reserve is depleted, the shaper +packets are sent immediately. When the burst reserve is depleted, the shaper starts limiting the outgoing data rate to the committed information rate. Meanwhile, the excess incoming traffic is being stored in the queue. As described previously, the queue has a virtual limit, as packets that would wait diff --git a/src/inet/applications/udpapp/UdpVideoStreamServer.ned b/src/inet/applications/udpapp/UdpVideoStreamServer.ned index 0108ba54470..70aaec146f6 100644 --- a/src/inet/applications/udpapp/UdpVideoStreamServer.ned +++ b/src/inet/applications/udpapp/UdpVideoStreamServer.ned @@ -19,7 +19,7 @@ import inet.applications.contract.IApp; // sendInterval, until videoSize is reached. The parameters packetLen // and 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. +// accommodate jitter. // // The server can serve several clients, and several streams per client. // diff --git a/src/inet/linklayer/ethernet/common/ChangeLog b/src/inet/linklayer/ethernet/common/ChangeLog index 9d69cad92fa..986f86c9d28 100644 --- a/src/inet/linklayer/ethernet/common/ChangeLog +++ b/src/inet/linklayer/ethernet/common/ChangeLog @@ -489,7 +489,7 @@ from the RelayUnit. The new MACTable is ready for future VLAN support. IEEE8021DRelay: added a new relay for supporting STP/RSTP protocols. - The CPU and memory modelling are no longer supported with this relay. + The CPU and memory modeling are no longer supported with this relay. 2013-08-22 ------ inet-2.2.0 released ------ diff --git a/src/inet/networklayer/arp/ipv4/ArpPacket.msg b/src/inet/networklayer/arp/ipv4/ArpPacket.msg index 1031bd0566d..5373a46edb3 100644 --- a/src/inet/networklayer/arp/ipv4/ArpPacket.msg +++ b/src/inet/networklayer/arp/ipv4/ArpPacket.msg @@ -28,7 +28,7 @@ enum ArpOpcode // addresses and IPv4. Packet fields are therefore represented by C++ classes // MACAddress and IPv4Address. Also, some ARP protocol header fields are // not modelled explicitly (their values are implied): -// - hardwareType (not needed for modelling); +// - hardwareType (not needed for modeling); // - protocol type (0x800 IPv4) // - hardware address length (6) // - protocol address length (4) diff --git a/src/inet/transportlayer/sctp/Sctp.h b/src/inet/transportlayer/sctp/Sctp.h index 3c576f3fea9..da192b9f4b8 100644 --- a/src/inet/transportlayer/sctp/Sctp.h +++ b/src/inet/transportlayer/sctp/Sctp.h @@ -60,7 +60,7 @@ class SctpHeader; * SctpAssociation internally relies on 3 objects. The first two are subclassed * from SctpSendQueue and SctpReceiveQueue. They manage the actual data stream, * so SctpAssociation 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 cMessage objects (where every message object is * mapped to a SCTP sequence number range). diff --git a/src/inet/transportlayer/sctp/SctpQueue.h b/src/inet/transportlayer/sctp/SctpQueue.h index 980519185f8..65f5bf35c80 100644 --- a/src/inet/transportlayer/sctp/SctpQueue.h +++ b/src/inet/transportlayer/sctp/SctpQueue.h @@ -21,7 +21,7 @@ class SctpAssociation; /** * Abstract base class for SCTP receive queues. This class represents * data received by SCTP but not yet passed up to the application. - * The class also accomodates for selective retransmission, i.e. + * The class also accommodates for selective retransmission, i.e. * also acts as a segment buffer. * * This class goes hand-in-hand with SctpSendQueue. @@ -30,7 +30,7 @@ class SctpAssociation; * use the SCTP model you might have different ideas about "sending data" * on a simulated connection: you might want to transmit real bytes, * "dummy" (byte count only), cMessage objects, etc; see discussion - * at SctpSendQueue. Different subclasses can be written to accomodate + * at SctpSendQueue. Different subclasses can be written to accommodate * different needs. * * @see SctpSendQueue diff --git a/src/inet/transportlayer/tcp/Tcp.h b/src/inet/transportlayer/tcp/Tcp.h index 4bb9e7dec6a..30c69f68972 100644 --- a/src/inet/transportlayer/tcp/Tcp.h +++ b/src/inet/transportlayer/tcp/Tcp.h @@ -59,7 +59,7 @@ class TcpReceiveQueue; * TcpConnection internally relies on 3 objects. The first two are subclassed * from TcpSendQueue and TcpReceiveQueue. They manage the actual data stream, * so 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 cMessage objects (where every message object is * mapped to a Tcp sequence number range). diff --git a/src/inet/transportlayer/tcp_lwip/lwip/include/lwip/opt.h b/src/inet/transportlayer/tcp_lwip/lwip/include/lwip/opt.h index e7511cc8f3f..777c7fa921e 100644 --- a/src/inet/transportlayer/tcp_lwip/lwip/include/lwip/opt.h +++ b/src/inet/transportlayer/tcp_lwip/lwip/include/lwip/opt.h @@ -899,7 +899,7 @@ namespace tcp { /** * PBUF_POOL_BUFSIZE: the size of each pbuf in the pbuf pool. The default is - * designed to accomodate single full size TCP frame in one pbuf, including + * designed to accommodate single full size TCP frame in one pbuf, including * TCP_MSS, IP header, and link header. */ #ifndef PBUF_POOL_BUFSIZE diff --git a/src/inet/transportlayer/tcp_lwip/queues/TcpLwipQueues.h b/src/inet/transportlayer/tcp_lwip/queues/TcpLwipQueues.h index cd0a0740475..047cf887d2e 100644 --- a/src/inet/transportlayer/tcp_lwip/queues/TcpLwipQueues.h +++ b/src/inet/transportlayer/tcp_lwip/queues/TcpLwipQueues.h @@ -65,7 +65,7 @@ class TcpLwipConnection; * receiving side when its last byte has arrived on the simulated * connection. * - * Different TcpLwipSendQueue subclasses can be written to accomodate + * Different TcpLwipSendQueue subclasses can be written to accommodate * different needs. * * This class goes hand-in-hand with TcpLwipReceiveQueue. diff --git a/tutorials/wireless/README b/tutorials/wireless/README index 7ce407e3f79..8158f1152a7 100644 --- a/tutorials/wireless/README +++ b/tutorials/wireless/README @@ -13,7 +13,7 @@ supposed to demonstrate. Script for the tutorial (work in progress) -========================================== +========================================== The INET Wireless Tutorial contains a series of simulation models numbered. 1 through 16. The models are of increasing complexity -- they start from the @@ -95,7 +95,7 @@ current radio model handles each radio channel independently. 15) To support the modeling of the cross-talk effect we will switch to dimensional analog radio model. This model requires much more processing power, -but allows much more accurate modelling of each packets as they travel through +but allows much more accurate modeling of each packets as they travel through space. 16) Now we are introducing some very short burst radio signals (1ns?) that can