[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ns] Trivial question about TCPSink



Hi again,

Sorry for sending this separate mail - just noticed the typos as my mail got
back to me from the ns list. I meant to say that I increased my own (bound)
bytes_ variable RIGHT AFTER the numBytes = ... line in the recv method.

Cheers,
Michael

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of
> Michael Welzl
> Sent: Friday, April 27, 2001 9:05 AM
> To: 'Lloyd Wood'
> Cc: 'ns users'
> Subject: RE: [ns] Trivial question about TCPSink
>
>
> Hi,
>
> I don't quite get the recvBytes(int bytes) method thing.
> Anyway, I solved that problem by introducing a bound bytes_ variable
> variable which I increased by numBytes numBytes line (2nd
> line (*), numBytes
> = ... )in the recv method. Is there anything wrong with this?
>
> Cheers,
> Michael
>
>
> (*) for more 2nd line, see http://www.rebirthbrassband.com/
> ;-)
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of
> > Srihari Raghavan
> > Sent: Friday, April 27, 2001 12:41 AM
> > To: Lloyd Wood
> > Cc: ns users
> > Subject: RE: [ns] Trivial question about TCPSink
> >
> >
> > Hi,
> >   Thank you for your time. I noticed after my post that you
> > had answered it
> > in one of the previous postings. Sorry about that.
> >   For others, in case one needs, here is the posting of the
> solution.
> >   http://mash.cs.berkeley.edu/dist/archive/ns-users/0003/0069.html
> >
> > Thanks
> > Srihari Raghavan
> >
> > -----Original Message-----
> > From: Lloyd Wood [mailto:[email protected]]
> > Sent: Thursday, April 26, 2001 6:17 PM
> > To: Srihari Raghavan
> > Cc: [email protected]
> > Subject: Re: [ns] Trivial question about TCPSink
> >
> >
> > On Thu, 26 Apr 2001, Srihari Raghavan wrote:
> >
> > > I am using a variation of the traditional dumbbell shaped
> > topology with
> > > both UDP (CBR) sources and TCP (infinite FTP) sources. I am
> > trying to mix
> > > these two traffic in a common bottleneck link that has less
> > capacity than
> > > compared to the rate at which the sources generate traffic. When I
> > increase
> > > UDP traffic I expect TCP througphut over time to decrease
> > due to the TCP
> > > congestion control.
> > >
> > > The question is that I need to collect bandwidth (in Mbps) at the
> > > TCPSink. With, Agent/LossMonitor sink for the UDP case, I
> > use "bytes_" in
> > > the oft-repeated "record" function to collect statistics.
> > With TCPSink I
> > do
> > > not have a similar data member.
> >
> > You need to hack TCPSink's recv() function in the
> tcp-sink.cc file to
> > record the data you want, after introducing your own bound
> variables.
> > For the actual bytes received, numbytes in the tcp-sink file should
> > probably be a bound variable - but isn't. (note that header overhead
> > isn't counted, and doesn't exist anyway.)
> >
> > There's a pointer to a (very simple, because I'm lazy) hack on my ns
> > webpage to record the rather different application-level
> throughput by
> > adding a recvBytes() method. This should probably increment a bound
> > variable called numbytesdelivered_ or somesuch.
> >
> > TCPSink is generally neglected IMO.
> >
> > L.
> >
> > > I tried using the TCP agent's "ndatabytes_", but it gives
> > the sender's
> > > view of the TCP bandwidth. What I need is the reciever's
> > > (TCPSink's) view of TCP bandwidth recieved over time. Do I
> > need to use
> > > "acks" at the sender? Or is there any other way?
> > >
> > > Thank you for your time
> > > /Srihari
> > >
> > >
> >
> >
> <[email protected]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
> >
>