[Ns-developers] [ns3] socket API

[George Riley]

I've been out of touch for a couple of days and obviously missed  
replying
to the large volume of traffic on this subject.  Let me try to  
summarize a couple
of points.

I'm still firmly in the camp that we need an API that says:

send(uint8_t* data, size_t length)

I am aware that our API is sufficiently different from "real sockets"  
due to
the blocking/non-blocking issues, but I don't think that means we should
abandon other similarities without good reason.

Mathieu pointed out that users will often want "dummy data", with
no real payload.  This is certainly the case, and both Sally Floyd and I
argued strongly for this early o.  In fact this capability is what is  
presently
checked in:

int Socket::Send (const uint8_t* buf, uint32_t size)
{
   NS_LOG_FUNCTION;
   Ptr<Packet> p;
   if (buf)
     {
       p = Create<Packet> (buf, size);
     }
   else
     {
       p = Create<Packet> (size);
     }
   return Send (p);
}

A call to "send" with a null pointer for the data buffer results in a  
packet
with the dummy payload.  In the non-dummy case (I believe, please  
correct if wrong)
the data is copied right there on the spot, which to me is exactly the  
right
behavior (the real socket send call copies the data, the caller need  
not be concerned
about saving it after the send call).

The ns3 socket API also has the "Send(Ptr<Packet>p)" which users who  
want the
byte manipulation part of the packet API can use. I believe Gustavo  
used this in the
OLSR implementation.  This is fine, and I'm not arguing against this  
API, just that
is must not be the ONLY way to call send.

The discussion got started in the context of the finite send and  
receive buffers. What is
presently implemented is infinite size for both.  In thinking about  
this, let me propose an
alternative solution.  Clearly, the finite receive buffer is only  
meaningful when/if we are
modeling application and operating system scheduling behavior.  For  
example, presently
when data shows up, it is upcalled immediately to the application, and  
the size of the
rx buffer is not relevant.  It only becomes relevant if the receiving  
applicaition is not blocked
on a read, or is not schedulable at that time.  The send buffer is not  
quite the same, but again
the only time it is really relevant is if the user wants detailed  
modeling of the timing of the
application.

So here's the proposal; let's keep infinite send and receive buffers  
in the current API,
exactly as checked in. In Mathieu's multi-threaded blocking sockets we  
should enforce
the finite buffers, since it becomes much easier to model that when we  
have a blocking
thread.

How does this sound?  I suspect I might have missed an issue or two,  
as the previous
thread on this subject was rather lengthy, but this seems to me the  
right approach.

George

--------------------------------------------------
George Riley
Associate Professor
Georgia Tech
Electrical and Computer Engineering
riley at ece.gatech.edu
404-894-4767
Klaus Advanced Computing Building
Room 3360
266 Ferst Drive
Atlanta, Georgia 30332-0765

ECE4110 Web page:
http://users.ece.gatech.edu/~riley/ece4110/

ECE4112 Web page:
http://users.ece.gatech.edu/~riley/ece4112/