NASA Astronaut Email - TCP Proxy Notification Manager Assembly

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 assemble an HTTP(s) proxy that will use DTN to transport the data to earth.

This objective will be divided in 3 parts. This is the second part of the competition which is to change the working HTTP(s) proxy and add a Notification Manager Layer. At this moment, this notification layer will manage a set of threads in a single process. It might look it is an overkill, but these threads will be needed when DTN is introduced.

The first part of the assembly developed a multi-threaded TCP proxy. The srv_loop function waits for Outlook client connections and the con_loop opens a connection with Exchange Server and loops reading and writing data from the Outlook client socket to a new Exchange Service socket and vice versa. Picture bellow illustrates the process:

 

The requirement of the notification layer is based on the picture bellow (there is no architecture for this contest):

 

The notification manager is an abastraction implemented using global variables and C functions. It will basically have the following elements, but you are free to add, remove and rename them:

• A set of functions to receive and send events to and from threads: action_request and action_response which needs to handle. The arguments may vary depending on the action that will take place.
• A connection datastore:an in-memory map of <connection id> to a pair <client socket, server socket>
• The connection ID can be a sequential number incremented at every connection open request

The manage should be able to handle the following requests and responses from the threads:

• OPEN_CONN - the srv_loop requests a new connection to the server passing the client socket as argument (step 2). 
  • Connection manager defines a new connection ID and open a new Thread (T1) to connect to exchange server. The new connection must be done in a new thread because when DTN is introduced this process will be asynchronous.
  • Thread T1 will connect to exchange server (step 3) and reply by calling the action_reponse with one of the following status (step 4):
    • CONN_OK: connection is established, keep client connected
    • CONN_NOK: connection failed, close client connection
  • Once the notification manager receives either of the responses, it will start two threads T2 and T3 passing the connection id to both of them.
  • If the response is CONN_NOK, it should close the client socket.
• Thread T2 is the Outlook client socket thread. It will continuosuly read data (non-blocking) from the outlook client socket (step 5a). When new data arrives, this thread will inform the Notification Manager using a message type CLIENT_DATA (step 5b).
  • Notification Manager upon receiving client data will write this data to thread T3 buffer associated with the given connection ID.
• Thread T3 is the Exchange server socket thread. Similarly, it will read data (non-blocking) from the exchange server socket. (step 6a) When new data arrives, this thread will inform the Notification Manager using a message type SERVER_DATA (step 6b).
  • Notification Manager upon receiving server data will write this data to thread T2 buffer associated with the given connection ID.
• Thread T2 and T3 write buffer:
  • Writing and reading from SSL sockets cannot occur concurrently.
  • A write buffer needs to be created to allow the thread to finish reading without blocking the notification manager
  • The write buffer can be implemented as a synchronized FIFO list
  • Whenever there is data in the write buffer, the thread must write to socket and avoid reading in the meanwhile
  • A synchronization lock/mutex must be created to avoid the concurrency
• If any of T2 or T3 connection is closed, the thread will send a CLOSE_CONN to Notification Manager
  • Notification Manager will inform the other party associated with the given connection ID to close its connection.

The assembly is complete if one is able to send and receive emails through the proxy.

Final Submission Guidelines