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

[Sam Jansen]

Looks like it is based on makecontext et. al., which are now
deprecated POSIX functions (see
http://www.opengroup.org/onlinepubs/000095399/functions/makecontext.html
). These functions allow one to save and switch stack space, which
allows you to implement co-operative multitasking in user space.

Practically, newer versions of glibc on Linux have an implementation
of this, at least for i386 and amd64. It appeared somewhen in the
2.3.x series of glibc I think. FreeBSD and Darwin also have
implementations in their libc implementations as far as I know. I
don't know how wide ranging support for this is, when I looked into
these a few months ago I found support lacking in some areas.

It might be useful to have a threads based implementation and fall
back to that when these aren't available. I've done this with threads
in the past which isn't too hard, but I found efficiency to be lacking
a bit. Do you test performance at all Mathieu?

Anyway, I think this is really good work and I agree with all of the
points stated. It's really nice to be able to write blocking
applications for simulation.

On Fri, Apr 4, 2008 at 3:38 PM, Gustavo Carneiro <gjcarneiro at gmail.com> wrote:
> 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
>