about deleting TCP

[he@expert.cc.purdue.edu]

On Fri, 16 Jul 1999, Haobo Yu wrote:
> Umm... that is indeed a possibility. I've always used persistent
> connections and never tested *thoroughly* the scenario you pointed out.
> Let me know if you found something. 
> 
	By the way, I thought the current method of realsing TCP 
agent as following may have some problem. 

$tcp proc done {} "$ns_ detach-agent $node_ $tcp; delete $tcp"

	Sometimes, when this line (which is in Http/Client) is
executed, the context could be still in a Tcp Agent (e.g.,
the Tcp Agent on client get a Http message and then pass it
eventually to the Http/Client object by "target_"), if somehow
the Http/Client decide to "disconnect" the connection and delete
the very Tcp Agent where the execution context is still in, potential
core-dump will be generated especially in my case when disconnect/connect
are frequently. I suggest following change as:



Http/Client/Clnt instproc disconnect { server } {
    set servWrapper [$self get-cnc $server]
    set tcp [$servWrapper agent]
    $tcp close
    $ns_ at [$ns_ now] "$self cmd disconnect $server"
    # detach the tcp agent and delete it
    $ns_ at [$ns_ now] "$ns_ detach-agent $node_ $tcp;delete $tcp"B
    $server disconnect $self
}


      In this way, when "deleting" is executed, the context will
be in Scheduler in stead of the Tcp Agent itsself. I eliminate
some early stage core-dump by doing above. 

      By the way, I close tcp by calling "FullTcpAgent::finish()"
directly instead of calling "FullTcpAgent:usrclosed()" because
I dont need the details like waiting FIN packets, so on. I simply
call "finish()" for TCP agents on both sides and "delete" them
to tear down a connection (of course, I de-associate and delete
corresponding Tcp Wrappers before delete Tcp Agents). Dont know
whether this method of closing Tcp will trigger problems.


> :( Can you do a gdb on where it coredumped and do a little debugging let
> me know where that crash happened? Thanks. It'll be even better if you
> have purify available... 

	OK, I'll try to but need to learn how to do that first, what if
the dump is within otcl? I'm a little puzzled about how to debug the
mixture of otcl and c++ code:(


Thanks a lot!


kaichuan