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

Re: [ns] Problems using TcpApp wit FullTcp



I've been using full-tcp a lot also, and experienced problems when
"re-using" the agents (mostly "hung" connections that would never finish).
Secondly, the packet reassembly code I think is still buggy in that I
sometimes got the abort near the line that says "this should never
happen".

I did three things:

1) Added a "closed_ = 0" in reset (this is the same problem Tarik refers
to).  Without this fix, the "Agent/TCP done" proc is a one-shot, called
only once ever per agent.

2) Added a "reinitialize" method callable from TCL, when essentially
returns the agent to a completely reinitialized state (identical almost to
a newly created agent).

3) Rewrote completely ReasseblyQueue::add(int, int, int) .. I tried for
several days to debug it and just could not.  I deduced from this that the
code is much too complicated!  I of course think my rewrite is simpler and
easier to understand (who doesn't?), and will contribute it to whoever
would like it.  I will caveat this with saying the validate suites claim
some problems after using my code, so it perhaps still has problems but I
haven't looked into it in detail.  There is the chance that with my code
the test suites are just "different", not "wrong", but I don't know that
yet.

With these fixes, I have run literally 10's of millions of full-tcp
connections over the last couple of weeks, with no apparent problems.

George

					
			-George F. Riley ([email protected])

On Mon, 11 Dec 2000, Tarik Alj wrote:

> "Welcome to the ns-users mailing list!
> We automatically send this message to every new person who sends mail.."
> 
> argh, got caught!
> 
> here it is :
> 
> >I'm not sure this is going to fix your problem, but it will help. reset is
> >partially broken in FullTcp. The main problem is that closed_ is defined in
> >tcp.h and then redefined in tcp-full.h. This *is* wrong. I submitted a bug
> >report three month ago, but it has not been committed yet. Read my (lengthy)
> >posting for more details,
> >
> >http://www.isi.edu/nsnam/archive/ns-users/webarch/2000/msg03812.html
> >
> >(see also John Heidemann's reply:
> >http://www.isi.edu/nsnam/archive/ns-users/webarch/2000/msg03859.html)
> >
> >You may want to contact Tarik Alj ([email protected]). He was
> >doing real work with FullTcp at that time, while I was just trying to help. He
> >may have a more mature version of FullTcp.
> 
> I wish I did! As a matter of fact I have been using the FullTcp version I got 
> from Felix and it has been working alright for me.
> 
> You might want to try and run gdb to see if TCP is in the right "STATE" after 
> reset. I think there might also be a problem when "connecting" the agents 
> together, I would look into the behaviour there. 
> 
> Anyways this code is messy, there must be a few bugs just waiting to be stumbled 
> across... If you find more keep us posted!
> 
> 
> >
> >By the way, someone with writing access should have a look to this and make 
> some
> >changes. Thanks.
> >
> >Mark Janssen wrote:
> >
> >> Hello all,
> >>
> >> I am trying to use TcpApp over FullTcp to simulate some application
> >> behaviour. While doing that I run into a problem while connecting different
> >> apps. What I would like to accomplish is the following:
> >>
> >> I have a linear topology of three nodes with an attached FullTcp agent:
> >>
> >> (1)-----------(2)-----------(3)
> >>
> >> After that I create three apps and put the TCP agent at the second node in
> >> the listen state. And connect tcp1 with tcp2 with app1 and app2.
> >> Now app1 sends a message to app2. This all works great. Now because of this
> >> message app2 needs to contact app3. So I connect tcp2 with tcp3 and app2
> >> with app3 and I put tcp3 in listen mode.
> >> When I now send a message from app2 to app3 I only see ACK packets without
> >> TCP packets. I suspect this occurs because tcp2 is still in a different
> >> state then when you create it. I tried to do a "$tcp2 reset" but that
> >> doesn't solve my problem. Below I have include the tcl script, the ns output
> >> and the tracefile.
> ...
> 
> >> $ns connect $tcp1 $tcp2
> >> $app1 connect $app2
> >> #Call the finish procedure after 5 seconds of simulation time
> >> $ns at 0.1 "$tcp2 listen ;  $app1 send 100 \"$app2 app-recv $app1 100\""
> >> $ns at 4.0 "$ns connect $tcp2 $tcp3 ; $app2 connect $app3; $tcp3 listen;
> >> $app2 send 100 \"$app3 app-recv $app2 100\""
> >> $ns at 7.0 "finish"
> >> #Run the simulation
> >> $ns run
> >> ###end tcpapp.tcl
> >>
> ...
> -Tarik 										
> 
> 
> 
> 												
> 
> 
> 
> 
>