NASA Astronaut Email - MS-RPC over HTTP - ION-DTN Module Architecture

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