doc: users-guide, developers-guide: proofreading of rst files using llm

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

@@ -29,12 +29,12 @@ information with other pieces of documentation, namely:
 
 Why is duplication to be avoided? Multiple reasons:
 
--  It is a waste of our reader’s time they have to skip information they
-   have already seen elsewhere
+-  It is a waste of our reader’s time if they have to skip information they
+   have already seen elsewhere.
 
--  The text can easily get out of date as the INET Framework evolves
+-  The text can easily get out of date as the INET Framework evolves.
 
--  It is extra effort for maintainers to keep all copies up to date
+-  It is extra effort for maintainers to keep all copies up to date.
 
 .. _dg:sec:authorsguide:guidelines:
 
@@ -50,23 +50,23 @@ When describing a module that implements protocol X, do not go into
 lengths explaining what protocol X does and how it works, because that
 is appropriately (and usually, much better) explained in the
 specification or books on protocol X. It is OK to summarize the
-protocol’s goal and principles in a short paragraph though.
+protocol’s goal and principles in a short paragraph, though.
 
 In particular, do not describe the *format of the protocol messages*. It
 surely looks nice and takes up a lot of space, but the same information
-can probably be found in a myriad places all over the internet.
+can probably be found in myriad places all over the internet.
 
 .. _dg:sec:authorsguide:do-not-repeat-neddoc:
 
 Do Not Repeat NED Documentation
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Things like module parameters, gate names, emitted signals and collected
+Things like module parameters, gate names, emitted signals, and collected
 statistics are appropriately and formally part of the NED definitions,
 and there is no need to duplicate that information in this *Guide*.
 
 Detailed information on the module, such as *usage details* and the list
-of *implemented standards* should be covered in the module’s NED
+of *implemented standards*, should be covered in the module’s NED
 documentation, not in this *Guide*.
 
 .. _dg:sec:authorsguide:do-not-repeat-cpp:
@@ -87,5 +87,5 @@ generally capable of, how the parts fit together, how to use the
 provided APIs, what were the main design decisions, etc. Give simple yet
 meaningful examples and just enough information about the API that after
 a quick read, users can “bootstrap” into implementing their own
-protocols and applications. If they have questions afterwards, they
-will/should refer to the C++ documentation.
+protocols and applications. If they have questions afterward, they
+will/should refer to the C++ documentation.

doc/src/developers-guide/ch-developing-models.rst

@@ -11,17 +11,17 @@ Overview
 This section introduces the most important modeling support features of
 INET. These features facilitate the implementation of applications and
 communication protocols by providing various commonly used
-functionality. Thus modeling support allows rapid implementation of new
+functionalities. Thus, modeling support allows for the rapid implementation of new
 models by building on already existing APIs while the implementor can
 focus on the research topics. These features differ from the reusable
-NED modules introduced earlier, because they are available in the form
+NED modules introduced earlier because they are available in the form
 of C++ APIs.
 
 The easy usage of protocol services is another essential modeling
 support. Applications often need to use several different protocol
-services simultaneously. In order to spare the applications from using
+services simultaneously. To spare the applications from using
 the default OMNeT++ message passing style between modules, INET provides
-an easy to use C++ socket API.
+an easy-to-use C++ socket API.
 
 TODO
 
@@ -42,13 +42,13 @@ The @labels Module Property
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The ``@labels`` property can be added to modules and gates, and it
-allows the OMNeT++ graphical editor to provide better editing
-experience. First we look at ``@labels`` as a module property.
+allows the OMNeT++ graphical editor to provide a better editing
+experience. First, we look at ``@labels`` as a module property.
 
 ``@labels(node)`` has been added to all NED module types that may
-occur on network level. When editing a network, the graphical editor
-will NED types with ``@labels(node)`` to the top of the component
-palette, allowing the user to find them easier.
+occur on the network level. When editing a network, the graphical editor
+will show NED types with ``@labels(node)`` at the top of the component
+palette, allowing the user to find them more easily.
 
 Other labels can also be specified in the ``@labels(...)`` property.
 This has the effect that if one module with a particular label has
@@ -74,17 +74,17 @@ making it easier to find.
    }
 
 Module types that are already present in the compound module also appear
-in the top part of the palette. The reason is that if you already added
+in the top part of the palette. The reason is that if you have already added
 a :ned:`StandardHost`, for example, then you are likely to add more of
-the same kind. Gate labels (see next section) also affect palette order:
+the same kind. Gate labels (see the next section) also affect the palette order:
 modules which can be connected to modules already added to the compound
 module will also be listed at the top of the palette. The final ordering
 is the result of a scoring algorithm.
 
 The @labels Gate Property
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Gates can also be labelled with ``@labels()``; the purpose is to make
+Gates can also be labeled with ``@labels()``. The purpose is to make
 it easier to connect modules in the editor. If you connect two modules
 in the editor, the gate selection menu will list gate pairs that have a
 label in common.
@@ -93,7 +93,7 @@ TODO screenshot
 
 For example, when connecting hosts and routers, the editor will offer
 connecting Ethernet gates with Ethernet gates, and PPP gates with PPP
-gates. This is the result of gate labelling like this:
+gates. This is the result of gate labeling like this:
 
 
 
@@ -109,12 +109,12 @@ gates. This is the result of gate labelling like this:
    }
 
 Guidelines for choosing gate label names: For gates of modules that
-implement protocols, use the C++ class name of the packet or acompanying
+implement protocols, use the C++ class name of the packet or accompanying
 control info (see later) associated with the gate, whichever applies;
 append ``/up`` or ``/down`` to the name of the control info class.
 For gates of network nodes, use the class names of packets (frames) that
 travel on the corresponding link, with the ``-conn`` suffix. The
-suffix prevents protocol-level modules to be promoted in the graphical
+suffix prevents protocol-level modules from being promoted in the graphical
 editor palette when a network is edited.
 
 Examples:
@@ -165,28 +165,28 @@ Address Types
 
 The INET Framework uses a number of C++ classes to represent various
 addresses in the network. These classes support initialization and
-assignment from binary and string representation of the address, and
+assignment from binary and string representations of the address, and
 accessing the address in both forms. Storage is in binary form, and they
 also support the "unspecified" special value (and the
 :fun:`isUnspecified()` method) that usually corresponds to the
 all-zeros address.
 
 -  :cpp:`MacAddress` represents a 48-bit IEEE 802 MAC address. The
-   textual notation it understands and produces is hex string.
+   textual notation it understands and produces is a hex string.
 
 -  :cpp:`Ipv4Address` represents a 32-bit IPv4 address. It can parse and
    produce textual representations in the "dotted decimal" syntax.
 
 -  :cpp:`Ipv6Address` represents a 128-bit IPv6 address. It can parse
    and produce address strings in the canonical (RFC 3513) syntax.
 
--  :cpp:`L3Address` is conceptually a union of a :cpp:`Ipv4Address` and
+-  :cpp:`L3Address` is conceptually a union of an :cpp:`Ipv4Address` and
    :cpp:`Ipv6Address`: an instance stores either an IPv4 address or an
    IPv6 address. :cpp:`L3Address` is mainly used in the transport layer
    and above to abstract away network addresses. It can be assigned from
    both :cpp:`Ipv4Address` and :cpp:`Ipv6Address`, and can also parse
    string representations of both. The :fun:`getType()`,
-   :fun:`toIpv4()` and :fun:`toIpv6()` methods can be used to access
+   :fun:`toIpv4()`, and :fun:`toIpv6()` methods can be used to access
    the value.
 
 TODO

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

@@ -19,10 +19,10 @@
    ------
 
    The INET defines these frames in the :file:`EtherFrame.msg` file.
-   The models supports Ethernet II, 803.2 with LLC header, and 803.3 with
+   The models support Ethernet II, 803.2 with LLC header, and 803.3 with
    LLC and SNAP headers. The corresponding classes are:
    :msg:`EthernetIIFrame`, :msg:`EtherFrameWithLlc` and
-   :msg:`EtherFrameWithSNAP`. They all class from :msg:`EtherFrame` which
+   :msg:`EtherFrameWithSNAP`. They all derive from :msg:`EtherFrame` which
    only represents the basic MAC frame with source and destination
    addresses. :ned:`EthernetCsmaMac` only deals with :msg:`EtherFrame`’s, and does
    not care about the specific subclass.
@@ -71,7 +71,7 @@
    In general, if :ned:`Ieee8022Llc` receives a packet from the higher layers,
    it interprets the message kind as a command. The commands include
    IEEE802CTRL_DATA (send a frame), IEEE802CTRL_REGISTER_DSAP (register
-   highher layer) IEEE802CTRL_DEREGISTER_DSAP (deregister higher layer) and
+   higher layer) IEEE802CTRL_DEREGISTER_DSAP (deregister higher layer) and
    IEEE802CTRL_SENDPAUSE (send PAUSE frame) – see EtherLLC for a more
    complete list.
 
@@ -105,11 +105,11 @@
       the interface packets.
 
    Using a control structure is more efficient than the interface packet
-   approach, because the control structure can be created once inside the
+   approach because the control structure can be created once inside the
    higher layer and be reused for every packet.
 
    It may also appear to be more intuitive in Tkenv because one can observe
-   data packets travelling between the higher layer and Ethernet modules –
+   data packets traveling between the higher layer and Ethernet modules –
    as opposed to "interface" packets.
 
    EtherLLC: SAP Registration
@@ -144,10 +144,10 @@
 
    When frames collide the transmission is aborted – in this case the
    transmitting station transmits a jam signal. Jam signals are represented
-   by a :msg:`EthernetJamSignal` message. The jam message contains the tree
+   by an :msg:`EthernetJamSignal` message. The jam message contains the tree
    identifier of the frame whose transmission is aborted. When the
    :ned:`EthernetCsmaMac` receives a jam signal, it knows that the corresponding
-   transmission ended in jamming and have been aborted. Thus when it
+   transmission ended in jamming and has been aborted. Thus when it
    receives as many jams as collided frames, it can be sure that the
    channel is free again. (Receiving a jam message marks the beginning of
    the jam signal, so actually has to wait for the duration of the
@@ -169,7 +169,7 @@
    ~~~~~~~~
 
    When the transmission line is busy, messages received from the upper
-   layer needs to be queued.
+   layer need to be queued.
 
    In routers, MAC relies on an external queue module (see
    :ned:`PacketQueue`), and requests packets from this external queue
@@ -197,7 +197,7 @@
    resume immediately.
 
    :ned:`EthernetCsmaMac` will properly respond to PAUSE frames it receives
-   (:msg:`EtherPauseFrame` class), however it will never send a PAUSE frame
+   (:msg:`EtherPauseFrame` class), however, it will never send a PAUSE frame
    by itself. (For one thing, it doesn’t have an input buffer that can
    overflow.)
 

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

@@ -8,23 +8,23 @@ Introduction
 What is INET Framework
 ----------------------
 
-INET Framework is an open-source model library for the OMNeT++
-simulation environment. It provides protocols, agents and other models
+The INET Framework is an open-source model library for the OMNeT++
+simulation environment. It provides protocols, agents, and other models
 for researchers and students working with communication networks. INET
-is especially useful when designing and validating new protocols, or
+is especially useful when designing and validating new protocols or
 exploring new or exotic scenarios.
 
 INET supports a wide class of communication networks, including wired,
-wireless, mobile, ad hoc and sensor networks. It contains models for the
-Internet stack (TCP, UDP, IPv4, IPv6, OSPF, BGP, etc.), link layer
+wireless, mobile, ad hoc, and sensor networks. It contains models for the
+Internet stack (TCP, UDP, IPv4, IPv6, OSPF, BGP, etc.), link-layer
 protocols (Ethernet, PPP, IEEE 802.11, various sensor MAC protocols,
 etc), refined support for the wireless physical layer, MANET routing
 protocols, DiffServ, MPLS with LDP and RSVP-TE signalling, several
 application models, and many other protocols and components. It also
 provides support for node mobility, advanced visualization, network
-emulation and more.
+emulation, and more.
 
-Several other simulation frameworks take INET as a base, and extend it
+Several other simulation frameworks take INET as a base and extend it
 into specific directions, such as vehicular networks,
 overlay/peer-to-peer networks, or LTE.
 
@@ -34,7 +34,7 @@ Scope of this Manual
 --------------------
 
 This manual is written for developers who intend to extend INET with new
-components, written in C++. This manual is accompanied by the INET
+components written in C++. This manual is accompanied by the INET
 Reference, which is generated from NED and MSG files using OMNeT++’s
 documentation generator, and the documentation of the underlying C++
 classes, generated from the source files using Doxygen. A working