INET 3.8.0

This release requires OMNeT++ 5.7 or 6.0 preview 13. For older OMNeT++ versions please use INET 3.7.x. This version serves as a stepping stone for porting older INET based models to OMNeT++ 6 and INET 4.x. A recommended way is to port first to INET 3.8 (and OMNeT++ 5.7), then upgrade to OMNeT++ 6 and finally port the model to INET 4.x.

Main changes since 3.7:

• MSG files are now in OMNeT++ 6 compatible format (i.e. using --msg6 because OMNeT++ 6 no longer supports --msg4)
• NED files are now compatible with both OMNeT++ 5.7 and 6.0 (i.e. they are explicitly using parent.foo and this.foo in expressions of submodule and connection blocks.)
• Follow OMNeT++ API changes: use AnyPtr instead of void*
• Fix #92: TcpConnection: accepts simultaneous open requests

INET 4.2.6

This release contains compatibility fixes for OMNeT++ 6.0 Preview 12 and OMNeT++ 5.7 Preview 1. It WILL NOT work with OMNeT++ 5.6.x or 6.0pre11 or ealier versions. If you want to use those versions, please use INET 4.2.5.

INET 4.3.3

• This release contains compatibility fixes for OMNeT++ 6.0 Preview 12.
• OMNeT++ 6.0 Preview 11 or earlier versions are NOT supported (use INET 4.3.2 for those versions).

INET 4.2.5

This release contains:

• Compatibility fixes for OMNeT++ 6.0 Preview 11.
• Fixed default type names for 802.15.4 transmitter and receiver.
• Fixed wrong state change signal in Radio
• Fixed crash in rare cases when accessing receptionTimer.

INET 4.2.4

This release contains compatibility fixes for OMNeT++ 6.0 Preview 11.

NOTE: This version works both with OMNeT++ 5.6 and 6.0pre11.

INET 4.3.2

This release contains compatibility fixes for OMNeT++ 6.0 Preview 11.

NOTE: This version does NOT work with OMNeT++ 5.6. It requires OMNeT++ 6.0 Preview 10 or later.

INET 4.2.3

This release contains compatibility fixes for OMNeT++ 6.0 Preview 11.

NOTE: This version works both with OMNeT++ 5.6 and 6.0pre11.

INET 3.7.1

This release contains compatibility fixes for OMNeT++ 6.0 preview 11, and some minor bugfixes:

• localPort parameter didn't take effect in TCPAppBase
• use BYPASS for multicast packets to allow unfiltered multicast traffic in IPSec

INET 4.3.1

Minor bugfixes.

• Fixed bug #646
• Fixed calling base ClockUserModuleMixin class from initialize
• Fixed several smaller issues. See the commit history for details.

INET 4.3.0

This is a new minor stable release of the INET 4.x branch. The highlights of this
release are the infrastructure for Time-Sensitive Networking protocols, the EIGRP
routing protocol and DCTCP congestion control.

For TSN support, a new modular Ethernet MAC and PHY layer model has been added
which provides Ethernet frame preemption, Ethernet cut-through switching, a gating
mechanism for packet queueing, and a clock model which also models clock drifting.

New API level features include intra-node packet streaming, inter-node transmission
update support, bit level packet data identity tracking, and the ability to define
and measure packet flows.

There are also a number of small improvements, and several bug fixes. Some changes
are backward incompatible, so existing models may need to be updated. This version
requires OMNeT++ 6.0 preview 10 or later.

For a complete list of all added, removed, and change folders, NED modules, packet
chunks, packet tags, statistics, C++ classes, and signals please refer to src/ChangeLog.

Notable backward incompatible changes

1. Packet API

The packet tag, chunk tag and chunk region tag APIs have been changed to
store all tags using shared pointers. Moreover, the vectors containing said
tags have also been changed to be stored using shared pointers. These shared
data structures are automatically copied behind the scenes when they are
modified, and they are also shared among multiple packets.

The reasoning is that packets are copied quite often, so this operation must
be very efficient both in terms of space and time. Often the copied packet is
not modified with respect to the attached tags, so it makes sense to share these
data structures. The previous packet API already shared the packet data between
copies, but it didn't share the attached tags.

Internally, the class TagSet has been replaced with another class, SharedTagSet,
and similarly, the class RegionTagSet has been replaced with SharedRegionTagSet.

This change requires the modification of simulation models, because tags are
now returned as shared pointers. Moreover, a different method must be called,
namely the ones with the 'ForUpdate' suffix, to modify existing tags. Due to
this copy-on-write semantics, this change can also break existing user code.

2. Ethernet

Several modules which had an abbreviated Ether in their names have been renamed
to have the complete word, Ethernet, in their names instead. This change affects
many names: EthernetSwitch, EthernetMac, EthernetLink, EthernetSignal, etc.

The Ethernet switch relay functionality provided by the MacRelayUnit and
Ieee8021dRelay modules have been refactored. The most prominent change is that
these modules no longer work on Ethernet frames only. They simply expect the
packets to contain the necessary metadata such as the incoming interface
indication (InterfaceInd) and the source and destination MAC address indication
(MacAddressInd) in order to operate.

A new WireJunction module has been added which replaces the functionality of
the old EtherBus and EtherHub modules. This module represents a generic wiring
hub, and simply broadcasts messages (packets, frames, signals) received on one
port to all other ports, mimicking the propagation of wired electrical signals.

The physical signal class hierarchy has been refactored, the old Signal class
has been split into a generic wireless signal, called WirelessSignal, and
a generic wired signal, called WiredSignal, both subclassed from Signal.

The renames may break existing simulations but they are easy to follow. The
MAC relay changes are internal to network nodes and may only break Ethernet
extension models. All the other changes are likely to produce compilation
errors.

3. IEEE 802.1q support

The old 802.1q support has been removed from the default EthernetInterface,
because it unnecessarily complicated the network interface and it was not
extensible.

The LinkLayerNodeBase base module has been extended with separate and optional
Ethernet and IEEE 802.1q protocol layers, where protocol modules have on instance
per network node. This results in a different structure from the default one
where the Ethernet protocol is part of the network interface. The advantage is
that various additional IEEE 802 protocols such as 802 LLC, 802 SNAP, 802.1q
and 802.1ae are better composable this way.

Several small layered protocol models and infrastructure components have been
added to support these IEEE 802 protocols. These include among others protocol
header inserters and checkers, protocol printers and dissectors, etc.

This change may break simulations that used the old IEEE 802.1q support. They
must be carefully investigated and updated to use the new model instead.

4. VLAN support

The VLAN support has been completely refactored to use separate modules for
filtering and mapping VLAN indications and requests on packets according to
a user-configurable policy. The new VlanIndFilter and VlanReqMapper modules
are part of a VLAN policy module of Ethernet switches by default.

This change may cause simulations to ignore certain parameters which are
expected to affect virtual interfaces and thus break existing simulations.

5. Virtual interfaces

The vlan submodule vector of network nodes inherited from LinkLayerNodeBase
has been renamed to virt. The original name suggested misleadingly that this
set of network interfaces were meant to be used exclusively for VLAN, but that
is not the case. The virtual interfaces, called VirtualInterface, can be used
for all kinds of protocol parameterization such as changing the source MAC
address.

This change may cause simulations to ignore certain parameters which are
expected to affect virtual interfaces.

6. Registering protocols and services

There was some confusion with respect to the expected module gates in the
arguments of the registerService() and registerProtocol() methods. Following
the OSI terminology, the registerService() method now takes the requestIn
and indicationOut gates, the registerProtocol() method takes the requestOut
and indicationIn gates as arguments. This change has been followed with
all affected modules.

Unfortunately, this change may break existing code silently, although not
very likely. The registration calls may provide the incorrect gates to the
MessageDispatcher modules, which in turn will dispatch the packets to the
wrong modules or not at all. Luckily, in the latter case, an error will be
thrown and the simulation terminates.

7. Mobility

All methods in the IMobility interface that returned a Coord or a Quaternion
data structure by value have been changed to return a const reference instead.
These methods, especially the getCurrentPosition() method, may be called quite
often, so avoiding the copying of said data structures increases performance.

This change can be followed easily by implementations, because in most cases
the values were already stored in the mobility modules. This change is not
expected to break existing models silently.

8. Radio medium analog model

Similarly to the IMobility interface change, several methods that returned
or received as an argument a Coord or a Quaternion data structure by value
has been changed to return or receive a const reference instead. Again, these
methods may be called quite often in wireless network simulations, so avoiding
the copying of these data structures increases performance.

This change has very little effect on the implementations, since in most cases
the values were already stored in the related object with a large enough dynamic
extent. This change is not expected to break existing models silently.

9. Queueing model

The IPacketQueue interface has been changed to use explicit enqueuePacket()
and dequeuePacket() methods instead of relying on the generic pushPacket()
and pullPacket().

This change required to updated all existing MAC models to use the new API.
Other 3rd party MAC modules have to be updated accordingly.

10. Renames

Several folders in the physicallayer folder have been moved below the newly
added wired and wireless folders, and renamed. Besides, all support modules have
been moved one level deeper into the common folders. This change helps new
users to find existing physical layer technologies more easily, because they
have their own folders right inside the wired and wireless folders. This change
separates the largely independent wired and wireless physical layer support
modules and implementations.

Similary to the above, several folders in the visualizer folder have been
moved below the newly added canvas and osg folders. This change is required
in order to be able to add separate features for canvas (2D) and OSG (3D)
visualizations.

The InterfaceEntry module that represents network interfaces has been renamed
to NetworkInterface. The old name was a left-over from the time when this
class was really an integral part of the InterfaceTable module. This is no
longer the case, thus the renaming makes perfect sense.

The Protocol::ieee8022 global protocol variable has been renamed, and split
into Protocol::ieee8022llc and Protocol::ieee8022snap.

The queueing API has been updated to reflect the new push/pull duality in
the naming convention as opposed to the old push/pop duality. For example,
the old packetPopped signal has been renamed to packetPulled, and the old
popPacket() method in the IPassivePacketSource has been renamed to pullPacket().

The IPacketQueueingElement C++ interface and the corresponding base class,
called PacketQueueingElementBase, has been renamed to IPacketProcessor and
PacketProcessorBase, respectively. The reason is that, although these classes
are part of the queueing API, they are more general and their original na...