Window Size Value on Wireshark

[Guillermo Gala]

Hi at all,

I'm trying to change the value of receive window on tcp-socket-base.cc
to view how to change the throughput of my simulation.
The change that i make is: (line 646 on ns3.12.1)
//m_rWnd = tcpHeader.GetWindowSize ();
m_rWnd = 5840; // bytes. 1MSS=1460. 4MSS=5840

and i can see that throughput is better, but when open pcap file on
Wireshark, always says that Window Size Value is 65535.

Anyone could tell me if i'm wrong and i'm changing other parameter?

thanks in advice

[Guillermo Gala]

Anyone could help me?

[John Abraham]

m_rWnd is a trace source reflecting the value read from the TCP
Header.
perhaps you are looking for Config::SetDefault
("ns3::TcpSocket::RcvBufSize", UintegerValue(5840)); ?

[Guillermo Gala]

Hi John,

I have RcvBufSize set to 2100000000 (bytes)

In the link http://www.nsnam.org/doxygen/classns3_1_1_tcp_socket.html
says that: RcvBufSize "Underlying type: uint32_t 0:4294967295"

I tried set this parameter to 4294967295 but i get an error, the same
with 3000000000 (3e9).

But, it's true you are saying and I'm grateful with you, because I
change RcvBufSize to 10000 bytes and I can see on Wireshark that
Window Size Value is now 10000, but is not the parameter that I'm
looking for.

I'm trying to change RWIN Receive window (http://www.dslreports.com/
faq/6266), but seems that is not RcvBufSize. This is only a buffer.

I think that it is m_rWnd, because setting that parameter to a low
value, my throughput is better like i expect.

Any idea?

Thank you

On 28 oct, 19:19, John Abraham <johnj...@gmail.com> wrote:
> m_rWnd is a trace source reflecting the value read from the TCP
> Header.
> perhaps you are looking for Config::SetDefault
> ("ns3::TcpSocket::RcvBufSize", UintegerValue(5840));  ?
>

> On Oct 28, 10:26 am,GuillermoGala<valentinosn...@gmail.com> wrote:
>
> > Anyone could help me?
>

[John Abraham]

well by hard-coding m_rWnd like you did earlier, you are forcing that
receiver's window to be something you want. But in fact for an
unhacked TCP , the receivers window is a function of the receiver's
available rx buffer.
By logic, setting rWnd to a lower value should decrease your
throughput rather than increase it (when congestion is not present).

So fixing rWnd to a fixed value ignores the current state of the rx
buffer,.. the consequences for doing that are undefined. But you might
have some legitimate reason for doing that, so you might want to
search for places where "SetWindowSize" is used in tcp-socket-base.cc
and change it appropriately.

-john

On Oct 29, 6:00 pm, Guillermo Gala <valentinosn...@gmail.com> wrote:
> Hi John,
>
> I have RcvBufSize set to 2100000000 (bytes)
>

> In the linkhttp://www.nsnam.org/doxygen/classns3_1_1_tcp_socket.html

[Guillermo Gala]

Hi John,

I want to replicate next paper:
http://www.tcs.hut.fi/Studies/T-79.300/2005S/slides/Paper_Presentation-65598M-J_Hautakorpi.pdf

Graphs on page 16 / 28. As you can see, setting less windows value, do
that throughput is more stable and I can eliminate the problem of
hidden node on TCP.

This is exactly that I want to do, but using NS-3. On NS-2 i know that
the variable is "window_"

Thanks for your reply

[John Abraham]

if you see those graphs, you will see the max throughput 400 vs 325
(not average throughput) is higher for larger rx windows. Average
throughput can grow for lower rWnd only if the BDP limits and/or
congestion come into play.

And further, the window_ mentioned here, is the maximum window size
(my guess). If yes, it is the same as setting RcvBufSize which
eventually translates to rWnd . If you hard-code rWnd to a constant
value, you may get unexpected behavior (my opinion).

On Oct 29, 6:35 pm, Guillermo Gala <valentinosn...@gmail.com> wrote:
> Hi John,
>

> I want to replicate next paper:http://www.tcs.hut.fi/Studies/T-79.300/2005S/slides/Paper_Presentatio...

[Guillermo Gala]

Hi again John,

If I set RcvBufSize and SndBufSize to 11680 bytes=8MSS (1MSS = 1460
Bytes) I obtain next plot:

http://www.subirimagenes.com/imagen-throughputaodv11680-7081103.html

On Wireshark "Window size value" is equal to 11680.

However if I put RcvBufSize and SndBufSize to 65535 bytes or more I
obtain this other plot:

http://www.subirimagenes.com/imagen-throughputaodv65535-7081114.html

and on Wireshark "Window size value" is equal to 65535 (always).

I think that Send and Receive buffer don't delete send and receive
correct packets, because with 11680, throughput down to 0 Kbps after
40 sec (more or less)

Regards

[John Abraham]

A lot of additional things may be involved such layer 2 contention,
layer 3 congestion, mobility, how you calculate throughput, is there a
problem with AODV etc.
You will have to figure out why the throughput reduces to zero after
40 sec,before comparing it with some other RcvBufSize or some other
SndBufSize.

-john

[Guillermo Gala]

Thanks for your time John.

I have another question about throughput.

Can I calculate the throughput of two flows every 1 second with NS-3,
but filtering by IP origin-IP destiny?

I want to send packets from node 1 to node 0, and when past 10 seconds
for example, send packets from node 2 to node 4 (node 1 have to
continue sending packets to node 0).

Now, I have:

________________________________________________________________________________________________________________________
static uint32_t m_bytesTotal=0; // Variable to keep total ok rx bytes
static double throughputSeconds = 0.5; // Throughput calculated each
this time(seconds)

static void Throughput () // in Mbps calculated every Xs
{
double mbps = (((m_bytesTotal * 8.0) / 1000000)/
throughputSeconds); // BytesRx*8(bits)/ 1e6 (Mbits) / X seg
Time time = Simulator::Now ();
NS_LOG_UNCOND (time.GetSeconds () << "\t" << mbps);
Simulator::Schedule (Seconds (throughputSeconds), &Throughput);
m_bytesTotal=0;
}

void PhyRxOkTrace (std::string context, Ptr<const Packet> packet,
double snr, WifiMode mode, enum WifiPreamble preamble)
{
Ptr<Packet> m_currentPacket;
WifiMacHeader hdr;
m_currentPacket = packet->Copy();
m_currentPacket->RemoveHeader (hdr); // Remove header
if (hdr.IsData())
{
m_bytesTotal += m_currentPacket->GetSize (); // Get size of ok rx
bytes and add to previous
}
}

int main (int argc, char *argv[])
{
................

// Call to PhyRxOkTrace when node 4 receives a packet
Config::Connect ("/NodeList/4/DeviceList/*/Phy/State/
RxOk",MakeCallback (&PhyRxOkTrace));
Throughput (); // Call to function that calculates the
throughput every X seconds
_______________________________________________________________________________________________________________________


But, with that code, the throughput calculated on node 4 is all
packets that arrived at that node, not only packets from node 2. I
don't know if i'm explaining well.

I wish something like:
Config::Connect ("/NodeList/4/DeviceList/*/Phy/State/RxOk/*/
192.168.1.2 > 192.168.1.5",MakeCallback (&PhyRxOkTrace));

but obviously doesn't work.

Am I force to do a python script to filter .tr file? or Can I use NS3?


Regards

[John Abraham]

It is important to realize that even if RxOk is seen at the Phy layer,
it does not mean Receive is OK for Mac, IP, and TCP layers. Goodput
(useful throughput), is something usually best measured at the
application layer (after all what your application ,say webbrowser,
experiences, is what matters most , in many cases). In your code,
heavy retransmissions (useless/control overhead) can also cause higher
throughput numbers.

For instance, you can check "manet-routing-compare.cc" on how they
calculate throughput.

[Guillermo Gala]

Hi John,

I'm watching manet-routing-compare.cc, but in the example, throughput
is not filtered by IP, only shows the IP which sends packets.

I think the only way to "do a filter" is make a python script that
analize trace output file

Thanks

[John Abraham]

There is Socket::GetSockName for destination address,
there is SocketAddressTag carrying the source address, that is already
shown in the example.
-john

[Guillermo Gala]

Hi John,

I used next code to send packets:

_______________________________________________________________________________________________________
// CONFIGURATION OF SOURCES AND SINKS NODES
// Set sink node which receives packets (2->4)
uint16_t sinkPort = 8080; // HTTP port
// Create TCP sockets and Bind to address and port
// GetAny returns the 0.0.0.0 address -> Node can receive packets
from all the IPs, but only for the specified port
PacketSinkHelper packetSinkHelper ("ns3::TcpSocketFactory",
InetSocketAddress (Ipv4Address::GetAny (), sinkPort));
ApplicationContainer sinkApps = packetSinkHelper.Install (nodos.Get
(sinkNode)); // Set up one application on the sink node
sinkApps.Start (Seconds (startSocket-1.0)); // Start Time
sinkApps.Stop (Seconds (stopSocket)); // End Time
// Other application to probe hidden node (1->0) (2->4)
ApplicationContainer sinkApps2 = packetSinkHelper.Install (nodos.Get
(0)); // Set up one application on the sink node
sinkApps2.Start (Seconds (10.)); // Start Time
sinkApps2.Stop (Seconds (stopSocket)); // End Time

// Create socket for sender
Ptr<Socket> ns3TcpSocket = Socket::CreateSocket (nodos.Get
(sourceNode), TcpSocketFactory::GetTypeId ());
ns3TcpSocket->TraceConnectWithoutContext ("CongestionWindow",
MakeCallback (&CwndChange)); // Call to CwndChange function

// Set source node which sends packets (node 2 to node 4)
Ptr<MyApp> app = CreateObject<MyApp> ();
Address sinkAddress (InetSocketAddress(interfaces.GetAddress
(sinkNode), sinkPort)); // Address (with port) of node which receive
packets
app->Setup (ns3TcpSocket, sinkAddress, AppPacketSize, numPackets,
DataRate ("2Mbps"));
nodos.Get (sourceNode)->AddApplication (app);
app->SetStartTime (Seconds (startSocket)); // Start Time
app->SetStopTime (Seconds (stopSocket)); // End Time
// It can't start at 0 seconds because of OLSR protocol, for example,
the nodes require flooding messages to be exchanged for a few seconds

// Definition of the node that sends packets (node 1 to node 0)
Ptr<Socket> ns3TcpSocket2 = Socket::CreateSocket (nodos.Get (1),
TcpSocketFactory::GetTypeId ());
ns3TcpSocket2->TraceConnectWithoutContext ("CongestionWindow",
MakeCallback (&CwndChange)); // Call to CwndChange function
Ptr<MyApp> app2 = CreateObject<MyApp> ();
Address sinkAddress2 (InetSocketAddress(interfaces.GetAddress (0),
sinkPort)); // Address (with port) of node which receive packets
app2->Setup (ns3TcpSocket2, sinkAddress2, AppPacketSize, numPackets,
DataRate ("2Mbps")); // Physical layer has to transmit at least at 2x
nodos.Get (1)->AddApplication (app2);
app2->SetStartTime (Seconds (30.0)); //1
app2->SetStopTime (Seconds (stopSocket)); //20
____________________________________________________________________________________________________________
// Call to PhyRxOkTrace when node 0 receives a packet

Config::Connect ("/NodeList/4/DeviceList/*/Phy/State/
RxOk",MakeCallback (&PhyRxOkTrace));
Throughput (); // Call to function that calculates the throughput
every X seconds
_____________________________________________________________________________________________________________

void PhyRxOkTrace (std::string context, Ptr<const Packet> packet,
double snr, WifiMode mode, enum WifiPreamble preamble)
{
Ptr<Packet> m_currentPacket;
WifiMacHeader hdr;
m_currentPacket = packet->Copy();
m_currentPacket->RemoveHeader (hdr); // Remove header
if (hdr.IsData())
{
m_bytesTotal += m_currentPacket->GetSize (); // Get size of ok rx
bytes and add to previous
}
}

________________________________________________________________________________________________________________


So, I can't use Socket::GetSockName and SocketAddressTag because
Socket isn't argument on PhyRxOkTrace.
I'm looking for the way to obtain the IP through the packet, but i
can't see anything. It is possible?

I found:
Ipv4Address destAddressPacket = ipv4Header.GetDestination();
Ipv4Address scrAddressPacket = ipv4Header.GetSource();

and next i want to do something like:
if (destAddressPacket == 192.168.1.5 && scrAddressPacket ==
192.168.1.2)

m_bytesTotal += m_currentPacket->GetSize (); // Get size of ok rx
bytes and add to previous

but I don't know how to associate it to a specificied packet.

Can I solve the problem differently?

Thanks

On 30 oct, 23:46, John Abraham <johnj...@gmail.com> wrote:
> There is Socket::GetSockName for destination address,
> there is SocketAddressTag carrying the source address, that is already
> shown in the example.
> -john
>

> On Oct 30, 6:26 pm,GuillermoGala<valentinosn...@gmail.com> wrote:
>
> > Hi John,
>
> > I'm watching manet-routing-compare.cc, but in the example, throughput
> > is not filtered by IP, only shows the IP which sends packets.
>
> > I think the only way to "do a filter" is make a python script that
> > analize trace output file
>
> > Thanks
>
> > On 30 oct, 14:58, John Abraham <johnj...@gmail.com> wrote:
>
> > > It is important to realize that even if RxOk is seen at the Phy layer,
> > > it does not mean Receive is OK for Mac, IP, and TCP layers. Goodput
> > > (useful throughput), is something usually best measured at the
> > > application layer (after all what your application ,say webbrowser,
> > > experiences, is what matters most , in many cases). In your code,
> > > heavy retransmissions (useless/control overhead) can also cause higher
> > > throughput numbers.
>
> > > For instance, you can check "manet-routing-compare.cc" on how they
> > > calculate throughput.
>

> > > > > On Oct 29, 9:19 pm,GuillermoGala<valentinosn...@gmail.com> wrote:
>
> > > > > > Hi again John,
>
> > > > > > If I set RcvBufSize and SndBufSize to 11680 bytes=8MSS (1MSS = 1460
> > > > > > Bytes) I obtain next plot:
>
> > > > > >http://www.subirimagenes.com/imagen-throughputaodv11680-7081103.html
>
> > > > > > On Wireshark "Window size value" is equal to 11680.
>
> > > > > > However if I put RcvBufSize and SndBufSize to 65535 bytes or more I
> > > > > > obtain this other plot:
>
> > > > > >http://www.subirimagenes.com/imagen-throughputaodv65535-7081114.html
>
> > > > > > and on Wireshark "Window size value" is equal to 65535 (always).
>
> > > > > > I think that Send and Receive buffer don't delete send and receive
> > > > > > correct packets, because with 11680, throughput down to 0 Kbps after
> > > > > > 40 sec (more or less)
>
> > > > > > Regards
>
> > > > > > On 29 oct, 19:52, John Abraham <johnj...@gmail.com> wrote:
>
> > > > > > > if you see those graphs, you will see the max throughput 400 vs 325
> > > > > > > (not average throughput) is higher for larger rx windows. Average
> > > > > > > throughput can grow for lower rWnd only if the BDP limits and/or
> > > > > > > congestion come into play.
>
> > > > > > > And further, the window_ mentioned here, is the maximum window size
> > > > > > > (my guess). If yes, it is the same as setting RcvBufSize which
> > > > > > > eventually translates to rWnd . If you hard-code rWnd to a constant
> > > > > > > value, you may get unexpected behavior (my opinion).
>

> > > > > > > On Oct 29, 6:35 pm,GuillermoGala<valentinosn...@gmail.com> wrote:
>
> > > > > > > > Hi John,
>
> > > > > > > > I want to replicate next paper:http://www.tcs.hut.fi/Studies/T-79.300/2005S/slides/Paper_Presentatio...
>
> > > > > > > > Graphs on page 16 / 28. As you can see, setting less windows value, do
> > > > > > > > that throughput is more stable and I can eliminate the problem of
> > > > > > > > hidden node on TCP.
>
> > > > > > > > This is exactly that I want to do, but using NS-3. On NS-2 i know that
> > > > > > > > the variable is "window_"
>
> > > > > > > > Thanks for your reply
>
> > > > > > > > On 30 oct, 00:12, John Abraham <johnj...@gmail.com> wrote:
>
> > > > > > > > > well by hard-coding m_rWnd like you did earlier, you are forcing that
> > > > > > > > > receiver's window to be something you want. But in fact for an
> > > > > > > > > unhacked TCP , the receivers window is a function of the receiver's
> > > > > > > > > available rx buffer.
> > > > > > > > > By logic, setting rWnd to a lower value should decrease your
> > > > > > > > > throughput rather than increase it (when congestion is not present).
>
> > > > > > > > > So fixing rWnd to a fixed value ignores the current state of the rx
> > > > > > > > > buffer,.. the consequences for doing that are undefined. But you might
> > > > > > > > > have some legitimate reason for doing that, so you might want to
> > > > > > > > > search for places where "SetWindowSize" is used in tcp-socket-base.cc
> > > > > > > > > and change it appropriately.
>
> > > > > > > > > -john
>

> ...
>
> leer más »

[John Abraham]

i don't think you followed my previous email. Any throughput you are
calculating by looking at PhyRxOk (physical layer) will include useful
+useless + retransmission +control traffic. In any case, if you still
want to calculate throughput at the phy layer, then you will have to
strip the correct mac headers and peek into the ip header to extract
the source/destination IP. That is not a straightforward process, so I
will leave it to someone else to comment on that.

On Oct 31, 11:38 am, Guillermo Gala <valentinosn...@gmail.com> wrote:
> Hi John,
>

> ...
>
> read more »

[Guillermo Gala]

Sorry John,

I was looking for this way, because I found some examples of other
programs, but maybe as you say is not the best form to get IP
destination and origin.

Now, the question is: How can I look into application layer?

I only found this traces:
Config::Connect("NodeList/*/DeviceList/*/Phy/
PhyRxBegin",MakeCallback(&PhyRxBegin));
Config::Connect("NodeList/*/DeviceList/*/Phy/
PhyRxDrop",MakeCallback(&PhyRxDrop));
Config::Connect("NodeList/*/DeviceList/*/Phy/
PhyRxEnd",MakeCallback(&PhyRxEnd));
Config::Connect("NodeList/*/DeviceList/*/Mac/
MacDropRx",MakeCallback(&MacDropRxTrace));
Config::Connect("NodeList/*/DeviceList/*/Mac/
MacPromiscRx",MakeCallback(&MacPromiscRxTrace));
Config::Connect("NodeList/*/DeviceList/*/Mac/
MacRx",MakeCallback(&MacRxTrace));
Config::Connect("/NodeList/*/DeviceList/*/Phy/State/
RxOk",MakeCallback(&PhyRxOkTrace));
Config::Connect("/NodeList/*/DeviceList/*/Phy/State/
RxError",MakeCallback(&PhyRxErrorTrace));
Config::Connect("/NodeList/*/DeviceList/*/Phy/State/
Tx",MakeCallback(&PhyTxTrace));

only physical and mac layer :(

Thanks

> ...
>
> leer más »

[Guillermo Gala]

Note that to get trace, I use:

YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();
....
AsciiTraceHelper ascii;
wifiPhy.EnableAsciiAll (ascii.CreateFileStream ("pfc.tr")); //
Create file with trace
wifiPhy.EnablePcap ("pfc", devices); // Create pcap files to open it
with Wireshack

Regards

> ...
>
> leer más »

[John Abraham]

If you are using packetsink you have Rx trace source
http://www.nsnam.org/docs/release/3.12/doxygen/classns3_1_1_packet_sink.html

If you use the style in manet-routing-compare.cc
we have
sink->SetRecvCallback (MakeCallback
(&RoutingExperiment::ReceivePacket, this));

both styles notify you , when the application layer receive a packet.

> ...
>
> read more »

[Guillermo Gala]

Hi John,

now, I have: Config::ConnectWithoutContext ("/NodeList/4/
ApplicationList/0/$ns3::PacketSink/Rx", MakeCallback (&SinkRx));

void
SinkRx (Ptr<const Packet> packet, const Address& ad)
{
Ptr<Packet> m_currentPacket;
m_currentPacket = packet->Copy();

m_bytesTotal += m_currentPacket->GetSize (); // Get size of ok rx
bytes and add to previous

TcpHeader tcpHeader;
m_currentPacket->PeekHeader(tcpHeader);

int scrPortPacket;
int destPortPacket;
scrPortPacket = tcpHeader.GetSourcePort();
destPortPacket = tcpHeader.GetDestinationPort();
NS_LOG_UNCOND("Port dest" << destPortPacket);
NS_LOG_UNCOND("Port source" << scrPortPacket);
}
-----------------------------------------------------------------

I can jump to SinkRx and count size of packets correctly, but I don't
know how to obtain IP source/destination from packet.
With TcpHeader I can get port (no IP), but the number returned from
the program is '0', so I'm doing something wrong.

If i use:

Ipv4Header ipv4Header;
m_currentPacket->PeekHeader(ipv4Header);

Ipv4Address destAddressPacket = ipv4Header.GetDestination();
Ipv4Address scrAddressPacket = ipv4Header.GetSource();

NS_LOG_UNCOND("IP address dest" << destAddressPacket);
NS_LOG_UNCOND("IP address source" << scrAddressPacket);

the result is:
0 0
1 0
2 0
3 0
4 0
5 0
6 0
7 0
8 0
9 0
10 0
11 0
assert failed. cond="(verIhl >> 4) == 4", file=../src/internet/model/
ipv4-header.cc, line=289
terminate called without an active exception
Command ['/home/guillermo/Escritorio/ns-allinone-3.12.1/ns-3.12.1/
build/debug/scratch/pfc_exposednode'] terminated with signal SIGIOT.
Run it under a debugger to get more information (./waf --run <program>
--command-template="gdb --args %s <args>").

NS_LOG_UNCOND(ad); returns --> 02-06-c0:a8:01:03:01:c0

What can I do?

Thanks


On 31 oct, 17:45, John Abraham <johnj...@gmail.com> wrote:
> If you are using packetsink you have Rx trace sourcehttp://www.nsnam.org/docs/release/3.12/doxygen/classns3_1_1_packet_si...

>
> If you use the style in manet-routing-compare.cc
> we have
>   sink->SetRecvCallback (MakeCallback
> (&RoutingExperiment::ReceivePacket, this));
>
> both styles notify you , when the application layer receive a packet.
>

> ...
>
> leer más »

[John Abraham]

There are several ways. sometimes i use the following way: the diff is
applied to "fifth.cc"
hg diff
diff -r aa5b5f290a0d examples/tutorial/fifth.cc
--- a/examples/tutorial/fifth.cc Fri Oct 21 08:52:15 2011 -0400
+++ b/examples/tutorial/fifth.cc Tue Nov 01 16:09:05 2011 -0400
@@ -161,15 +161,31 @@
}

static void
+sinkRx (Ptr <Application> pApp, Ptr <const Packet> packet, const
Address & dstAddr)
+{
+ Ptr <PacketSink> ps = DynamicCast <PacketSink> (pApp);
+ std::list <Ptr <Socket> > socketList = ps->GetAcceptedSockets ();
+ Ptr <Socket> s = socketList.front (); // first socket is good
enough
+ Address srcAddr;
+ s->GetSockName (srcAddr);
+
+
+ NS_LOG_UNCOND ("Node:" << pApp->GetNode ()->GetId () << " Src:" <<
InetSocketAddress::ConvertFrom(srcAddr).GetIpv4 () <<
+ " Dst:" <<
InetSocketAddress::ConvertFrom(dstAddr).GetIpv4 ());
+
+
+}
+
+static void
CwndChange (uint32_t oldCwnd, uint32_t newCwnd)
{
- NS_LOG_UNCOND (Simulator::Now ().GetSeconds () << "\t" << newCwnd);
+ //NS_LOG_UNCOND (Simulator::Now ().GetSeconds () << "\t" <<
newCwnd);
}

static void
RxDrop (Ptr<const Packet> p)
{
- NS_LOG_UNCOND ("RxDrop at " << Simulator::Now ().GetSeconds ());
+ //NS_LOG_UNCOND ("RxDrop at " << Simulator::Now ().GetSeconds ());
}

int
@@ -201,6 +217,9 @@
Address sinkAddress (InetSocketAddress (interfaces.GetAddress (1),
sinkPort));

PacketSinkHelper packetSinkHelper ("ns3::TcpSocketFactory",
InetSocketAddress (Ipv4Address::GetAny (), sinkPort));

ApplicationContainer sinkApps = packetSinkHelper.Install (nodes.Get
(1));
+ Ptr <Application> pApp = sinkApps.Get (0);
+ pApp->TraceConnectWithoutContext ("Rx", MakeBoundCallback (&sinkRx,
pApp));
+
sinkApps.Start (Seconds (0.));
sinkApps.Stop (Seconds (20.));


In your case you already have the source Address "ad". To get the
destination address, you will need to obtain the node Id from the
context. And use the Node id to get the ipv4 address from the correct
interface. a long procedure. I use it in NetAnim in some places. In
such cases, you should use "Config::Connect" instead of
"Config::ConnectWithoutContext". If you use Config::Connect, you can
extract the Node id from the context string using a code similar to
GetNodeFromContext in http://code.nsnam.org/jabraham3/netanim/file/612fb0dc0cb2/Simulation/private/simulation.cpp

Finally, the packet that reaches the application layer usually has the
Ipv4headers/Tcp headers already stripped (i did not check). So just
using "GetSize()" is enough.

> ...
>
> read more »

[John Abraham]

oh yeah there is also a GetNode function for ns3::Application
http://www.nsnam.org/doxygen-release/classns3_1_1_application.html#af3fe69baed35c5168ec3b5636ce0736c

So in your case, you could possibly use MakeBoundCallback instead of
MakeCallback and bind the Ptr to the application and extract the Node
id when the callback is called.

> GetNodeFromContext inhttp://code.nsnam.org/jabraham3/netanim/file/612fb0dc0cb2/Simulation/...

> ...
>
> read more »

[Guillermo Gala]

Hi John,

thank you very much.

I could put your code into my program, and works very well.

The only doubt is that, if I send TCP packets from 192.168.1.3 to
192.168.1.5,

NS_LOG_UNCOND ("Node:" << pApp->GetNode ()->GetId () << " Src:" <<
InetSocketAddress::ConvertFrom(srcAddr).GetIpv4 () << + " Dst:" <<
InetSocketAddress::ConvertFrom(dstAddr).GetIpv4 ());

returns me the opposite, Src: 192.168.1.5 and Dst: 192.168.1.3, so I
think that sinkRx function is called when ACK packets are sended from
sink node to source node instead of when TCP packets arrive at sink
node.

Again, thanks John.



On 1 nov, 21:30, John Abraham <johnj...@gmail.com> wrote:
> oh yeah there is also a GetNode function for ns3::Applicationhttp://www.nsnam.org/doxygen-release/classns3_1_1_application.html#af...

> ...
>
> leer más »

[John Abraham]

yes, you are right. just swap the names around.

static void

sinkRx (Ptr <Application> pApp, Ptr <const Packet> packet, const

Address & srcAddr)
{

Ptr <PacketSink> ps = DynamicCast <PacketSink> (pApp);

std::list <Ptr <Socket> > socketList = ps->GetAcceptedSockets ();

Ptr <Socket> s = socketList.front (); // first socket is good enough

Address dstAddr;
s->GetSockName (dstAddr);

NS_LOG_UNCOND ("Node:" << pApp->GetNode ()->GetId () << " Src:" <<
InetSocketAddress::ConvertFrom(srcAddr).GetIpv4 () <<

" Dst:" <<
InetSocketAddress::ConvertFrom(dstAddr).GetIpv4 ());

NS_LOG_UNCOND ("Size:" << packet->GetSize ());

}



and no, the application layer (sink) does not know about TCP semantics
such as ACKs. It only gets the payload.

> ...
>
> read more »

[Guillermo Gala]

Hi again John,

I have a last question.

Is it possible view TCP drop packets on .tr file?

YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();

AsciiTraceHelper ascii;
wifiPhy.EnableAsciiAll (ascii.CreateFileStream ("pfc.tr")); // Create
file with trace

I know that with Point to Point (I don't use Point to Point) you can
view when a packets is dropped with:
Config::Connect("/NodeList/2/DeviceList/*/$ns3::PointToPointNetDevice/
TxQueue/Drop",MakeCallback(&TxDrop));

but in the .tr file generated through NS-3 don't appear those kind of
packets.

Regards

On 3 nov, 08:42, John Abraham <johnj...@gmail.com> wrote:
> yes, you are right. just swap the names around.
>
> static void
> sinkRx (Ptr <Application> pApp, Ptr <const Packet> packet, const
> Address & srcAddr)
> {
>   Ptr <PacketSink> ps = DynamicCast <PacketSink> (pApp);
>   std::list <Ptr <Socket> > socketList = ps->GetAcceptedSockets ();
>   Ptr <Socket> s = socketList.front (); // first socket is good enough
>   Address dstAddr;
>   s->GetSockName (dstAddr);
>
>   NS_LOG_UNCOND ("Node:" << pApp->GetNode ()->GetId () << " Src:" <<
> InetSocketAddress::ConvertFrom(srcAddr).GetIpv4 () <<
>                                                           " Dst:" <<
> InetSocketAddress::ConvertFrom(dstAddr).GetIpv4 ());
>
>   NS_LOG_UNCOND ("Size:" << packet->GetSize ());
>
> }
>
> and no, the application layer (sink) does not know about TCP semantics
> such as ACKs. It only gets the payload.
>

> ...
>
> leer más »

[John Abraham]

I am not sure what you mean by TCP drop packets. TCP usually drops
segments if the sequence number is not in the acceptable window. There
are other reasons for TCP to drop segments such as flags incompatible
with the current state-machine etc. None of these reasons are known by
the lower layers which capture the traces. Sometimes it is
decipherable from the pcap, whether a segment is lost by carefully
tracking the TCP sequence number being retransmitted.

Further, if your loss model is deployed by associating a
ReceiverErrorModel on the receiving netdevice then for both CSMA and
P2P your trace files will not show the dropped packet (only allowed
packets will be seen in the trace file on the receiving node). I am
assuming that is the case with Wifi as well.

> ...
>
> read more »

[Guillermo Gala]

Ok, thanks.

I can see that TCP data is sended, and received for the sink node, but
due to exposed node problem, sink node can't send ACK to source node,
so source node has to send again the packet successively. For that
reason I assumed that source node must to think that TCP data has been
dropped.
(I am using wifi ad-hoc multihop network)

Regards

> ...
>
> leer más »