INET 3.99.3 released
171 views
Skip to first unread message
Levente Mészáros
Apr 16, 2018, 4:58:42 AM4/16/18
to omn...@googlegroups.com, omnetpp-an...@googlegroups.com, inetframew...@googlegroups.com
Dear all,
We are happy to announce the release of the last development snapshot of the upcoming INET-4.0 version. All originally planned refactorings have been completed, and we don't expect too many changes until the final version is released. This version requires OMNeT++ 5.3 or later.
You can download the INET-3.99.3 release from github, and read more about what's new in this realease below:
We are happy to announce the release of the last development snapshot of the upcoming INET-4.0 version. All originally planned refactorings have been completed, and we don't expect too many changes until the final version is released. This version requires OMNeT++ 5.3 or later.
You can download the INET-3.99.3 release from github, and read more about what's new in this realease below:
1. Documentation
The somewhat outdated 'INET Framework for OMNeT++ Manual' draft has been split
into two documents. One is called the User's Guide and the other one is called
the Developer's Guide. The reason for the split is that the two documents have
different target audiences, and they focus on introducing different aspects of
the INET Framework.
The User's Guide is intended for users who are mainly interested in assembling
simulations using the existing components provided by the INET Framework. In
contrast, the Developer's Guide is intended for developers who are mainly
interested in developing their own protocols as an addition to the INET
Framework. Both guides are work in progress, but many parts have been added,
deleted, and rewritten compared to the old manual.
2. Packet API
The packet API has been finalized. Several Packet and Chunk functions have been
renamed for better consistency and more clarity. Affected C++ class level and
function level documentation has been updated.
For more details, see the related patch.
3. Packet dissector
The packet API has been extended with a new packet dissector API. The packet
dissector analyzes a packet solely based on the assigned packet protocol and
the data it contains. The analysis is done according to the protocol logic as
opposed to the actual representation of the data. The packet dissector works
similarly to a parser. Basically, it walks through each part (such as protocol
headers) of a packet in order. For each part, it determines the corresponding
protocol and the most specific representation for that protocol.
The packet dissector is mostly implemented in the PacketDissector C++ class.
It relies on small registered protocol-specific dissector classes such as the
Ipv4ProtocolDissector. User defined protocols can register their own protocol
dissector classes to extend the functionality of the generic packet dissector.
4. Packet filter
Filtering packets based on the actual data they contain is a long time missing
functionality of INET. With the help of the new packet dissector API, it is
very simple to create such packet filters.
In order to simplify filtering, INET provides a new generic expression-based
packet filter implemented in the PacketFilter C++ class. The expression syntax
is the same as other OMNeT++ expressions, and the data filter is matched against
individual parts of the packet as found by the packet dissector. For example,
the expression "inet::Ipv4Header and srcAddress(10.0.0.*)" matches all packets
that contains an IPv4 header with a '10.0.0' source address prefix.
5. Packet printer
Based on the new packet dissector, the INET packet printer has been reworked.
The new packet printer is implemented in the PacketPrinter C++ class. It relies
on small protocol specific printer classes to form the user readable string
representation. User defined protocols can register their own protocol printer
classes to extend the functionality of the generic packet printer.
With the OMNeT++ 5.3 version the message printer API has been changed to provide
support for ANSI escape sequences for styling, and for options. The new INET
packet printer allows showing/hiding columns and control various printing
features from Qtenv. The new packet printer provides the following columns in
Qtenv: 'Source', 'Destination', 'Protocol', 'Length', and 'Info' similarly to
the well-known Wireshark protocol analyzer. The info column for simple packets
is assembled inside-out in terms of protocol nesting, but for more complicated
packets (e.g. ones using aggregation) it is assembled left to right.
6. Packet tags
With the OMNeT++ 5.3 version, the old experimental API for attaching tag objects
to packets is no longer available. Meanwhile INET has been extended with a very
similar, although not exactly source code compatible API.
The most important consequence is that cMessage and cPacket instances cannot
have tags attached any more. In order to make dispatching non-packet messages
between protocols still possible, two new cMessage subclasses called Request
and Indication have been introduced. Protocols send instances of said classes
to request services from other protocols or indicate status changes to other
protocols.
7. SCTP
With this new release, SCTP, the last remaining protocol, has also been
ported to the new packet API.
Many thanks to Irene Rüngeler for her valuable contribution.
8. Packet drill
The last remaining application has also been ported to the new packet API.
This application is heavily used for testing UDP, TCP, and SCTP transport
protocols. All tests under the packetdrill folder pass.
9. Mobility
Throughout the mobility API and implementation, speed has been renamed to
velocity where appropriate. The reason is that speed is generally considered
a scalar quantity whereas velocity is considered a vector quantity.
The documentation of orientation has been updated to clarify how exactly it
is meant to be understood. As a somewhat related change, the double type of
angles in mobility models and geographic positioning (longitude, latitude)
has been replaced with compile-time checked C++ types called rad and deg for
clarity.
New mobility models have been added, some of which allow the combination of
existing mobility models. The SuperpositioningMobility combines the trajectory
of several other mobility modules using superposition. The AttachedMobility
provides a mobility that is attached to another mobility at a given offset.
10. Various renames
All network interfaces have been renamed to have 'Interface' suffix in their
names. All signals having the old 'NF_' (obsolete NotificationBoard) prefix
in their names have been renamed according to the new INET signal naming scheme.
Moreover, many functions have been renamed (e.g. camel case) to use the INET
C++ naming scheme.
11. Visualization
Physical transmission medium, data link and physical link, network path, and
packet drop visualizers have been extended with the new packet data filtering.
This allows, for example, to configure several network path visualizers within
an IntegratedMultiCanvasVisualizer to display the path of packets with certain
destination addresses differently.
12. PCAP recording
Similarly to visualization, PCAP recording has also been extended with the
new packet data filtering. This allows recording only certain packets in a
PCAP file, which results in drastically reduced file size and significantly
increased performance.
13. Other notable changes
The protocol registration C++ interface has been changed to provide better
support for the message dispatching mechanism. The result is that protocols
and MessageDispatcher modules can be connected in more flexible ways. In fact,
MessageDispatchers now only have one gate vector to connect to, they learn
where protocols are and act accordingly. Network nodes are free to connect
protocols directly or by using one or several MessageDispatchers as they see
fit.
The physical environment ground model has been extended with a new OSG based
OsgEarthGround model which uses the elevation data of the map. The ground models
have been also extended with the computation of the ground normal vector.
Some globally registered protocol identifiers (e.g. Protocol::ieee80211) have
been split into separate PHY, MAC, and MGMT protocols to disambiguate packet
parts for the packet dissector. This only affects the registered protocol
identifiers, actual protocol implementations are unaffected.
Several MSG file customizations (i.e. @customize) have been refactored or
eliminated altogether by using the new MSG compiler features of OMNeT++. The
main purpose is to simplify MSG files, remove unnecessary C++ customizations,
and to ease understanding and maintaining these files.
Potential infinite loop in the GPSR MANET routing has been fixed.
The somewhat outdated 'INET Framework for OMNeT++ Manual' draft has been split
into two documents. One is called the User's Guide and the other one is called
the Developer's Guide. The reason for the split is that the two documents have
different target audiences, and they focus on introducing different aspects of
the INET Framework.
The User's Guide is intended for users who are mainly interested in assembling
simulations using the existing components provided by the INET Framework. In
contrast, the Developer's Guide is intended for developers who are mainly
interested in developing their own protocols as an addition to the INET
Framework. Both guides are work in progress, but many parts have been added,
deleted, and rewritten compared to the old manual.
2. Packet API
The packet API has been finalized. Several Packet and Chunk functions have been
renamed for better consistency and more clarity. Affected C++ class level and
function level documentation has been updated.
For more details, see the related patch.
3. Packet dissector
The packet API has been extended with a new packet dissector API. The packet
dissector analyzes a packet solely based on the assigned packet protocol and
the data it contains. The analysis is done according to the protocol logic as
opposed to the actual representation of the data. The packet dissector works
similarly to a parser. Basically, it walks through each part (such as protocol
headers) of a packet in order. For each part, it determines the corresponding
protocol and the most specific representation for that protocol.
The packet dissector is mostly implemented in the PacketDissector C++ class.
It relies on small registered protocol-specific dissector classes such as the
Ipv4ProtocolDissector. User defined protocols can register their own protocol
dissector classes to extend the functionality of the generic packet dissector.
4. Packet filter
Filtering packets based on the actual data they contain is a long time missing
functionality of INET. With the help of the new packet dissector API, it is
very simple to create such packet filters.
In order to simplify filtering, INET provides a new generic expression-based
packet filter implemented in the PacketFilter C++ class. The expression syntax
is the same as other OMNeT++ expressions, and the data filter is matched against
individual parts of the packet as found by the packet dissector. For example,
the expression "inet::Ipv4Header and srcAddress(10.0.0.*)" matches all packets
that contains an IPv4 header with a '10.0.0' source address prefix.
5. Packet printer
Based on the new packet dissector, the INET packet printer has been reworked.
The new packet printer is implemented in the PacketPrinter C++ class. It relies
on small protocol specific printer classes to form the user readable string
representation. User defined protocols can register their own protocol printer
classes to extend the functionality of the generic packet printer.
With the OMNeT++ 5.3 version the message printer API has been changed to provide
support for ANSI escape sequences for styling, and for options. The new INET
packet printer allows showing/hiding columns and control various printing
features from Qtenv. The new packet printer provides the following columns in
Qtenv: 'Source', 'Destination', 'Protocol', 'Length', and 'Info' similarly to
the well-known Wireshark protocol analyzer. The info column for simple packets
is assembled inside-out in terms of protocol nesting, but for more complicated
packets (e.g. ones using aggregation) it is assembled left to right.
6. Packet tags
With the OMNeT++ 5.3 version, the old experimental API for attaching tag objects
to packets is no longer available. Meanwhile INET has been extended with a very
similar, although not exactly source code compatible API.
The most important consequence is that cMessage and cPacket instances cannot
have tags attached any more. In order to make dispatching non-packet messages
between protocols still possible, two new cMessage subclasses called Request
and Indication have been introduced. Protocols send instances of said classes
to request services from other protocols or indicate status changes to other
protocols.
7. SCTP
With this new release, SCTP, the last remaining protocol, has also been
ported to the new packet API.
Many thanks to Irene Rüngeler for her valuable contribution.
8. Packet drill
The last remaining application has also been ported to the new packet API.
This application is heavily used for testing UDP, TCP, and SCTP transport
protocols. All tests under the packetdrill folder pass.
9. Mobility
Throughout the mobility API and implementation, speed has been renamed to
velocity where appropriate. The reason is that speed is generally considered
a scalar quantity whereas velocity is considered a vector quantity.
The documentation of orientation has been updated to clarify how exactly it
is meant to be understood. As a somewhat related change, the double type of
angles in mobility models and geographic positioning (longitude, latitude)
has been replaced with compile-time checked C++ types called rad and deg for
clarity.
New mobility models have been added, some of which allow the combination of
existing mobility models. The SuperpositioningMobility combines the trajectory
of several other mobility modules using superposition. The AttachedMobility
provides a mobility that is attached to another mobility at a given offset.
10. Various renames
All network interfaces have been renamed to have 'Interface' suffix in their
names. All signals having the old 'NF_' (obsolete NotificationBoard) prefix
in their names have been renamed according to the new INET signal naming scheme.
Moreover, many functions have been renamed (e.g. camel case) to use the INET
C++ naming scheme.
11. Visualization
Physical transmission medium, data link and physical link, network path, and
packet drop visualizers have been extended with the new packet data filtering.
This allows, for example, to configure several network path visualizers within
an IntegratedMultiCanvasVisualizer to display the path of packets with certain
destination addresses differently.
12. PCAP recording
Similarly to visualization, PCAP recording has also been extended with the
new packet data filtering. This allows recording only certain packets in a
PCAP file, which results in drastically reduced file size and significantly
increased performance.
13. Other notable changes
The protocol registration C++ interface has been changed to provide better
support for the message dispatching mechanism. The result is that protocols
and MessageDispatcher modules can be connected in more flexible ways. In fact,
MessageDispatchers now only have one gate vector to connect to, they learn
where protocols are and act accordingly. Network nodes are free to connect
protocols directly or by using one or several MessageDispatchers as they see
fit.
The physical environment ground model has been extended with a new OSG based
OsgEarthGround model which uses the elevation data of the map. The ground models
have been also extended with the computation of the ground normal vector.
Some globally registered protocol identifiers (e.g. Protocol::ieee80211) have
been split into separate PHY, MAC, and MGMT protocols to disambiguate packet
parts for the packet dissector. This only affects the registered protocol
identifiers, actual protocol implementations are unaffected.
Several MSG file customizations (i.e. @customize) have been refactored or
eliminated altogether by using the new MSG compiler features of OMNeT++. The
main purpose is to simplify MSG files, remove unnecessary C++ customizations,
and to ease understanding and maintaining these files.
Potential infinite loop in the GPSR MANET routing has been fixed.
Hervé Diedie
Apr 18, 2018, 5:09:31 AM4/18/18
to OMNeT++ Users
Badly waiting for INET 4.0
Rudolf Hornig
Apr 18, 2018, 5:37:46 AM4/18/18
to OMNeT++ Users
You can pretty much start using 3.99.3. We don't expect any big changes from now on expect adding more documentation :)
Rashmi Varma
Jun 15, 2018, 3:50:52 AM6/15/18
to omn...@googlegroups.com
well, I started using it for my Zigbee project but I am facing issues with 802.15.4 showcase. It throws error when i try to run Ieee802154ShowcaseUwbIr network.
Reply all
Reply to author
Forward
0 new messages