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

Re: [ns] TcpApp behaviour





>I am trying to use TcpApp and I face this strange behavior:
>
>- everything  works fine when I send data from the application that
>calls 'connect' to the other.
>
>  $tcp2 listen
>  set app1 [new Application/TcpApp $tcp1]
>  set app2 [new Application/TcpApp $tcp2]
>  $app1 connect $app2
>
>  $ns at 1.2 "$app1 send 100 \"$app2 app-recv 100\""           (*)
>
>
>-but when I try to send data first from the "listener" to the other part
>nothing happens.  I am doing this replacing line (*) with:
>
>  $ns at 1.2 "$app2 send 100 \"$app1 app-recv 100\""
>
>- it is even stranger that this transfer succeds when code looks like:
>
>   $ns at 0.6 "$app1 send 100 \"$app2 app-recv 100\""
>   $ns at 1.2 "$app2 send 100 \"$app1 app-recv 100\""
>
>
>Probably I am missing something ....

ok, this is not related to TcpApp but rather to FullTcp. When in state 
TCPS_LISTEN one cannot send a packet. What happens is that TcpApp::send calls 
Application::send, wich calls FullTcpAgent::sendmsg() wich calls 
FullTcpAgent::advance_bytes. If you look at the code there you will see that it 
simply returns without doing anything if in state LISTEN.

There could be a problem if you try to send from app1 to app2 and then from app2 
to app1 like in the above script : the second line might be executed when the 
agent is in state LISTEN and thus no packet will be sent. 

The question is : could it be possible that an agent need to send packet while 
in state listen, as required by the application over it? Perhaps we should 
provide a way for the application to test if the agent below is in a state where 
transmission is possible. Or return an error message to the user. Any comments?

Thanks,

Tarik.