Abstract
In this chapter, we introduce tools for building models of network applications, i.e., processes providing the simulated network with traffic. The application model is represented by a centralized entity called the Client and organized into a collection of traffic patterns. Simple traffic patterns can be easily described by a few numerical parameters, and complex patterns can be programmed as sets of specialized processes. The centralized view of the network’s Client facillitates collecting performance measures.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
This interpretation assumes that messages and packets are used to model traffic in a communication network. It is possible to use messages and packets to model other things, e.g., boxes traveling through conveyor belts. In such scenarios, the headers and trailers (as well as some other message/packet attributes) may be irrelevant and need not be used.
- 2.
This also applies to many nonstandard interpretations of messages and packets, say, a message representing a truckload of boxes (packets) to be transported via a conveyor belt.
- 3.
For example, the packet length determines the amount of time needed to transmit the packet, i.e., insert it into a port or a transceiver at a given transmission rate (see Sect. 7.1.2).
- 4.
This minor difference between a packet buffer and the packet itself did not seem to warrant introducing a separate data type for representing packet buffers.
- 5.
It is often more natural, especially when issued from a method of a Station subtype, because packet buffers are most often declared “statically” (as class variables) at stations.
- 6.
Many traffic patterns are in fact defined this way.
- 7.
This is important, because no type conversion is automatically forced for a function/method with a variable-length argument list. Using, say, an int argument in place of a double one will have the disastrous effect of completely misreading one argument and possibly misaligning (and thus misinterpreting) the remaining ones.
- 8.
Formally, the reception process can respond to all packets and use arbitrary, programmable criteria to decide whether it should receive a given packet or not. The built-in mechanism of packet addressing merely facilitates a few standard and simple classes of such criteria, thus simplifying the implementation of some standard cases.
- 9.
- 10.
If the program has been compiled with the –D (deterministic) option of mks (Sect. B.5), the traffic pattern with the lowest Id wins in such a case.
- 11.
If the program has been compiled with the –D (deterministic) option of mks (Sect. B.5), the traffic pattern with the lowest Id wins in such a case.
- 12.
Note that this is not necessarily the same message that will be used by a subsequent call to getPacket, unless the program has been generated with the –D option of mks (Sect. B.5).
Author information
Authors and Affiliations
Corresponding author
Rights and permissions
Copyright information
© 2019 Springer Nature Switzerland AG
About this chapter
Cite this chapter
Gburzyński, P. (2019). The Client. In: Modeling Communication Networks and Protocols. Lecture Notes in Networks and Systems, vol 61. Springer, Cham. https://doi.org/10.1007/978-3-030-15391-5_6
Download citation
DOI: https://doi.org/10.1007/978-3-030-15391-5_6
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-030-15390-8
Online ISBN: 978-3-030-15391-5
eBook Packages: EngineeringEngineering (R0)