[Ns-developers] ns3 TCP merge candidate
gjcarneiro at gmail.com
Thu Jan 24 05:33:18 PST 2008
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,
socket, the parameters to and tolen are ignored (and the error
may be returned when they are not NULL and 0), and the error
is returned when the socket was not actually connected. Otherwise,
address of the target is given by to with tolen specifying its
For sendmsg(), the address of the target is given by msg.msg_name,
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
More information about the Ns-developers