通讯编程

开发平台：
Visual C++

delays.tex：源码内容
							%
% personal commentary:
%        DRAFT DRAFT DRAFT
%        - KFALL
%
chapter{Delays and Links}
label{chap:delays}
Delays represent the time required for a packet to
traverse a link.
A special form of this object (``dynamic link'')
also captures the possibility of a link failure.
The amount of time required for a packet to traverse a link
is defined to be $s/b + d$ where $s$ is the packet size
(as recorded in its IP header), $b$ is the speed of the link
in bits/sec, and $d$ is the link delay in seconds.
The implementation of link delays is closely associated with
the blocking procedures described for Queues in
Sectionref{sec:qblock}.
section{The LinkDelay Class}
label{sec:delayclass}
The clsref{LinkDelay}{../ns-2/delay.cc} is derived from the
base clsref{Connector}{../ns-2/connector.h}.
Its definition is in nsf{delay.cc}, and is briefly excerpted below:
begin{program}
        class LinkDelay : public Connector {
         public:
                LinkDelay();
                void recv(Packet* p, Handler*);
                void send(Packet* p, Handler*);
                void handle(Event* e);
                double delay();    * line latency on this link */
                double bandwidth(); * bandwidth on this link */
                inline double txtime(Packet* p) { * time to send pkt p on this link */
                        hdr_cmn* hdr = (hdr_cmn*) p->access(off_cmn_);
                        return (hdr->size() * 8. / bandwidth_);
                }
         protected:
                double bandwidth_; * bandwidth of underlying link (bits/sec) */
                double delay_;     * line latency */
                int dynamic_;     * indicates whether or not link is ~ */
                Event inTransit_;
                PacketQueue* itq_; * internal packet queue for dynamic links */
                Packet* nextPacket_; * to be delivered for a dynamic link. */
                Event intr_;
        };
end{program}
The 
fcnref{fcn[]{recv} method}{../ns-2/delay.cc}{DelayLink::recv}
overrides the base
fcnref{class Connector}{../ns-2/connector.cc}{Connector::recv} version.
It is defined as follows:
begin{program}
        void LinkDelay::recv(Packet* p, Handler* h)
        {    
                double txt = txtime(p);
                Scheduler& s = Scheduler::instance();
                if (dynamic_) {
                        Event* e = (Event*)p;
                        e->time_ = s.clock() + txt + delay_; 
                        itq_->enque(p);
                        schedule_next();
                } else {
                        s.schedule(target_, p, txt + delay_);
                }       
                /*{cf XXX only need one intr_ since upstream object should}
                 * {cf block until it's handler is called}
                 *       
                 * {cf This only holds if the link is not dynamic.  If it is, then}
                 * {cf the link itself will hold the packet, and call the upstream}
                 * {cf object at the appropriate time.  This second interrupt is}
                 * {cf called code{inTransit_}, and is invoked through fcn[]{schedule_next}}
                 */
                s.schedule(h, &intr_, txt);
        }   
end{program}
This object supports one 
fcnref{instproc-like}{../ns-2/delay.cc}{LinkDelay::command},
code{$object dynamic},
to set its variable, code{dynamic_}. 
This variable determines whether the link is dynamic or not (ie, prone
to fail/recover at appropriate times).
The internal behavior of the link in each case is different.
For ``non-dynamic'' links,
this method operates by receiving a packet, $p$,  and scheduling two
events.
Assume these two events are called $E_1$ and $E_2$, and that
event $E_1$ is scheduled to occur before $E_2$.
$E_1$ is scheduled to occur when the upstream node attached to this
delay element has completed sending the current packet
(which takes time equal to the packet size divided by the link bandwidth).
$E_1$ is usually associated with a code{Queue} object, and will
cause it to (possibly) become unblocked (see section ref{sec:qblock}).
$E_2$ represents the packet arrival event at the downstream neighbor
of the delay element.
Event $E_2$ occurs a number of seconds later than $E_1$ equal to the
link delay.
Alternately, when the link is dynamic, and receives  $p$, then
it will schedule $E_1$ to possibly unblock the queue at the
appropriate time.
However, $E_2$ is scheduled only
if $p$ is the only packet currently in transit.
Otherwise, there is at least one packet in transit on the link that must
be delivered before $p$ at $E_2$.
Therefore, packet $p$ is held in the object's inTransit queue, code{itq_}.
When the packet just before $p$ in transit on the link is delivered
at the neighbor node, 
the DelayLink object will schedule an event for itself to fire at $E_2$.
At that appropriate time then, 
fcnref{it's fcn[]{handle} method}{../ns-2/delay.cc}{LinkDelay::handle}
will directly send $p$ to its target.
The object's internal
fcnref{fcn[]{schedule_next} method}{../ns-2/delay.h}{%
        LinkDelay::schedule_next} 
will schedule these events for packet sin transit at the appropriate time.
section{Commands at a glance}
The LinkDelay object represents the time required by a packet to
transverse the link and is used internally within a Link. Hence we donot
list any linkdelay related commands suitable for simulation scripts here.

						