.. _ug:cha:apps: Applications ============ .. _ug:sec:apps:overview: Overview -------- This chapter describes application models and traffic generators. All applications implement the :ned:`IApp` module interface to ease configuration. For example, :ned:`StandardHost` contains an application submodule vector that can be filled in with specific applications from the INI file. INET applications fall into two categories. In the first category, applications implement very specific behaviors, and generate corresponding traffic patterns based on their specific parameters. These applications are implemented as simple modules. In the second category, applications are more generic. They separate traffic generation from the usage of the protocol, :ned:`Udp` or :ned:`Tcp` for example. These applications are implemented as compound modules. They contain separate configurable traffic source, traffic sink, and protocol input/output submodules. This approach allows building complex traffic patterns by composing queueing model elements. .. _ug:sec:apps:tcp-applications: TCP applications ---------------- This sections describes the applications using the TCP protocol. These applications use :msg:`GenericAppMsg` objects to represent the data sent between the client and server. The client message contains the expected reply length, the processing delay, and a flag indicating that the connection should be closed after sending the reply. This way intelligence (behaviour specific to the modelled application, e.g. HTTP, SMB, database protocol) needs only to be present in the client, and the server model can be kept simple and dumb. .. _ug:sec:apps:tcpbasicclientapp: TcpBasicClientApp ~~~~~~~~~~~~~~~~~ Client for a generic request-response style protocol over TCP. May be used as a rough model of HTTP or FTP users. The model communicates with the server in sessions. During a session, the client opens a single TCP connection to the server, sends several requests (always waiting for the complete reply to arrive before sending a new request), and closes the connection. The server app should be :ned:`TcpGenericServerApp`; the model sends :msg:`GenericAppMsg` messages. Example settings: FTP: .. code-block:: ini numRequestsPerSession = exponential(3) requestLength = truncnormal(20,5) replyLength = exponential(1000000) HTTP: .. code-block:: ini numRequestsPerSession = 1 # HTTP 1.0 numRequestsPerSession = exponential(5) # HTTP 1.1, with keepalive requestLength = truncnormal(350,20) replyLength = exponential(2000) Note that since most web pages contain images and may contain frames, applets etc, possibly from various servers, and browsers usually download these items in parallel to the main HTML document, this module cannot serve as a realistic web client. Also, with HTTP 1.0 it is the server that closes the connection after sending the response, while in this model it is the client. .. _ug:sec:apps:tcpsinkapp: TcpSinkApp ~~~~~~~~~~ Accepts any number of incoming TCP connections, and discards whatever arrives on them. .. _ug:sec:apps:tcpgenericserverapp: TcpGenericServerApp ~~~~~~~~~~~~~~~~~~~ Generic server application for modelling TCP-based request-reply style protocols or applications. The module accepts any number of incoming TCP connections, and expects to receive messages of class :msg:`GenericAppMsg` on them. A message should contain how large the reply should be (number of bytes). :ned:`TcpGenericServerApp` will just change the length of the received message accordingly, and send back the same message object. The reply can be delayed by a constant time (:par:`replyDelay` parameter). .. _ug:sec:apps:tcpechoapp: TcpEchoApp ~~~~~~~~~~ The :ned:`TcpEchoApp` application accepts any number of incoming TCP connections, and sends back the data that arrives on them, The byte counts are multiplied by :par:`echoFactor` before echoing. The reply can also be delayed by a constant time (:par:`echoDelay` parameter). .. _ug:sec:apps:tcpsessionapp: TcpSessionApp ~~~~~~~~~~~~~ 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 and IPv6. Opening the connection ^^^^^^^^^^^^^^^^^^^^^^ Depending on the type of opening the connection (active/passive), the application may be either a client or a server. In passive mode, the application will listen on the given local local port, and wait for an incoming connection. In active mode, the application will bind to given local local address and local port, and connect to the given address and port. It is possible to use an ephemeral port as local port. Even when in server mode (passive open), the application will only serve one incoming connection. Further connect attempts will be refused by TCP (it will send RST) for lack of LISTENing connections. The time of opening the connection is in the :par:`tOpen` parameter. Sending data ^^^^^^^^^^^^ Regardless of the type of OPEN, the application can be made to send data. One way of specifying sending is via the :par:`tSend`, :par:`sendBytes` parameters, the other way is :par:`sendScript`. With the former, :par:`sendBytes` bytes will be sent at :par:`tSend`. When using :par:`sendScript`, the format of the script is: ::