package flow procedure
Figure 1. Packet Flow Example
The problem interested to me, in the figure above is, why the package in red must be handled, both in the source and the sink, using a Addr Classifier. This is a little illogical to let the package flowing out of the node(the circle in Fig.1) and getting back again. It might be possible to do it in a much easier way: the source send the package, only using a Port Classifier(or no classifier, since there is only one port in the Port Classifier), and the sink receive the package. That's all. Why they design like this?
The answer is, pay attention on the package size. At the beginning, a "short" red package is generated as the node entry point. It is forwarded to the Port Classifier by the Addr Classifier, which means the "Addr" of the "short" red package is 0. And the "short" package arrives at the TCP entry. Let me remind you, TCP, in NS, a discrete event-driven simulator, is designed as Agent, rather than a actual Protocol in the network layer. And FTP, is considered as one of the applications above TCP, which is only responsible for the data source. Knowing this, it will not be difficult for us to understand why there are two "burdensome" routes outside the nodes. The entire procedure should be descried like this: At the beginning, The event of sending a TCP package from node n1 to node n2 is generated. Then, a "short" message requesting data is sent towards the FTP application inside node n0(the "short" red package we've seen). As soon as the FTP application receive the message, it generated a "long" red package and send it to the TCP agent. The "long" red package is actually the data we want to send through the link. The TCP agent then forward the data package to node n0 again. And, at this time, the data package is classified as "Addr = 1" by the Addr Classifier inside node n0. Then, the similar procedure happens at the sink side. The sink receive the data package, and forward it to the sink agent. After the package is successfully received by the sink agent, it generate a "ACK" message, resend it to the node n2. n2 classified the "ACK" message as "Addr = 0" and send it back to node n0 through the link. The agent(TCP, Sink) and the application(FTP) remain independent for node n0 and n1 during the entire simulation procedure.
It's of top importance for us to understand throughly the event-scheduling and network component abstraction in NS-2.
package structure
The concept of "package" in real-world computer and telecoms networks are quite different from the concept in NS. Package in NS, is only a abstraction and generalization of all network packages. Thus, the structure of the package in NS is entirely different from the real-world.
A NS packet is composed of a stack of headers, and an optional data space (see Figure 2). As briefly mentioned in the "Simple Simulation Example" section, a packet header format is initialized when a Simulator object is created, where a stack of all registered (or possibly usable) headers, such as the common header that is commonly used by any objects as needed, IP header, TCP header, RTP header (UDP uses RTP header) and trace header, is defined, and the offset of each header in the stack is recorded. What this means is that whether or not a specific header is used, a stack composed of all registered headers is created when a packet is allocated by an agent, and a network object can access any header in the stack of a packet it processes using the corresponding offset value.
Figure 2. NS Packet Format
(http://nile.wpi.edu/NS/)
Usually, a packet only has the header stack (and a data space pointer that is null). Although a packet can carry actual data (from an application) by allocating a data space, very few application and agent implementations support this. This is because it is meaningless to carry data around in a non-real-time simulation.
没有评论:
发表评论