Re: [ns] How to access mac layer in c++ of ns2
Hi,
I have never done anything with TCP layer, so I'm not sure.
But a general rule I summarized is that
1) If the two layers you want to cross-access are adjacent, you can use
uptarget_/downtarget_
2) If they are not, it is a bit of difficult to make the pointer clear. My
method is to use tcl to get the pointer. You must have seen the usage of
TclObject::lookup() many times.
My case is to let my SensorAgent to access Mac802_11, thus
in my sensor-agent.cc (can be others such as aodv.cc)
implement a command
if (strcmp(argv[1], access-mac) == 0) {
mac_pt_ = (Mac802_11*)TclObject::lookup(argv[2]);
if (mac_pt_ == 0)
return TCL_ERROR;
return TCL_OK;
}
here mac_pt_ is defined in sensor-agent.h
Mac802_11 *mac_pt_
you may also need to declare Mac802_11 as friend class.
Once you execute the following command in your tcl file, mac_pt_ gets the
right pointer and you can use it now.
$sensoragent_($i) access-mac [$node_($i) set mac_(0)]
vice versa
set mac_ [$node_($i) set mac_(0)]
$mac_ access-agent [$node_($i) agent 255]
you implement access-agent command in mac layer
so the point is that you need to know how to get TCP
set tcp_ ???
Best,
Pei
Basim Javed [EMAIL PROTECTED] wrote：
I just read, and you are correct.
Could u plz also tell me how to access the TCP layer from the node pointers in
C++, and how does we know that this is the current node (some thing like self)?
So I want each node to access the TCP and PHY layers from within itself, and
also the reverse of it: i.e. within TCP I want to access the MAC functions of
the concerned node, if possible?
thanks many.
basim
Pei Huang, Ph.D. student
Dept. of Computer Science and Engineering
Michigan State University
http://dekst.awardspace.com
__
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com
Re: [ns] How to access mac layer in c++ of ns2
Hi Basim, The connection from a node to a TCP agent is fairly subtle. Basically, a Node has an instvar dmux_ which is a classifier. It install a TcpAgent and TcpSink in the slot of the classifier dmux_. This occurs when you invoke commands like $ns attach-agent $n0 $udp0 You may find the details in the book (chs 4 and 6) from Springer: T. Issaraiyakul and E. Hossain, Introduction to Network Simulator NS2, Springer 2008. Here is the link: http://www.springer.com/engineering/signals/book/978-0-387-71759-3 You might also find the following slide useful: http://www.ece.ubc.ca/~teerawat/NS2.htmhttp://www.ece.ubc.ca/%7Eteerawat/NS2.htm Best Regards, Teerawat
[ns] TCP max congestion window and ssthreh's values
Dear ns colleagues, How to set max congestion window in tcp? I ns-default.tcl sets it to 0 (Zero). How it could be if following concept is correct? maxcwnd (Maximum Congestion Window) indicates the maximum number that the CWND can achieve. ie. After tcp enters in the Congestion Avoidance phase, the rate of increase in CWND becomes slow (linear rather than exp). When it reaches MAXCWND, it stops increases. However if some packet loss occurs, during this process, it enters into recovery process, by Reseting the CWND to 1, MAXCWND to half the current CWND. Am I conceptually (theoretically) correct? If yes, then the default value of maxcwnd must be some greater positive number and not zero! (Similar comment is due for ssthresh (Slow Start Threshold ) too, as it is also ZERO by default in ns!) As ns2 is working properly, I am sure I am mistaking / misunderstanding somewhre. I just want to know where. Your expert comments are welcomed.. Mayur
Re: [ns] Doubt Clarified.... TCP max congestion window and ssthreh's values
Mayur wrote: Dear ns colleagues, How to set max congestion window in tcp? I ns-default.tcl sets it to 0 (Zero). How it could be if following concept is correct? maxcwnd (Maximum Congestion Window) indicates the maximum number that the CWND can achieve. ie. After tcp enters in the Congestion Avoidance phase, the rate of increase in CWND becomes slow (linear rather than exp). When it reaches MAXCWND, it stops increases. However if some packet loss occurs, during this process, it enters into recovery process, by Reseting the CWND to 1, MAXCWND to half the current CWND. Am I conceptually (theoretically) correct? If yes, then the default value of maxcwnd must be some greater positive number and not zero! (Similar comment is due for ssthresh (Slow Start Threshold ) too, as it is also ZERO by default in ns!) As ns2 is working properly, I am sure I am mistaking / misunderstanding somewhre. I just want to know where. Your expert comments are welcomed.. Mayur Dear all, I found the clarification to the doubt... The code in tcp.cc is ## // if maxcwnd_ is set (nonzero), make it the cwnd limit if (maxcwnd_ (int(cwnd_) maxcwnd_)) cwnd_ = maxcwnd_; ## So, the comment itself speaks well... By default the algorithm (in ns) does not check for maxcwnd_, ie. cwnd can grow to (theoretically) infinity. If we set it by 'Agent/TCP set maxcwnd_ some_value' then it is set accordingly. I hope I perceived it right. Mayur
[ns] A possible BUG in ns2, in capture() function in mac/mac-802_11.cc
Dear NS experts,
There seems to be a BUG in ns2 (till latest version ns2.33) :
_*Abstract: *_
capture() function should treat errored_pkts and normal_pkts
differently. Viz., the NAV should be set to only EIFS for errored
packets and for normal packets to { EIFS + txtime(pkt) }.
_*More elaboration :*_
* When a sender is far such that the received power (Pr) is [
RXThresh_ Pr = CSThresh_ ], the packet is sensed but bot
understood. As per the 802.11 std, for such sensed_only packet the
receiver node should wait for EIFS. In NS2 presently (till ns2.33)
this is done so far as this is the only packet being received.
(PHY makes the packet ERRORED and MAC sets NAV to EIFS. (see
recv_timer() function.)
* But when more than one packets are being received, (COLLISION or
CAPTURE case) then, there (seems to be) is a bug in the code. viz.
The capture() function always sets NAV to (EIFS + txtime(pkt)),
without checking if the packet is marked with 'errored' or not.
I have tried to rectify the bug (If I am correct). The corrected
mac-802_11.cc is attached herewith. [Note: The original and modified
versions can be toggled by just commenting/uncommenting the
corresponding #define .]
As observed I have modified the capture() function to take a second
argument for if the pkt is errored and the function acts accordingly.
Obviously, the mac-802_11.h needs one line correction for the new
declaration of capture().
The results in the two cases (original_capture and modified_capture) are
drastically different depending upon the scenario being tested.
Your suggestions are welcomed.
regards,
Mayur
[ns] Sorry Wrong File Sent A possible BUG in ns2, in capture() function in mac/mac-802_11.cc
Dear all,
[Sorry, I attached wrong file, Pl find the modified_mac-802_11.cc
attached herewith. Kindly discard the earlier sent mac-802_11.cc file.]
Mayur wrote:
Dear NS experts,
There seems to be a BUG in ns2 (till latest version ns2.33) :
_*Abstract: *_
capture() function should treat errored_pkts and normal_pkts
differently. Viz., the NAV should be set to only EIFS for errored
packets and for normal packets to { EIFS + txtime(pkt) }.
_*More elaboration :*_
* When a sender is far such that the received power (Pr) is [
RXThresh_ Pr = CSThresh_ ], the packet is sensed but bot
understood. As per the 802.11 std, for such sensed_only packet the
receiver node should wait for EIFS. In NS2 presently (till ns2.33)
this is done so far as this is the only packet being received.
(PHY makes the packet ERRORED and MAC sets NAV to EIFS. (see
recv_timer() function.)
* But when more than one packets are being received, (COLLISION or
CAPTURE case) then, there (seems to be) is a bug in the code. viz.
The capture() function always sets NAV to (EIFS + txtime(pkt)),
without checking if the packet is marked with 'errored' or not.
I have tried to rectify the bug (If I am correct). The corrected
mac-802_11.cc is attached herewith. [Note: The original and modified
versions can be toggled by just commenting/uncommenting the
corresponding #define .]
As observed I have modified the capture() function to take a second
argument for if the pkt is errored and the function acts accordingly.
Obviously, the mac-802_11.h needs one line correction for the new
declaration of capture().
The results in the two cases (original_capture and modified_capture)
are drastically different depending upon the scenario being tested.
Your suggestions are welcomed.
regards,
Mayur
Re: [ns] Please help me to solve my issue in ns2
Hi,
I don't think you want to classify packets in mac layer. Instead, you want
your packets to be submitted to aodv. Thus, in aodv.cc, you need to identify
your packets in AODV::recv(Packet *p). In fact, as you know, all packets first
arrive at such a recv function in any layer. So if you want to do anything
about your packets, it should be in this function.
Then how to identify your packets
you need to register your packet header in common/packet.h
then you can set hdr_cmn and use it to identify your packets and do something.
hdr_cmn *ch = HDR_CMN(p)
when you send a packet, set the packet type as yours,
when you recv it in aodv
if(ch-ptype() == PT_YOUR_TYPE) {
recvMYPACKT(p); //change to execute your code instead of recvAODV(p)
return;
}
Detailed how to register your header can be referred to
Implementing a New Manet Unicast Routing Protocol in NS2
see the needed changes part.
BTW, how to suppress duplicate packets I have sent. I do not want to read
aodv code if you already know.
Best,
Pei
Mubashir Rehmani [EMAIL PROTECTED] wrote：
Hello Daniel
I hope that you are fine. I need your help to resolve my problem in ns2.
Basically i am using AODV.cc and as you know that AODV has many types of
packets like HELLO, RREQ etc. I have declared my own packet header in AODV.cc
and i used it for unicasting. Now the problem is that when i send my own packet
from source to destination in AODV.cc then first this packet is received in MAC
802.11.cc file in the recv_timer() function and then in this recv_timer()
function all the packets are classified. For instance if the packet is Control
like RTS/CTS/ACK then recv_timer() call functions like recvRTS() etc etc. and
if the packet is data packet, as Hello or my own packet then it just check
whether it is data packet or not and just call the recvDATA() packet in
mac-802.11.cc and then this function send packet to upword layer to recv()
function that is present in AODV.cc file. Then further action is taken place
and packets are being dropped there.
Now my problem is that when i send my own packet from particular source to
destination then at the mac layer all the nodes that are in the communication
range will listen this packet and discard them at the mac layer (control
packets) but if the packet is data packet, in the mac layer it will not
classify the data packet, instead it will just check whether it is a data
packet or not and then forward it to upper layer.
What i want to do is that at the mac layer, in the recv_timer() function, the
mac layer should classify the data packet and if it found that at the mac layer
that this is a data packet and of type HELLO or RREQ then discard them or if it
is my own data packet type then forward it to upper layer.
I hope you understand my question.
Thanks in advance.
Regards
--
Mubashir Husain Rehmani
Mobile : 00 33 (0)6 32 00 89 35
__
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com
