Re: [ns] TcpApp behaviour

[matei <matei@cs.uchicago.edu>]

Tarik Alj wrote:

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

i agree ...

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

... here is something i do not understand. As far as I know TCP connection moves
from to state ESTABLISHED after  a successful connect() call.  So, after connect(),
I should be able to send data on this connection both directions.

(may way to get around this was to always have app1 (the part that does connect())
sending a dummy message to app2 (that does listen()) and then to start the real
application simulation 1s later).

any comments?

Thanks,
-matei

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