[Ns-developers] Students, Sockets and Smart Pointers

[Gustavo Carneiro]

On 28/03/2008, Craig Dowell <craigdo at u.washington.edu> wrote:
>
>
> > I might partially agree with what you say students should or
> > should not do.
> > But is beside the question.
> >
> > The issue here is whether or not NS 3 should 1) catch users
> > mistakes and
> > print a useful error message, or 2) accommodate different
> > programing styles
> > which people with different backgrounds may be used to.
>
>
> I am pointing out that there is a broader issue of whether or not it is a
> good thing to dump people into the low-level API when they aren't ready
> for
> it.  From one perspective you seem to be agreeing with me while
> disagreeing.


It seemed to me you were saying that _the_ solution for this particular
problem was more and better documentation.  I was disagreeing that
documentation should not be the only solution, or even the most important
solution.

It seems to me that it is clear that the student in question didn't
> understand what was going on.  I am thinking along the lines of your
> number
> 2 above.  We could accommodate people who aren't ready for the low level
> API
> by making something easier to deal with at a higher level.


Not only the student, I myself was a bit perplexed to find out the socket
was being deallocated before time.  That's why when reading the code I could
not find the bug; I was forced to use NS_LOG extensively to figure out what
was going on.  My expectation was that sockets would be "kept" by the Node,
the same way Applications are kept by the node.  Usually in my programs I
keep references to the sockets, but it's just my style of programming.

I'm a bit perplexed by 1.  If someone deallocates something but he really
> didn't mean to it's going to be hard to deal with that.  If you mean there
> should be a good warning message telling the user that a packet came in
> but
> there's no socket to send it to, that seems like a good thing and a simple
> solution.


Well, it may or not be helpful to print a warning when a packet arrives to a
node and there is no entity (doesn't have to be a socket) to consume it.
I'd say it's worth a try, but I wouldn't be 100% sure it would turn out too
well... real world hosts do not log this kind of stuff...

> In
> > the case in
> > question, however, NS 3 does neither of the above.  In this case the
> > programming error just leads to a "silent failure", i.e. the
> > packets are not
> > received in the destination node, but there is no hint from
> > NS-3 of why that
> > happens; not even one of those cryptic assertion failures this time...
>
>
> I think a warning or some kind of message would be appropriate.  I'm not
> sure that trying to change the way sockets are allocated or freed is going
> to solve the problem of someone who doesn't know how to drive the system.


I think programmers are used to sockets being explicitly closed or else kept
alive.

> Teaching to code "correctly" is not a good solution, else why
> > do we need
> > smart pointers at all?  Let's get rid of Ptr<T> and "teach"
> > programmers to
> > Ref and Unref.
>
>
> That's not at all what I meant.  What I said is that there is a low level
> interface that some people will be comfortable with.  This student clearly
> didn't understand it.  We could demand that everyone understand smart
> pointers and Objects and Parameters and all before they start.  That's the
> direction I was headed some time ago.  After looking at Tom's presentation
> it started to become clear to me that we need to ease the transition into
> this stuff.  That was the main reason I changed my mind and agreed about
> helpers being stack-based C++ objects and not Ptr<x> objects.
>
> I'm suggesting that perhaps in parallel with our topology creation helpers
> it would be a good idea to put together some kind of simple socket helpers
> to allow people like your student to succeed in simple situations like
> trying to send a packet from one node to another without having to
> understand the whole system and get lost in Ptr<Socket>-land.


 I am not as confident that adding more layers is a solution.   If the extra
layer does some ammount of  significant work, maybe it helps.  But I don't
see how an extra socket layer is going to help; why not just make sockets
easy to use to begin with?

> I'm sorry, but every time I see a case like this I cannot in
> > good conscience
> > simply learn from my mistake and move on, because I know many
> > others will
> > probably make the same mistake and spend the same time as I
> > did figuring out
> > what is wrong.
>
>
> I don't understand how you can take away that message from what I
> wrote.  I
> am saying that we need to address the situation in a much more serious and
> fundamental way than just by changing the socket lifetime management
> mechanism or adding a printf.  I thought I'd made it that there were
> issues
> regarding the socket lifetime that needed to be addressed separately.
>
>
> > A good library, where reasonable, prevents
> > programmers from
> > making mistakes, even when those programmers are in a hurry
> > to get the code
> > working have not had time to read the entire reference manual.
>
>
> Correct.  However someone who's trying to use a C library should probably
> understand a little C, just as a person who's trying to use the ns-3 low
> level API should understand it a little.
>
> I think it may be a better solution to try and make something along the
> lines of BASIC for people who are in a hurry and don't RTFM.


I don't disagree with a layered API  approach, but the transition between
layers has to be very smooth, and each layer must do some non negligible
ammount of work, not just change API semantics in subtle ways from one layer
to the layer above.

> A similar rule exists for graphical user interfaces, btw.
> > They say that a
> > good GUI should be intuitive enough to allow users to perform most
> > operations without having to even open the user manual.
>
>
> Which is what I'm suggesting.  Something intuitive and familiar for people
> who don't want to read the manual and do something more singnificant.


I still don't agree.  We have two choices:

  1. Fix the sockets, make them intuitive to use;
  2. Add a new layer on top of sockets;

For 2, the downside is that we would just be providing an additional socket
API, or alternative API.  In which case, why would have sockets in the first
place?  Two APIs to do the same thing at the same level?...

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