{{TOC}}

This webpage highlights project ideas, expectations, and requirements for ns-3's [http://code.google.com/soc Google Summer of Code] 2009 effort. ns-3 is pleased to announce that it has been accepted to the GSoC program for the second year in a row, and looks forward to talking with students about their applications!

== Student Guidelines ==

The ns-3 team is looking for three things from every successful GSoC project:
* Developing code that can be incorporated back into the main codebase and utilized by a variety of users.
* Developing new members that will remain part of the team and contribute to the ns-3 effort even after GSoC ends.
* Providing GSoC students with experience and ideas that will be useful to them in their careers and/or research.

Based on the ns-3 team's experiences in the 2008 Google Summer of Code, the most important factor in the success of an application and project is communication. That process begins in the application phase. Without joining the [http://mailman.isi.edu/mailman/listinfo/ns-developers mailing list] and starting some discussion of your ideas, it is unlikely your application will be complete or rich enough to be competitive. Please feel free to discuss your proposed technical approach, plan, and other factors on the mailing list while developing your application. In addition to helping you develop the necessary details, focus, and priorities to write a good application, that will also demonstrate your commitment and willingness to dedicate time to the effort. During the program, every student is expected to communicate regularly with their mentor, as well as to participate on the [http://mailman.isi.edu/mailman/listinfo/ns-developers development mailing list] and IRC chats.

It is also important for every student to commit fully to the effort. Applicants should recognize that being accepted into GSoC is a serious commitment and will be the focus of their time over the duration of the program. Any existing commitments for class, other jobs, etc should all be discussed as part of your application.

Additional slides about the ns-3 GSoC project are also available, from a [http://www.nsnam.org/docs/gsoc.ppt GSoC Infosession] at the University of Washington on March 5th, 2009.

== Application Template ==

The following are specific items the ns-3 teams requests GSoC applicants include in their proposal.

* '''Project Proposal''' What is the specific topic or area of interest you are proposing to work on?
* '''Interest.''' Why are you particularly attracted to this project?
** ''Future Plans.'' We are especially interested in GSoC applicants looking to pursue research or work in related areas in the future, so be sure to note any relevant plans you may have.
* '''Background.''' What experience or training do you have that makes you best suited to this project.
** ''Education.'' Include your academic or professional background related to data networking, as well as any software experience with C++ and/or Python.
** ''Work.'' Be sure to denote any work experience you have in relevant areas.
** ''Research.'' Be sure to denote any research experience you have in relevant areas.
* '''Approach.''' What is your technical plan for achieving the goals of the project? What components and functionality will have to be developed, integrated, etc?
* '''Deliverables.''' What do you plan as a mergeable code output of your GSoC effort? Please keep in mind that the program is only 10 weeks long and try to incorporate this realistically in the plan.
* '''Plan.''' What is your task schedule to implement your technical plan and develop your deliverables?
* '''Timezone.''' What are your expected work hours (in UTC)? What is your physical location for the summer? The project places no requirements on these but it will effect chat scheduling as well as mentor availability and selection.
* '''Commitments.''' Do you have any other commitments over the summer that would impair your ability to participate in the project, e.g., classes, thesis defense, existing work commitments, etc? Note: The project does not expect students to take personal vacations during this period; if there is a personal conflict planned, please state when, and how you would make up the time.

Of these, the ''Approach'' and ''Deliverables'' elements will require significant thought, development, and discussion. Applicants are advised to bring their ideas to the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list] and open up a discussion with the ns-3 team to develop these portions of their application prior to submission. Only applications that have well refined and developed technical objectives and plans are likely to be competitive. The ns-3 team will provide comments and help refine proposals somewhat after they are initially submitted, but obviously the stronger they start the stronger they will be. In the 2008 GSoC, our strongest student proposals were clearly those which had discussed their projects at length beforehand on the mailing list and on IRC.

In addition, once GSoC proposals have been accepted and reviewed, promising candidates will be invited to "meet" some of the ns-3 team and discuss their project further in an IRC chat.

== Project Ideas ==

The following are project ideas which the ns-3 team has identified as important and is most interested in working on as part of the 2009 Google Summer of Code. GSoC applicants are however free to propose their own ideas. In addition, please note that these ideas are not limited to Google Summer of Code, anyone is welcome to work on them. Please email the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list] if one interests you. GSoC applicants are encourage to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list]. That will help you develop the idea and present a concrete, meaningful application.

Each project idea has been tagged with the following properties:
* ''Required Experience:'' Languages, concepts, or packages with which applicants must be familiar.
* ''Bonus Experience:'' Other experience or familiarity which would be greatly helpful to applicants for this project.
* ''Interests:'' Areas of particular relevance to this project, and an indicator of where successful students might apply their experiences coming out of this project.
Note that all of the projects require some experience and comfort with C++. Project ideas for which C++ is noted as a required experience will require more and deeper familiarity with the language. A similar notion applies to computer networking, BSD sockets, etc: Familiarity is strongly preferred, but is not required except where explicitly noted due to the topic being more advanced in that regard.

=== Priority Project Ideas ===

The following are work areas the ns-3 project has identified as the highest priorities, has several mentors available, and would be especially interested in having students work on.

==== MAC and PHY Models ====
Mentors: [mailto:ruben@net.t-labs.tu-berlin.de Ruben Merz], [mailto:mathieu.lacage@sophia.inria.fr Mathieu Lacage], [mailto:juliana@ic.unicamp.br Juliana Freitag Borin]

* '''Minstrel rate control algorithm.''' [http://linuxwireless.org/en/developers/Documentation/mac80211/RateControl/minstrel Minstrel] is a rate control algorithm originally [https://www.ath9k.org/browser/trunk/ath_rate/minstrel/minstrel.txt?rev=2695 implemented in MadWifi]. This project would port the Minstrel rate control algorithm to the ns-3 802.11 MAC.
** ''Required Experience:''
** ''Bonus Experience:'' WiFi, 802.11, wireless networking, rate control
**''Interests:'' wireless networking, protocol development, resource alloations, 802.11

* '''Antenna radiation pattern.''' This project would implement support for [http://en.wikipedia.org/wiki/Radiation_pattern antenna radiation patterns] in the physical layer of ns-3. In addition to enhancing the realism of the ns-3 physical layer, this would also enable to implement directional antennas in ns-3.
** ''Required Experience:''
** ''Bonus Experience:'' physical layer modeling and simulation, wireless networking
**''Interests:'' wireless networking, physical layer modeling and simulation

* '''Uplink Scheduler for WiMAX.''': The ns-3 WiMAX module currently implements a simple FCFS scheduler based algorithm. In addition to generally continuing to improve that model and its integration, this project would investigate and add a more sophisticated scheduler to support the QoS requirements of multimedia applications. This might be accomplished by porting from an available ns-2 WiMAX module.
** ''Required Experience:'' C++
** ''Bonus Experience:'' WiMAX, IEEE 802.16, ns-2
** ''Interests:'' Wireless networking, MAC layer, resource allocation, 802.16

==== Routing ====

Mentors: [mailto:nbaldo@cttc.es Nicola Baldo], [mailto:mrequena@cttc.es Manuel Requena], [mailto:adrian.sw.tam@gmail.com Adrian Sai-wah Tam], [mailto:ruben@net.t-labs.tu-berlin.de Ruben Merz]

* '''Advanced Queues.''' ns-3 currently implements only a basic FIFO queue. This project would add support for and investigate more sophisticated queues, such as fair queuing, RED, and RIO. This might be accomplished by porting from other projects, such as [http://www.isi.edu/nsnam/ns/doc/node69.html ns-2] or [http://lartc.org/howto/ Linux routing and traffic control] implementations.
** ''Required Experience:''
** ''Bonus Experience:'' Routing architectures, routing protocols, queueing theory, statistics, Linux/BSD kernel, ns-2
** ''Interests:'' High fidelity simulation, queueing theory, statistics, data driven model development

* '''Click Modular Router Integration.''' This project would port and enable ns-3 simulations to use the [http://read.cs.ucla.edu/click/ Click modular router], widely used in research. This has been previously done for ns-2, and accomplishing this integration for ns-3 would enable faster protocol development and utilization of many existing protocol implementations.
** ''Required Experience:'' C++
** ''Bonus Experience:'' Click, routing architectures, routing protocols
** ''Interests:'' Protocol development, routing architecture

* '''Generalized Router Models/Structure.''' Many simulators, including ns-3, do not provide high fidelity models of Internet routers. For instance, intra-device latencies and input queuing behavior are not modeled. This project would adapt recent results on [http://www.cs.ucsb.edu/~rchertov/papers/infocom08.pdf empirical router testing] to develop a new, more detailed Router node type for ns-3.
** ''Required Experience:''
** ''Bonus Experience:'' Routing architectures, routing protocols, queueing theory, statistics
** ''Interests:'' High fidelity simulation, queueing theory, statistics, data driven model development

==== Network Stack ====
Mentors: [mailto:fw@strlen.de Florian Westphal]

* '''Network Simulation Cradle for IPv4.''' Last year's ns-3 Google Summer of Code very successfully ported the [http://research.wand.net.nz/software/nsc.php Network Simulation Cradle], providing the ability to run Linux TCP code over ns-3's IPv4 stack. This project would extend that effort to completely port the Linux TCP/IPv4 stack. This wolud start by adding IPv4 support to NSC, then support for multiple interfaces, routing tables, and assigning addresses, then making those features available in ns-3.
** ''Required Experience:'' C
** ''Bonus Experience:'' Linux kernel, TCP/IP
** ''Interests:'' Linux, operating systems, virtualization, software-in-the-loop

==== Emulation and Simulation In The Loop ====
Mentors: [mailto:craigdo@ee.washington.edu Craig Dowell]

* '''EMULAB Support and Integration.''' This project would attempt to emulate ns-3 and [http://www.emulab.net Emulab], a leading testbed for Internet research. Emulab experiments are described in tcl-like ns-2 scripts and are driven by ns-2 emulation. Two main goals of this effort would be: 1) Test and document how ns-3 emulation mode could be used in Emulab instead of ns-2, and compare its features and performance. 2) Investigate whether Emulab scripting could be moved to Python/ns-3 or whether ns-3 simulations need to generate Tcl for Emulab and attempt to do this integration.
** ''Required Experience:''
** ''Bonus Experience:'' Emulab, ns-2, Tcl
** ''Interests:'' Simulation, emulation, simulation-in-the-loop

==== Peer to Peer and Content Based Routing ====
Mentors: [mailto:marcello.caleffi@unina.it Marcello Caleffi]

* '''Mobile P2P.''' ns-3 currently does not include any implementation of Mobile Peer-to-Peer (P2P) systems. This project would implement some additional networking protocols based on a cross-layer approach between routing and Distributed Hash Tables (DHTs), such as ATR and MADPastry. Both the ns-2 implementations of the cited protocols are currently available and could be used as design guides.
** ''Required Experience:'' C/C++
** ''Bonus Experience:'' P2P, mobile ad hoc networks (MANETs), ns-2
** ''Interests:'' P2P, DHT, MANETs, routing.

=== Additional Project Ideas ===

The following are additional project ideas that the ns-3 team has highlighted as important projects to support.

==== Core Simulation Capabilities ====

* '''Realtime Distributed Simulation.''' This project would add support to ns-3 for running multiple instances distributed over several physical machines connected by and exchanging packet events over an IP network. Achieving this would require adding tunneling devices to ns-3, and developing distributed simulation configuration and control utilizing [http://rpyc.wikidot.com/ RPYC]. Development would build from multiple instances on a single host to a cluster to which the student will be given access.
** ''Required Experience:'' BSD networking
** ''Bonus Experience:'' Python, RPC, distributed systems, cluster computing
** ''Interests:'' Distributed systems, parallel simulation, concurrency, cluster computing, high performance computing, scientific computing

==== MAC and PHY Models ====

* '''SNS for ns-3 Wifi.''' [http://www.cs.cornell.edu/people/egs/sns/ Staged Network Simulations (SNS)] is a patch for the ns-2 wireless models which provides for function approximation and caching. That mechanism greatly speeds up the many calculations required in mobile wireless simulations. This project would incorporate those techniques into the ns-3 WiFi model.
** ''Required Experience:''
** ''Bonus Experience:'' Software profiling, software tuning
** ''Interests:'' Approximation, caching, software profiling, high performance computing, scientific computing

* '''WPAN Device Models.'''
* '''802.11 WDS Support for nqsta.'''

==== Routing ====

* '''Protolib Integration.''' [http://cs.itd.nrl.navy.mil/work/protolib/index.php Protolib] is an application support library that provides networking, timer, threading, and other functionality to support cross platform application and protocol implementation. It has previously been ported to enable programs based on the library to be executed in simulators such as sn-2 and OPNET. This project would port Protolib to ns-3 and enable many existing and well known routing protocol implementations to be immediately used in ns-3. Additionally, this may be followed by porting the Agent-J Java library (see below).
** ''Required Experience:'' C/C++
** ''Bonus Experience:'' BSD networking, threading
** ''Interests:'' Protocol development, mobile ad hoc networking, simulation, cross platform development

* '''Reactive Routing Protocols.''' ns-3 currently includes an implementation of the popular OLSR protocol for proactive mobile wireless ad hoc routing. This project would implement several additional routing protocols, focusing on reactive protocols such as AODV and DSR. Much literature exists in this area to draw from, as well as implementations for both real systems and other simulators such as ns-2 and OPNET.
** ''Required Experience:''
** ''Bonus Experience:'' Mobile ad hoc networking, routing
** ''Interests:'' Mobile ad hoc networking, routing, protocol development

==== Network Stack ====

* '''Network Address Translation (NAT).''' NATs have become an essential part of practical real-life networking, and are an important current research topic as they are being [http://blog.internetworkexpert.com/2008/04/18/understanding-ipv6-nat-pt/ proposed even for IPv6]. [http://www.isoc.org/tools/blogs/ietfjournal/?p=117 NAT traversal] is also an important topic in many user and system monitoring applications. This project would develop a NAT node model for ns-3, possibly by drawing upon the Linux NAT code, as well as common example configurations, such as home or small office connectivity, and start investigating these topics as time allows.
** ''Required Experience:''
** ''Bonus Experience:'' NAT, network management/deployment, firewalling, C, Linux kernel
** ''Interests:'' Internet topology, IPv6, network management/deployment, network security, P2P

* ''' Fragmentation and MTU Discovery.''' IPv4 packets may be fragmented as they travel the network and encounter smaller MTUs. ns-3's packet objects include support for this, but the network stack does not currently implement fragmentation. This project would begin by improving the MTU and fragmentation capabilies to be more realistic, possibly by drawing from code in the [http://cutebugs.net/files/wns2-yans.pdf yans simulator]. The project would then continue to add support for more research-oriented techniques such as [http://en.wikipedia.org/wiki/Path_MTU_discovery Path MTU discovery], particularly for IPv6 which fragments at the endpoints and must discover the proper MTU for a chosen path.
** ''Required Experience:'' IP
** ''Bonus Experience:'' IPv6
** ''Interests:'' IPv6, Internet topology, heterogenous networking

* ''' Virtual NetDevices.''' Virtual devices are network interfaces that are treated like any other device by the operating system, but do not actually correspond to hardware. These are important to provide features such as tunneling overlays for tasks such as VPNs and IPv6--IPv4 traversal, or capabilities such as 802.1q VLAN tagging. For instance, the [http://trac.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup IRTF Routing Research Group] seems likely to suggest a so-called map-and-encaps architecture for helping the global core routing scalability problem. This project would help define and implement an architecture for incorporating virtual devices into ns-3, and develop a few concrete instances of these devices, such as Ipv6-over-IPv4, VLANs, or providing multiple addresses per physical interface for routers to leverage.
** ''Required Experience:''
** ''Bonus Experience:'' IPv6, QoS
** ''Interests:'' IPv6, QoS, tunneling, virtualization

==== Applications and Systems ====

* '''Large Scale Topology Generation and Management.''' ns-2 incorporates support for [http://www.isi.edu/nsnam/ns/ns-topogen.html various topology generators], which would be useful to also support in ns-3. This project would investigate porting topology generators or mapping their output to ns-3 simulations. It would also touch on the problem of coherent IP addressing in generated topologies. In particular, [http://www.cs.utah.edu/flux/papers/ipassign-ftn2005-04-base.html recent work] by the Emulab project may be useful in this regard.
** ''Required Experience:''
** ''Bonus Experience:'' Graph theory, network management, Internet topology
** ''Interests:'' Internet topology, Internet autonomous systems, graph theory

* '''Agent-J Implementation.''' [http://cs.itd.nrl.navy.mil/pubs/docs/agentj-dfma06.pdf Agent-J] is a Java library built on top of [http://cs.itd.nrl.navy.mil/work/protolib/index.php Protolib] that enables Java networking application code to be run on real systems as well as network simulators such as ns-2 and OPNET. This project would port Agent-J to ns-3, thereby enabling users to develop applications in Java, as well as work with existing implementations. This project would require completing the above Protolib Integration effort first.
** ''Required Experience:'' Java, C
** ''Bonus Experience:'' JNI
** ''Interests:'' Java, Java native code, simulation, P2P

== Contact ==

Again, all interested applicants are encouraged to discuss their proposal ideas on the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list]. Many developers also congregate on IRC via #ns-3 on freenode.net, and that is also an appropriate place to discuss ideas.

[[Category:GSoC]]

GSOC2009Projects

2009-04-28T16:55:17Z

Tjkopena:

2009-03-13T13:26:34Z

Tjkopena:

{{TOC}}

This is the webpage for planning [http://code.google.com/soc Google Summer of Code] 2009 projects and mentors. ns-3 plans to apply for a spot in the Google Summer of Code again this year. Please list project ideas and identify possible mentors below.

The ns-3 project presented at a GSoC Infosession at the University of Washington on March 5th, 2009. Slides for the short talk we gave may be found [http://www.nsnam.org/docs/gsoc.ppt here].

'''Disclaimer:''' There is no guarantee that ns-3 will be accepted again in GSoC 2009. We have to re-apply.

== Project Ideas ==

The following are work areas the ns-3 project has identified as priorities and would be especially interested in having students work on. GSOC applicants are however free to propose their own ideas. In addition, please note that these ideas are not limited to Google Summer of Code, anyone is welcome to work on them. Please email the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list] if one interests you. GSOC applicants are encourage to look over this list, pick one that especially interests them, think about it, and discuss potential approaches on the [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers list]. That will help you develop the idea and present a concrete, meaningful application.

=== Core Simulation Capabilities ===

* '''Realtime Distributed Simulation.''' This project would add support to ns-3 for running multiple instances distributed over several physical machines connected by and exchanging packet events over an IP network. Achieving this would require adding tunneling devices to ns-3, and developing distributed simulation configuration and control utilizing [http://rpyc.wikidot.com/ RPYC]. Development would build from multiple instances on a single host to a cluster to which the student will be given access.

=== MAC and PHY Models ===

* '''SNS for ns-3 Wifi.''' [http://www.cs.cornell.edu/people/egs/sns/ Staged Network Simulations (SNS)] is a patch for the ns-2 wireless models which provides for function approximation and caching. That mechanism greatly speeds up the many calculations required in mobile wireless simulations. This project would incorporate those techniques into the ns-3 WiFi model.
* '''WPAN Device Models.'''
* '''802.11 WDS Support for nqsta.'''

=== Routing Internals ===

* '''Advanced Queues.''' ns-3 currently implements only a basic FIFO queue. This project would add support for and investigate more sophisticated queues, such as fair queuing, RED, and RIO. This might be accomplished by porting from other projects, such as [http://www.isi.edu/nsnam/ns/doc/node69.html ns-2] or [http://lartc.org/howto/ Linux routing and traffic control] implementations.
* '''Click Modular Router Integration.''' This project would port and enable ns-3 simulations to use the [http://read.cs.ucla.edu/click/ Click modular router], widely used in research. This has been previously done for ns-2, and accomplishing this integration for ns-3 would enable faster protocol development and utilization of many existing protocol implementations.
* '''Generalized Router Models/Structure.''' Many simulators, including ns-3, do not provide high fidelity models of Internet routers. For instance, intra-device latencies and input queuing behavior are not modeled. This project would adapt recent results on [http://www.cs.ucsb.edu/~rchertov/papers/infocom08.pdf empirical router testing] to develop a new, more detailed Router node type for ns-3.
* '''Protolib Integration.''' [http://cs.itd.nrl.navy.mil/work/protolib/index.php Protolib] is an application support library that provides networking, timer, threading, and other functionality to support cross platform application and protocol implementation. It has previously been ported to enable programs based on the library to be executed in simulators such as sn-2 and OPNET. This project would port Protolib to ns-3 and enable many existing and well known routing protocol implementations to be immediately used in ns-3. Additionally, this may be followed by porting the Agent-J Java library (see below).
* '''Reactive Routing Protocols.''' ns-3 currently includes an implementation of the popular OLSR protocol for proactive mobile wireless ad hoc routing. This project would implement several additional routing protocols, focusing on reactive protocols such as AODV and DSR. Much literature exists in this area to draw from, as well as implementations for both real systems and other simulators such as ns-2 and OPNET.

=== Network Stack ===

* '''Network Simulation Cradle for IPv4.''' Last year's ns-3 Google Summer of Code very successfully ported the [http://research.wand.net.nz/software/nsc.php Network Simulation Cradle], providing the ability to run Linux TCP code over ns-3's IPv4 stack. This project would extend that effort to completely port the Linux TCP/IPv4 stack. This wolud start by adding IPv4 support to NSC, then support for multiple interfaces, routing tables, and assigning addresses, then making those features available in ns-3.
* '''Network Address Translation (NAT).''' NATs have become an essential part of practical real-life networking, and are an important current research topic as they are being [http://blog.internetworkexpert.com/2008/04/18/understanding-ipv6-nat-pt/ proposed even for IPv6]. [http://www.isoc.org/tools/blogs/ietfjournal/?p=117 NAT traversal] is also an important topic in many user and system monitoring applications. This project would develop a NAT node model for ns-3, possibly by drawing upon the Linux NAT code, as well as common example configurations, such as home or small office connectivity, and start investigating these topics as time allows.
* ''' Fragmentation and MTU Discovery.''' IPv4 packets may be fragmented as they travel the network and encounter smaller MTUs. ns-3's packet objects include support for this, but the network stack does not currently implement fragmentation. This project would begin by improving the MTU and fragmentation capabilies to be more realistic, possibly by drawing from code in the [http://cutebugs.net/files/wns2-yans.pdf yans simulator]. The project would then continue to add support for more research-oriented techniques such as [http://en.wikipedia.org/wiki/Path_MTU_discovery Path MTU discovery], particularly for IPv6 which fragments at the endpoints and must discover the proper MTU for a chosen path.
* ''' Virtual NetDevices.''' Virtual devices are network interfaces that are treated like any other device by the operating system, but do not actually correspond to hardware. These are important to provide features such as tunneling overlays for tasks such as VPNs and IPv6--IPv4 traversal, or capabilities such as 802.1q VLAN tagging. For instance, the [http://trac.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup IRTF Routing Research Group] seems likely to suggest a so-called map-and-encaps architecture for helping the global core routing scalability problem. This project would help define and implement an architecture for incorporating virtual devices into ns-3, and develop a few concrete instances of these devices, such as Ipv6-over-IPv4, VLANs, or providing multiple addresses per physical interface for routers to leverage.

=== Emulation and Simulation In The Loop ===

* '''EMULAB Support and Integration.''' This project would attempt to emulate ns-3 and [http://www.emulab.net Emulab], a leading testbed for Internet research. Emulab experiments are described in tcl-like ns-2 scripts and are driven by ns-2 emulation. Two main goals of this effort would be: 1) Test and document how ns-3 emulation mode could be used in Emulab instead of ns-2, and compare its features and performance. 2) Investigate whether Emulab scripting could be moved to Python/ns-3 or whether ns-3 simulations need to generate Tcl for Emulab and attempt to do this integration.

=== Applications and Systems ===

* '''Large Scale Topology Generation and Management.''' ns-2 incorporates support for [http://www.isi.edu/nsnam/ns/ns-topogen.html various topology generators], which would be useful to also support in ns-3. This project would investigate porting topology generators or mapping their output to ns-3 simulations. It would also touch on the problem of coherent IP addressing in generated topologies. In particular, [http://www.cs.utah.edu/flux/papers/ipassign-ftn2005-04-base.html recent work] by the Emulab project may be useful in this regard.
* '''Agent-J Implementation.''' [http://cs.itd.nrl.navy.mil/pubs/docs/agentj-dfma06.pdf Agent-J] is a Java library built on top of [http://cs.itd.nrl.navy.mil/work/protolib/index.php Protolib] that enables Java networking application code to be run on real systems as well as network simulators such as ns-2 and OPNET. This project would port Agent-J to ns-3, thereby enabling users to develop applications in Java, as well as work with existing implementations. This project would require completing the above Protolib Integration effort first.
* '''P2P Protocols.'''

2008-06-23T20:50:57Z

Tjkopena:

In general, when setting or checking a pointer to be a null value, you should explicitly use 0 rather than <code>NULL</code>. To demonstrate, you should use:

<code><pre>
if (ptr == 0) {
// code failed, whine to listserv
}
</pre></code>

As opposed to the commonly used:

<code><pre>
if (ptr == NULL) {
// code failed, whine to listserv but say you used 0
}
</pre></code>

In any event, you should definitely not use:

<code><pre>
if (!ptr) {
// you're fired!
}
</pre></code>

There is some discussion about this issue [http://www.velocityreviews.com/forums/t284567-null-macro-vs-0-as-null-pointer.html here]. In general, <code>NULL</code> is not as crisply defined or its use as straightforwardly intuitive as using 0. The implicit check is also generally avoided in NS3 for reasons of code clarity.

[[Category:Samples]]

CheckingNull

2008-06-23T20:50:21Z

Tjkopena:

In general, when setting or checking a pointer to be a null value, you should instead explicitly use 0 rather than <code>NULL</code>. For example, you should use:

<code><pre>
if (ptr == 0) {
// code failed, whine to listserv
}
</pre></code>

As opposed to the commonly used:

<code><pre>
if (ptr == NULL) {
// code failed, whine to listserv but say you used 0
}
</pre></code>

In any event, you should definitely not use:

<code><pre>
if (!ptr) {
// you're fired!
}
</pre></code>

There is some discussion about this issue [http://www.velocityreviews.com/forums/t284567-null-macro-vs-0-as-null-pointer.html here]. In general, <code>NULL</code> is not as crisply defined or its use as straightforwardly intuitive as using 0. The implicit check is also generally avoided in NS3 for reasons of code clarity.

[[Category:Samples]]