Key Information

Register
Submit
The challenge is finished.

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.

One gateway is located on the ISS and the other is located on earth. The space gateway will be developed as an HTTP 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:

The scope of this architecture does not involve ION-DTN. We want to be able to use Outlook Anywhere through a proxy designed in a way that the transport of the HTTP payload is pluggable and asynchronous. The picture bellow illustrates that the DTN modules can be used as C callbacks, but not at this moment. They will be hooked in the future.

As a starting point, consider the following callback signatures. You should not be limited to only these functions. You may want to add a close connection function and an alert data expiration, etc. You may need to add expiration date to this signature and so on.

RPCH module will provide a callback registration for callback #1:

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);

 

RPCH client will provide a callback registration for callback #2:

type int /* return Code */ (*receiveResponseCallbackFuncPtr)(int /*id*/, int /*error code/*, char* /*response buffer*/);
void registerIncomingCallback(receiveResponseCallbackFuncPtr func);


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

int receiveResponse(int id, int errorCode, byte* buffer);
CLIENT::registerIncomingCallback(receiveResponse);


Final Submission Guidelines

Submission Deliverables

The space MS-RPCH module will be delivered as an HTTP server proxy module (mod_proxy_msrpc_dtn). Out http server will be Lighthttpd (http://www.lighttpd.net/) - but you may present other options you are familiar with. The ground MS-RPCH client should be an external library that could be linked with the HTTP server proxy module for testing purposes. The ground client will use existing HTTP C client libraries, such as serf (https://code.google.com/p/serf/) to access the Exchange Outlook Anywhere server. The ground client must issue the HTTP request asynchronously and send its result through registered callback. The proxy should hold the incoming HTTP connection until it gets the response from the client.

SSL certification as well as authentication will be handled by the HTTP APIs: SSL on the server side and basic authentication on the client side, where the credentials should be passed by the proxy module in order to be used in the client request.

Your submission will be used as an input for assembly competitions. There is no design / development phases.

There is an existing implementation of a mod_proxy_msrpc that can be used as a reference - https://github.com/bombadil/mod_proxy_msrpc . It works on Apache HTTP server and delegates to mod_proxy_http, so it does not directly fit needs, but it might provide some clues for implementating ours on Lighthttpd.

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.

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

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)
  • Outlook client 2010
  • Exchange server 2010
  • Light HTTP Daemon
  • HTTP client (serf, for example - https://code.google.com/p/serf )
  • C

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: 30043038