Rudolf Hornig
This release is the first development snapshot of the upcoming INET-4.0 version.
It contains a number of non-trivial backward incompatible changes compared to the
INET 3.x releases. These changes may require considerable efforts from INET users
to migrate their projects and protocols. The migration may affect INI files, NED
files, and C++ code. Please refer to the INET-4.0 migration guide under 'doc/misc/'
for further details.
The code is still work in progress, which means some details may change until the
final 4.0 version is released. At the moment, it requires a modified version of
OMNeT++ 5.1 or 5.2. The modification is distributed as a patch file in the
'misc/patch' folder.
The highlights of this release are:
Redesigned network node architecture
The internal structure of network nodes has been changed considerably. These
changes have profound effects on how applications are using protocols, and
also on how protocols communicate with each other.With the new architecture, applications are able to use multiple protocols
simultaneously, even if the protocols are part of different protocol layers.
For example, in the old model it was impossible for a StandardHost application
to use TCP and UDP protocols at the same time. This old restriction has been
eliminated. Applications can now talk to any protocol (or several protocols),
even several layers below. The dispatch mechanism necessary for that is now
built into the new network node architecture.Furthermore, protocols don't have to deal with dispatching packets to other
protocols or applications any more. In the old architecture, many protocols
(e.g. IP) implemented their own mechanisms to communicate with multiple
protocols/applications. In the new network node architecture this issue is
solved by the dispatching mechanism, and protocols don't need to implement
their own dispatching.The main component of the new network node architecture is the so-called
MessageDispatcher module type. Such modules are responsible for directing
packets from one protocol to the other and also between applications and
protocols. Most often, MessageDispatcher modules are displayed as horizontal
lines between protocol layers inside the network nodes. Protocols and
applications connect to the dispatcher module directly above and below them.
Dispatchers do not need to be configured because they learn about connected
protocols/application at runtime.Please refer to the 'src/inet/node/base' and 'src/inet/node/inet' folders for
more details.Introduction of packet tags
Packets no longer carry control info data structures while being passed around
in a network node. They have a set of so-called packet tags attached instead.
A packet tag is usually a very small data structure that focuses on a single
parameterization aspect of one or more protocols. For example, a MacAddressReq
tag specifies the requested transmitter and receiver MAC addresses for a MAC
protocol.In general, packet tags come in three flavors: requests (top down), indications
(bottom up), and plain tags (meta data). The naming convention for packet tags
is to use the Req, Ind, or Tag suffix respectively. Tags are usually defined
in MSG files, so that they can be inspected in the runtime environment.Tags can pass through protocol layers and reach far away from the originator
protocol in both the downward and upward direction. This allows protocols to
implement mechanisms that depend on meta data that is not directly present in
a packet. For example, a wireless routing protocol could make more informed
decisions when building the routing table by using the SignalPowerInd tag
attached by the physical layer. Similarly, an application could attach an
InterfaceReq to a packet in order to instruct the routing protocol to use a
particular outgoing interface.The old control info data structures that were used with packets are no longer
available. They have been split into several packet tags. Other control info
data structures that were used with commands are left unchanged. All related
protocols have been updated to use the new packet tags. New tags have also
been introduced which don't have a counterpart in the old data structures.Please refer to the MSG files with the 'Tag.msg' suffix for more details.
Introduction of flat packets
A new packet API is introduced that supports efficient construction, sharing,
duplication, encapsulation, aggregation, fragmentation and serialization. The
new API also supports dual representation, packet data can be accessed both as
raw bytes and as objects.The new API contains two layers, the lower layer focuses on the representation
of data. The primary building block of the lower layer is the Chunk class and
its subclasses. The upper layer builds on top of this and provides the typical
packet, queue and buffer abstractions used by protocols.Nearly all protocols (except SCTP) have been changed to use the new packet API.
This includes TCP, UDP, IPv4, IPv6, AODV, OSPF, RIP, MPLS, Ethernet, PPP,
802.11, etc. Due to the flat nature of the new packet data structure, all old
packet data structures (subclasses of cPacket) have been replaced with chunks
(subclasses of FieldChunk).The various old TCP transfer mode parameters which were used to distinguish
between communicating with simple byte counts, objects, or byte streams are
obsolete. Applications and protocols are free to use any kind of chunk in any
combination. Other protocols will be able to handle such packets transparently
using the new API.Furthermore, all old packet serializer classes have been changed to integrate
with the new packet API. This allows the transparent processing of packets
by protocols independently whether they are actually represented as a sequence
of bytes or as a sequence of field based chunks.NOTE: SCTP has not been ported yet to the new architeture and is currently
excluded from the build.Please refer to the 'src/inet/common/packet' and 'test/packet' folders for
more details.The new implementation has been extensibly tested. We used fingerprint tests
after each change to ensure that all protocol behaviors have been preserved.