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

Re: [ns] Re: reset() in tcp.cc, Question on getting pointer to sink from tcp client



I think one can write code to find out about the other connection. In
principle, you can look at the way the command connect is implemented.
Then we can write some commands to identify teh other end.

One way to do this may be like this:

1. add a command to register the other end for both tcp and the sink
class. 

2. in the code implementing connect, use these commands to register the
peer. 

Another way:

Register the peer with each other eg 
$tcpsink source $tcpsource
$tcpsource sink $tcpsink

where $tcpsink and $tcpsource are agents and sink and source are your own
commands. There may be other easier ways too.

Debo

On Tue, 10 Oct 2000, Eric Weigle wrote:

> Hi everyone-
> 
> What I want to do is add some code tcp.cc to get a pointer to the sink class
> it's working with, so that I can call reset() on the sink class when tcp gets
> reset(). More generally, how can one end of connection find the other end of a
> connection? The motivation and more detail for this is as follows:
> 
> A while back Nabil Seddigh asked why
> > reset() in tcp.cc doesn't currently set the following
> > parameters to zero:
> > 
> > ndatapack_
> > ndatabytes_
> > nrexmitbytes_
> > nrexmit_
> And I couldn't find a response. Any comment? This applies indirectly to what I'm
> doing.
> 
> For me, I'm re-using tcp clients for some of my experiments and I observe the
> following behavior (Tracing tcp.cc newack() routine, where last_ack_ is set)
> ...
> call 1 to newack(): last_ack_: 72, highest_ack_: 71
> (reset gets called)
> call 2 to newack(): last_ack_: 73, highest_ack_: -1
> call 3 to newack(): last_ack_: 74, highest_ack_: 73
> ...
> 
> What's happening (I think) is that since the connection's sink is NOT getting
> reset when I call reset in tcp; the next ack I get holds a number from the
> previous connection; which then overrides the local ack counts.
> 
> Thanks for any information, I know my explanation of the problem may be a bit
> unclear.
> -Eric
> 
> --------------------------------------------
>  Eric H. Weigle   CCS-1, RADIANT team
>  [email protected]     Los Alamos National Lab
>  (505) 665-4937   http://home.lanl.gov/ehw/
> --------------------------------------------
>