Volume tests - Volume Testing of Messaging systems

Volume tests are often most appropriate to messaging, batch and conversion processing type situations. In a volume test, there is often no such measure as response time. Instead, there is usually a concept of throughput. A key to effective volume testing is the identification of the relevant capacity drivers. A capacity driver is something that directly impacts on the total processing capacity. For a messaging system, a capacity driver may well be the size of messages being processed.

Most messaging systems do not interrogate the body of the messages they are processing, so varying the content of the test messages may not impact the total message throughput capacity, but significantly changing the size of the messages may have a significant effect. However, the message header may include indicators that have a very significant impact on processing efficiency. For example, a flag saying that the message need not be delivered under certain circumstances is much easier to deal with than a message with a flag saying that it must be held for delivery for as long as necessary to deliver the message, and the message must not be lost. In the former example, the message may be held in memory, but in the later example, the message must be physically written to disk multiple times.

Before conducting a meaningful test on a messaging system, the following must be known:

- the capacity drivers for the messages.
- the peak rate of messages that need to be processed, grouped by capacity driver.
- the duration of peak message activity that needs to be replicated.
- the required message processing rates.


A test can then be designed to measure the throughput of a messaging system as well as the internal messaging system metrics while that throughput rate is being processed. Such measures would typically include CPU utilization and disk activity. It is important that a test be run, at peak load, for a period of time equal to or greater than the expected production duration of peak load.

CLNP (Connectionless Network Protocol)

CLNP is a datagram network protocol. It provides fundamentally the same underlying service to a transport layer as IP. CLNP provides essentially the same maximum datagram size, and for those circumstances where datagrams may need to traverse a network whose maximum packet size is smaller than the size of the datagram, CLNP provides mechanisms for fragmentation (data unit identification, fragment/total length and offset). Like IP, a checksum computed on the CLNP header provides a verification that the information used in processing the CLNP datagram has been transmitted correctly, and a lifetime control mechanism ("Time to Live") imposes a limit on the amount of time a datagram is allowed to remain in the internet system.

CLNP (Connectionless Network Protocol) may be used between network-entities in end systems or in Network Layer relay systems (or both). CLNP is intended for use in the Subnetwork Independent Convergence Protocol (SNICP) role, which operates to construct the OSI Network Service over a defined set of underlying services, performing functions necessary to support the uniform appearance of the OSI Connectionless-mode Network Service over a homogeneous or heterogeneous set of interconnected subnetworks.

CLNP Protocol Structure

- NLP ID - Network Layer Protocol Identifier : The value of this field is set to binary 1000 0001 to identify this Network Layer protocol as ISO 8473. The value of this field is set to binary 0000 0000 to identify the Inactive Network Layer protocol subset.
- Length ID : Length Indicator is the length in octets of the header.
- Version : Version/Protocol Id Extension identifies the standard Version of ISO 8473.
- Lifetime : PDU Lifetime representing the remaining lifetime of the PDU, in units of 500 milliseconds.
- Flags : There are three flags : segmentation permitted, more segments, error report.
- Type : The Type code field identifies the type of the protocol data unit, which could be data PDU or Error Report PDU.
- Segment Length : The Segment Length field specifies the entire length, in octets, of the Derived PDU, including both header and data (if present).
- Checksum : The checksum is computed on the entire PDU header.

Routing Information Protocol (RIP) Cont...

RIP Message Format

RIP updates are placed as UDP payload inside an IP datagram. The format is as follows:
- Command : It indicates whether the packet is a request or a response. The request asks that a router send all or part of its routing table. The response can be an unsolicited regular routing update or a reply to a request. Responses contain routing table entries. Multiple RIP packets are used to convey information from large routing tables.
- Version number : It specifies the RIP version used. This field can signal different potentially incompatible versions.
- Zero : This field is not actually used by RFC 1058 RIP; it was added solely to provide backward compatibility with prestandard varieties of RIP. Its name comes from its defaulted value: zero.
- Address family identifier (AFI) : It specifies the address family used. RIP is designed to carry routing information for several different protocols. Each entry has an address-family identifier to indicate the type of address being specified. The AFI for IP is 2.
- Address : It specifies the IP address for the entry.
- Metric : It indicates how many internetwork hops (routers) have been traversed in the trip to the destination. This value is between 1 and 15 for a valid route, or 16 for an unreachable route.

RIPv2 header explanation

- Command : Indicates whether the packet is a request or a response.
- Version : Version of RIP.
- Unused : It has a value set to zero.
- Address family identifier (AFI) : It specifies the address family used.
- Route tag : It provides a method for distinguishing between internal routes (learned by RIP) and external routes (learned from other protocols).
- IP address : It specifies the IP address for the entry.
- Subnet mask : It contains the subnet mask for the entry. If this field is zero, no subnet mask has been specified for the entry.
- Next hop : It indicates the IP address of the next hop to which packets for the entry should be forwarded.
- Metric : It indicates how many internetwork hops (routers) have been traversed in the trip to the destination. This value is between 1 and 15 for a valid route, or 16 for an unreachable route.

UDP - User Datagram Protocol

The User Datagram Protocol (UDP) is a transport layer protocol defined for use with the IP network layer protocol.UDP is often used in videoconferencing applications or computer games specially tuned for real-time performance.
- UDP network traffic is organized in the form of data grams.A data-gram comprises one message unit. The first eight bytes of a data-gram contain header information and the remaining bytes contain message data.
- UDP can be used in networks where TCP is traditionally implemented.
- It does not guarantee reliability or the correct sequencing of data.
- UDP makes use of a simple communication model without implicit transmission checks for guaranteeing reliability, sequencing, or data-gram integrity.
- UDP considers that error checks and corrections should be carried out in the communicating application, and not at the network layer.
- UDP makes the protocol that much faster and more efficient because it does not have the overhead of checking whether the data has reached the destination every time it is sent.
- UDP is a stateless protocol. UDP is used for packet broadcast or multi-casting whereby the data is sent to all the clients in the network.

The UDP header consists of four fields each of 2 bytes in length :

- Source Port : Source port recognizes the sending port and should be understood to be the port to respond to if required. If not used, then its value should be zero.

- Destination Port : UDP packets from a client use this as a service access point (SAP) to indicate the service required from the remote server.

- UDP length : The number of bytes comprising the combined UDP header information and payload data.

- UDP Checksum : A checksum to verify that the end to end data has not been corrupted by routers or bridges in the network or by the processing in an end system.