[Ns-developers] [ns3] a synchronous socket/posix API

[Gustavo Carneiro]

I see a file named
fiber-context-sysv.c<http://code.nsnam.org/mathieu/ns-3-simu/file/e7816374253e/src/process/fiber-context-sysv.c>,
and this makes me wonder, how portable is this code?  Will it also work in
non-unix platforms?  Can you explain roughly how it works, without getting
into much detail?

Thanks.

On 04/04/2008, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
>
> hi,
>
> During a recent discussion, the topic of providing a synchronous
> socket/posix API came back to haunt us and I made the now-familiar
> statement that it was really a 2-week prototyping hack. Because I
> thought that this was actually more fun than hacking on the Helper API,
> I wrote this code:
>
> "hg clone http://code.nsnam.org/mathieu/ns-3-simu"
>
> The directory src/process contains the prototype implementation while
> example/process.cc contains an example application.
>
> To summarize, the goal is that the full posix/socket API is defined in
> src/process/simu.h: each posix type and function is re-defined there
> with a simu_ or SIMU_ prefix to avoid ugly name clashes and collisions
> (feel free to come up with a better prefix).
>
> Each process is created with a call to ProcessManager::Create and is
> attached to that ProcessManager instance. So, if the ProcessManager
> (which is aggregated to a Node in src/helper/process-helper.cc) is
> killed when the simulation ends, the system will automatically reclaim
> all the resources of each process associated to each manager. The same
> happens when an application "exits" from its main function.
>
> The example application defines two posix "processes": the function
> ClientProgram creates a udp socket on the localhost port 2000 and the
> function ServerProgram creates a udp socket on the localhost port 2000.
> The code does not work right now because I did not get the details of
> simu_read right yet but, I do plan to make this work at some point.
>
> I really think that this approach is worthwhile for many reasons, a few
> of which are outlined below:
>
>   - makes porting real world application code _much_ easier
>
>   - makes write applications for new users much easier because they can
> read the bsd socket api reference and documentation and write code
> directly.
>
>   - can be used to write applications which work in both simulation and
> in the real world at the same time. To do this, all you have to do is
> write your application to use the simu_ API, and, then, you can chose at
> compile-time which implementation of that API you want to use: you can
> pick one implementation which forwards all calls to the system BSD
> socket API or another one which forwards all calls to the attached
> ProcessManager. Arguably, I did not implement the version which forwards
> to system BSD sockets but, that should be pretty trivial.
>
> So, anyway, comments about the overall API would be welcome. Students
> interested in the gsoc project for real-world code integration should
> consider looking at this also.
>
> regards,
>
> Mathieu
>
>


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