Challenge Overview

Overall Requirements

The objective of the NASA DTN Project is to develop an overall set of data communications protocols and associated deployment infrastructure to enable space agencies to incrementally build up a Solar System Internetwork (SSI).  The NASA Space DTN Project will develop and mature the necessary and generic DTN technology for use on a wide range of human and robotic space missions that will be part of the SSI.

The DTN protocol suite can run over the existing Internet Protocol (IP) suite or it can operate by itself as a full Internetworking protocol. DTN provides assured delivery of data using an automatic store-and-forward mechanism, while IP generally does not.

NASA needs to integrate the ION Disruption Tolerant Networking (DTN) implementation of Bundle Protocol (BP) with Microsoft Outlook and Microsoft Exchange Server to support the transfer of astronaut email to/from the International Space Station (ISS).

Microsoft Exchange Server currently supports RPC over HTTP(s) protocol (a.k.a. Outlook Anywhere -  http://msdn.microsoft.com/en-us/library/cc243950.aspx). TopCoder will architect and assemble a pair of gateways that will be responsible for bundling the RPC over HTTP payload and send them using ION-DTN Bundle Protocol. We should use Delay  Tolerant  Payload  Conditioning  (DTPC)  Protoc over BP to send data.

DTPC enables  the  following  end to end  services:

  • Application  data  unit  aggregation
  • Retransmission based  reliability
  • In order  delivery  of  application  data  units
  • Duplicate  suppression

One gateway is located on the ISS and the other is located on earth. The space gateway will be developed as an apache module and the ground gateway as a daemon process. Both run on Linux. The picture bellow presents the technology stack:

The communication between layer is depicted bellow:

However, the scope of this architecture does not involve the RPCH protocol. We want to transfer the payload from the above layer, so your API should provide callbacks where the information received is decoupled from the DTN concept. The callback implementation should be able to pack or divide the data from the upper layer into Application Data Units (ADU - DTPC payload).

The picture bellow illustrates that the DTN modules can be used as C callbacks and that's the scope of this competition. Design the callbacks that the higher-level and the lower-level RPCH modules (proxy and client) will use to receive data to transfer as bundles and to propagate incoming bundles up the protocol stack.

For example, you can define a callback that will simply receive a byte array and encapsulate it as bundles and send to BP.

There are existing tools such as bpsend and bpreceive as well as dtpcsend and dtpcreceive which are able to send and receive bundles, but we need to develop a single application that will receive data from upper layer through a well defined API callback, create the bundles and send through BP. It will listen for BP bundles, convert back to the expected response format (i.e., byte array) and call a registered API callback. The result product will be two command line libraries which will be statically linked to a simple ping/echo application that will echo back what was received.

As a starting point, consider the following callback signatures. You are not restricted to these signatures. You should also consider adding callbacks for:

  • Data cancellation / expiration
  • Error handling
  • Disconnection

BP GROUND module will provide a callback registration for callback #1. This callback has the same signature as callback #3 which would be defined by the SPACE application (or the RPCH module).

type int /* return Code */ (*sendRequestCallbackFuncPtr)(int /*id*/, byte* /*buffer*/);
void registerOutgoingCallback(sendRequestCallbackFuncPtr func);


RPCH client will implement a function with this signature and register.

int sendRequestToExchangeServer(int id, byte* buffer);
MODULE::registerOutgoingCallback(sendRequestToExchangeServer);


BP SPACE module will provide a callback registration for callback #2. This callback has the same signature as callback #4 which would be defined by the GROUND application (or the RPCH client).

type int /* return Code */ (*sendRequestCallbackFuncPtr)(int /*id*/, byte* /*buffer*/);
void registerOutgoingCallback(sendRequestCallbackFuncPtr func);


RPCH client will implement a function with this signature and register.

int sendRequestToExchangeServer(int id, byte* buffer);
MODULE::registerOutgoingCallback(sendRequestToExchangeServer);


Final Submission Guidelines

Submission Deliverables

The DTN BP Space and Ground API will be delivered as statically compiled libraries. The space DTN BP library will be linked with a command line application that will call its callback and wait for response.  The ground DTN library will be linked with a command line application that will register a callback and echo back what it receives. The application must not need to be aware of DTN code.

The ION-DTN source code has bping.c and a bpecho.c code that can be used as reference for your design. You should add extra features, such as error handling, endepoint configuration instead of command line, etc. Your API should be responsible for hiding all DTN code from the external application that will be linked with it.

Please, see attached System Design Specification document for more details.

Your Module Architecture submission will contain a combination of the following documents (from http://apps.topcoder.com/wiki/display/tc/Module+Architecture+Tutorial+-+Deliverables):

  • Application Design Specification
  • Sequence Diagrams
  • Class Diagrams
  • Component Diagrams
  • Assembly Specification(s): we can support up to 2 assemblies, but we believe one might be enough.

Project Resources

Reference documentation. You have the bundle protocol specification as well as the link to download and setup the tools, if needed:

Environment

  • Linux (Redhat or Ubuntu)
  • C
  • ION-DTN 3.2.0

Final Submission Guidelines

Submissions must adhere to the following guidelines:

1. Third Party Code/Libraries - All third party code/libraries must be open source and you must include the license in your submission. The license must allow us to modify/re-package the code as necessary. If you have any questions regarding this, please post in the forums. Submissions that include third party code without the proper license information will be disqualified if the third party code is found to be non-usable due to license restrictions.

2. Attribution/References- You must properly attribute and or reference any sentences, paragraphs or quotes that you cite in your text-based submission. If your submission is found to include text that has been copied and pasted from an online source without properly attributing the source, you will receive a not-so-nice email from the topcoder competition manager.

3. Spell Check - We understand that not all submitters will be native English speakers and that there will be spelling/grammatical mistakes. We request that you first run your submission through a grammar/spell checker before submission so as to fix simple mistakes.

ELIGIBLE EVENTS:

2014 TopCoder(R) Open

REVIEW STYLE:

Final Review:

Community Review Board

Approval:

User Sign-Off

SHARE:

ID: 30043039