[Ns-developers] [ns3] socket API

[Tom Henderson]

George Riley wrote:
> 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,
If I understand correctly, the two main issues you are concerned about 
are to provide a byte-based interface due to familiarity with real 
socket semantics, and to avoid having the application have to marshal in 
  large amounts of data via use of the Send callback.  I'd like to 
explore whether a helper class might be able to provide this additional 
API beyond the current API.  Then, users would be able to choose a 
Posix-based API (blocking or non-blocking), a basic ns3::Socket API, and 
an API that extended ns3::Socket API to support behavior analogous to 
infinite send buffers and the byte-based API calls (i.e., something in 
between).

(I think the first feature (byte-based interface) could be supported 
without this helper class by just extending the API as we have already 
done, but the second feature of providing infinite-like buffers will 
probably require some wrapper around the send callback)

Tom