[Ns-developers] Students, Sockets and Smart Pointers

[Mathieu Lacage]

On Fri, 2008-03-28 at 11:30 -0700, craigdo at ee.washington.edu wrote:

>   UdpSocketHelper sh0 (c.Get(0));  // socket helper on node 0
>   UdpSocketHelper sh1 (c.Get(1));  // socket helper on node 1
> 
> The constructors could add an event that called a run method that the user
> overrides.  In the user-changeable methods, the goal would be to temporarily
> hide things like,
> 
>   TypeId tid = TypeId::LookupByName ("ns3::Udp");
>   Ptr<SocketFactory> socketFactory =
>     GetNode ()->GetObject<SocketFactory> (tid);
>   m_socket = socketFactory->CreateSocket ();
> 
> and
> 
>   m_socket->SetRecvCallback(MakeCallback(&SomeClass::Receive, this));
> 
> Until the user is more prepared to understand and deal with them.  I was
> thinking along the lines of,
> 
>   MyUdpSocketHelper::Run (void)
>   {
>     m_sock = CreateSocket ();
>     m_sock->Bind ();
>     m_sock->Connect (InetSocketAddress (peerAddress, peerPort));
> 
>     ScheduleSendEvent(Seconds (1.));
>   }
> 
> Here the only things that are exposed are familiar socket calls, and
> something to schedule an event to kickstart the simulation.  The fact that
> it is an event-based simulation is not hidden, but some of the details
> regarding how to manage events are ... deferred so a newbie can focus on
> what's important, and not have to understand what 
> 
>   m_sendEvent = Simulator::Schedule(dt, &UdpEchoClient::Send, this);
> 
> means quite yet.  The next bit is
> 
>   MyUdpSocketHelper::SendEvent (void)
>   {
>     m_sock->Send ("hello");
>     ScheduleSendEvent(Seconds (1.));
>   }
> 
> Again, there's nothing to distract from the essence of the simulation.
> 
> Finally there is a simple receive method, something like,
> 
> MyUdpSocketHelper::Receive(char *buffer, uint32_t buflen, const Ipv4Address
> from)
> {
>   NS_LOG_FUNCTION;
>   NS_LOG_INFO ("Received " << buflen << " bytes from " << from);
> }
> 
> So I'm not talking about anything super-significant in terms of development
> effort.  I'm not talking about changing the way the simulator works.  As
> I've said, it's more of a small helper to ease someone into ns-3 and point
> them in the right direction at the start.  Someone should be able to take
> the socket helper and understand what it is doing at the highest level quite
> easily.  Major simulator concepts are introduced with no baggage.  Once he
> or she gets something working, s/he can begin to poke into the class itself
> and see how the internals are working where the real ns-3 API is exposed.
> 
> I'm only pondering the helper concept extended to things that happen while
> the simulation is running.

I agree that a simple base class with provides a single Run function
would go in the right direction because it would make the application
execution context lifetime much more explicit. Longer term, I think that
the real solution would be to give to that Run function synchronous
semantics with a good synchronous API which is much closer to a
real-world socket/process API with automatic per-process ressource
management, blocking calls, threads, integer file descriptors, et al.

The execution context would become vastly more intuitive because exiting
Run would be just like exiting a main function in a normal program. I
believe that this is the reason why joseph mentioned a synchronous API
and I wholeheartedly agree that this is the right solution. And the good
thing is that this is not hard: it is maybe 2 weeks of work to get a
working prototype (most of which would be spent dealing with socket bugs
because we never exercised a lot of the socket API) but, unfortunately,
we are a bit short on time and resources these days :/

regards,
Mathieu