[Ns-developers] ns3 TCP merge candidate

[Gustavo Carneiro]

On 24/01/2008, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
>
> On Thu, 2008-01-24 at 11:46 +0000, Gustavo Carneiro wrote:
>
> > The correct design is IMHO to make applications only handle "fully
> > prepared" sockets, i.e. it should be the resonsibility of the client
> > code to create and connect the socket prior to handling it to the
> > Application class.  Then  the Application can just use SendTo (),
> > which works equally well for both stream and datagram sockets
> > (right?).
>
> SendTo on a stream socket should be prepared to the fact that a stream
> socket might send only part of the input packet so, it should be
> prepared to re-invoke SendTo with a part of the input packet.


Correction on my last post: Application should use Send(), not SendTo():

       If  sendto() is used on a connection-mode (SOCK_STREAM,
SOCK_SEQPACKET)
       socket, the parameters to and tolen are ignored (and the error
EISCONN
       may  be  returned when they are not NULL and 0), and the error
ENOTCONN
       is returned when the socket was not actually connected.  Otherwise,
the
       address  of  the  target is given by to with tolen specifying its
size.
       For sendmsg(), the address of the target is given by msg.msg_name,
with
       msg.msg_namelen specifying its size.

It's true what you say.  Application should be prepared to re-send part of a
packet in case Send() returns a size < packet.Size ().

However, I have to question a more basic assumption.  Why does Application
work with stream sockets at all?  At least for the onoff application it does
not make complete sense.  You ask it to send data at a specified data rate,
but TCP congestion/flow control will limit the data rate by which you can
send.  How will this interaction work?

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert