Re: [ns] TcpApp behaviour

[Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca>]

>> 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?
>
the connect call just sets the dst target in both apps; it doesn't have anything 
to do with TCP's state machine, I think. 

the thing is that a TcpApp doesn't know wether the underlying agent is in 
ESTABLISHED state or another state; wich can lead to the problem you have 
experienced. 

And FullTcpAgent is still very bugy (that code is so ugly to look at it's 
understandable).

So yes, there is a problem; if you try to send a message you should at least be 
able to know wether the transmission has succeded or not.

Tarik