[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.