IApp¶

module interface IApp

Generic application interface.

Usage diagram¶

Inheritance diagram¶

Implemented by¶

Name	Type	Description
SimpleClockSynchronizer	simple module	Periodically synchronizes the slave clock to the master clock with the specified accuracy. The synchronization happens directly using C++ method calls and without any packet exchange. This is primarily useful when the overhead of the time synchronization protocol messages can be safely ignored.
SinkApp	compound module	Implements a generic sink application.
SourceApp	compound module	Implements a generic source application.
DhcpClient	simple module	Implements the DHCP client protocol. DHCP (Dynamic Host Configuration Protocol), described in RFC 2131, provides configuration parameters to Internet hosts. Requires UDP.
DhcpServer	simple module	Implements the DHCP server protocol. DHCP (Dynamic Host Configuration Protocol), described in RFC 2131, provides configuration parameters to Internet hosts. Requires UDP.
EthernetApp	compound module	Generates traffic as an Ethernet application. The traffic source and traffic sink modules can be built from queueing model elements.
EthernetSinkApp	compound module	Implements an Ethernet application that only receives packets.
EthernetSourceApp	compound module	Implements an Ethernet application that only sends packets.
ExternalApp	compound module	Provides an external application that uses a host OS external process.
Ieee8022LlcApp	compound module	Generates traffic as an IEEE 802.2 LLC application. The traffic source and traffic sink modules can be built from queueing model elements.
Ieee8022LlcSinkApp	compound module	Implements an IEEE 802.2 LLC application that only receives packets.
Ieee8022LlcSourceApp	compound module	Implements an IEEE 802.2 LLC application that only sends packets.
IpApp	compound module	Generates traffic for a IP application. The traffic source and traffic sink modules can be built from queueing model elements.
IpSinkApp	compound module	Implements an IP application that only receives packets.
IpSourceApp	compound module	Implements an IP application that only sends packets.
NetPerfMeter	simple module	Application model for comparing the performance of various transport protocols.
PingApp	simple module	Generates ping requests to several hosts (or rather, network interfaces), and calculates the packet loss and round trip times of the replies. It works exactly like ‘ping’ except that it is possible to specify several destination addresses as a space separated list of IP addresses or module names. (The `L3AddressResolver` class is used to resolve the address.) Specifying ‘*’ allows pinging ALL configured network interfaces in the whole simulation. This is useful to check if a host can reach ALL other hosts in the network (i.e. routing tables were set up properly).
QuicClient	simple module	(no description)
QuicDiscardServer	simple module	A QUIC server that reads and discards all received data.
QuicOrderedReceiver	simple module	A QUIC server that reads and discards all received data.
QuicZeroRttClient	simple module	(no description)
SctpClient	simple module	Client app for SCTP-based request-reply protocols. Handles a single session (and SCTP connection) at a time.
SctpNatPeer	simple module	Implements a peer application for SCTP NAT traversal. Supports both standard and rendezvous connection establishment methods to traverse NAT devices. Exchanges NAT traversal information with other peers and handles data transfer with configurable parameters. Supports multi-homing with multiple addresses.
SctpNatServer	simple module	Implements a rendezvous server for SCTP NAT traversal. Facilitates communication between peers behind NAT devices by maintaining connection information and exchanging address details between peers. Handles multi-homed connections and processes address addition notifications. Enables direct peer-to-peer communication by providing each peer with the necessary connection details of the other peer.
SctpPeer	simple module	Implements a versatile SCTP application that can function as both client and server simultaneously. Supports sending and receiving data with configurable parameters including multi-streaming, PR-SCTP, and stream reset capabilities. Provides options for echo functionality, ordered/unordered delivery, and configurable think times between transmissions.
SctpServer	simple module	Server app for SCTP-based request-reply protocols. Handles a single session (and SCTP connection) at a time.
TcpBasicClientApp	simple module	Client for a generic request-response style protocol over TCP, to be used with TcpGenericServerApp.
TcpClientApp	compound module	A generic, very modular TCP client application, similar to TcpServerApp. The traffic source and traffic sink modules can be built from queueing model elements.
TcpEchoApp	simple module	Accepts any number of incoming TCP connections, and sends back the data that arrives on them. The `echoFactor` parameter controls the amount of data to be sent back. If echoFactor==1, the received data is echoed back without change. For any other positive value of `echoFactor`, a message of appropriate length (datalen*``echoFactor``) without content (see `ByteCountChunk` C++ class) is sent back.
TcpGenericServerApp	simple module	Generic server application for modeling TCP-based request-reply style protocols or applications.
TcpRequestResponseApp	compound module	A generic request/response based server application. For each request it receives, it generates a different traffic based on the data the request contains. The client application can be any source that is capable of generating packets with different data. The first byte of the packet data determines the response traffic, which can be configured to produce complex streams of packets with various data and timing distributions.
TcpServerApp	compound module	A generic, modular TCP server application. It is composed of a listener module that listens on a port to accept TCP connections, and for each incoming TCP connection it dynamically creates a new module in the connection[] submodule vector to handle the connection.
TcpServerConnection	compound module	This is a pre-assembled module type to be used in TcpServerApp. One instance of this module type is launched by TcpServerListener for each incoming connection. It is composed of a traffic source, a traffic sink, a socket I/O and other modules, and most of the module types are parametric. The traffic source and traffic sink modules can be built from queueing model elements.
TcpServerHostApp	simple module	Hosts TCP-based server applications. It dynamically creates and launches a new “thread” object for each incoming connection.
TcpSessionApp	simple module	Single-connection TCP application: it opens a connection, sends the given number of bytes, and closes. Sending may be one-off, or may be controlled by a “script” which is a series of (time, number of bytes) pairs. May act either as client or as server. Compatible with both IPv4 (Ipv4) and IPv6 (Ipv6).
TcpSinkApp	compound module	Accepts any number of incoming TCP connections, and discards whatever arrives on them. Compatible with both Ipv4 and Ipv6.
TelnetApp	simple module	Models Telnet sessions with a specific user behavior. The server app should be TcpGenericServerApp. Compatible with both Ipv4 and Ipv6.
TelnetClientApp	compound module	This client application contains a configurable pre-composed telnet traffic source and traffic sink.
TelnetServerApp	compound module	This server application accepts and creates telnet server connections.
TelnetServerConnection	compound module	Contains a configurable pre-composed telnet traffic source and traffic sink as part of a telnet server application.
TrafficgenCompound	compound module	(no description)
TunLoopbackApp	simple module	Provides loopback functionality for a TUN interface by receiving packets, swapping source and destination addresses and ports, and sending them back through the same interface. Processes both network and transport layer headers to properly reverse packet direction. Useful for testing network configurations and protocols without requiring external connections.
TunnelApp	simple module	Relays packets between a pre-existing tunnel endpoint (a local TUN interface) and a remote network address using either UDP or IPv4 protocols.
UdpApp	compound module	Generates traffic for a UDP application. The traffic source and traffic sink modules can be built from queueing model elements.
UdpBasicApp	simple module	Sends UDP packets to the given IP address at the given interval. Compatible with both Ipv4 and Ipv6.
UdpBasicBurst	simple module	Sends UDP packets to the given IP address(es) in bursts, or acts as a packet sink. Compatible with both IPv4 (Ipv4) and IPv6 (Ipv6).
UdpEchoApp	simple module	Listens on a UDP port and sends back each received packet to its sender. Note: when used together with UdpBasicApp, UdpBasicApp’s “received packet lifetime” statistic will record round-trip times.
UdpRequestResponseApp	compound module	A generic request/response-based server application. For each request it receives, it generates different traffic based on the data the request contains. The client application can be any source that is capable of generating packets with different data. The first byte of the packet data determines the response traffic, which can be configured to produce complex streams of packets with various data and timing distributions.
UdpSink	simple module	Consumes and prints packets received from the Udp module.
UdpSinkApp	compound module	Implements a UDP application that only receives packets.
UdpSourceApp	compound module	Implements a UDP application that only sends packets.
UdpVideoStreamClient	simple module	Video streaming client.
UdpVideoStreamServer	simple module	Video stream server. To be used with UdpVideoStreamClient.
SimpleVoipReceiver	simple module	Receives a VoIP stream generated by a SimpleVoipSender, and records statistics. The most important statistic is MOS (Mean Opinion Score, a value between 1 and 5, representing a human user’s view of the voice quality), computed using the E Model defined in the ITU-T G.107 standard. The parameters starting with “emodel_” correspond to the parameters of the E model.
SimpleVoipSender	simple module	Implements a simple VoIP source. It is a constant bitrate source, with talk spurt support added. Packets do not contain actual voice data. Connection setup/teardown is not modeled. The peer must be a SimpleVoipReceiver.
VoipStreamReceiver	simple module	VoipStreamReceiver listens on a UDP port and expects to receive VoIP packets on it. The received voice is then saved into a result audio file that can be compared with the original for further evaluation. VoIP packets are numbered, and out-of-order packets are discarded (the corresponding voice interval will be recorded as silence into the file). VoIP packets that miss their deadlines will similarly be discarded. It is assumed that the audio is played back with a delay (by default 20ms), which allows some jitter for the incoming packets. The resulting audio file is closed when the simulation completes (i.e., in the OMNeT++ finish() function). Only one voice session (“call”) may be underway at a time.
VoipStreamSender	simple module	VoipStreamSender accepts an audio file and a destination IP address/port as input, and will transmit the file’s contents as voice traffic over UDP n times (by default once). For transmission, the audio is resampled at the specified frequency and depth, and encoded with the specified codec at the specified bit rate, and chopped into packets that each carry a specified number of milliseconds of voice. Those values come from module parameters. Packets that are all silence (all samples are below a given threshold in absolute value) are transmitted as special “silence” packets. The module does not simulate any particular VoIP protocol (e.g. RTP), but instead accepts a “header size” parameter that can be set accordingly.
Gptp	compound module	Implements the generalized Precision Time Protocol (gPTP) as defined in the IEEE 802.1AS-2020 standard.
MultiDomainGptp	compound module	Combines multiple Gptp modules, one per time domain into a multi time domain time synchronization module. Each gPTP time domain is automatically configured to use the corresponding subclock of the clock passed into this module.
Ldp	simple module	Handles and processes LDP messages.
Aodv	simple module	Ad hoc On-Demand Distance Vector Routing Protocol module.
Bgp	simple module	Implements the BGP Version 4 routing protocol (RFC 4271).
Rip	simple module	Routing Information Protocol.

Used in compound modules¶

Name	Type	Description
TcpServerApp	compound module	A generic, modular TCP server application. It is composed of a listener module that listens on a port to accept TCP connections, and for each incoming TCP connection it dynamically creates a new module in the connection[] submodule vector to handle the connection.
ApplicationLayerNodeBase	compound module	An extension of the transport layer node base that adds support for applications. Provides the highest level of abstraction for network nodes, completing the full network stack from physical to application layer.
EthernetSwitch	compound module	EthernetSwitch models a Layer 2 Ethernet switch with support for various IEEE 802.1 protocols and features. It provides frame forwarding based on MAC addresses and implements multiple switching technologies.
ManetRouter	compound module	A mobile node with ad hoc routing capabilities intended for Mobile Ad hoc Networks (MANETs). Extends AdhocHost by adding support for MANET routing protocols.

Known subclasses¶

Name	Type	Description
IGptp	module interface	Interface for gPTP module.
IBgp	module interface	Interface for BGP routing module.

Properties¶

Name	Value	Description
display	i=block/app

Source code¶

//
// Generic application interface.
//
moduleinterface IApp
{
    parameters:
        @display("i=block/app");
    gates:
        input socketIn;
        output socketOut;
}

File: src/inet/applications/contract/IApp.ned