First, let me explain what DTN is and why it was developed. A prototypical use of this technology was established and implemented at NASA to meet some peculiar requirements it had. When communicating across very long distances to spacecraft and orbiting bodies, one can imagine that data transfer is not as casual as it is for the average Internet user. Due to these issues, engineers had to be careful about timing and transferring data during certain windows of opportunity.
That kind of planning and timing is manual and labor intensive so a store-and-forward type of protocol was conceived that would ensure all the data sent or received would automatically just “get there” whenever it could.
|
|
The value of that kind of architecture for the intermittent nature of data communication in space is obvious. A similar but much simpler store-and-forward technology that’s more familiar to most people is e-mail, more specifically the simple mail transfer protocol (SMTP).
With e-mail, you send a message and your mail server sends it to the destination immediately if it can. If it cannot send it right away but knows the destination exists, it stores your message, waits, and tries again periodically. It typically tries for about three days (depending on your server configuration) before giving up and notifying you it could not send your message. This is a very simple model that does not rely on multiple node hops like DTN but the principle is the same.
Other than the space communications use, one could see the utility of this kind of capability in other circumstances where communications cannot be relied upon to be up all the time. Examples might include military units in tough battle situations, climbers of Mount Everest, deep undersea expeditions, or extended deep cave explorations perhaps. Anything in which communications might break down for a while, come back up for a time, then go down again. The technology is opportunistic about when connectivity is available.
The downside to DTN is that the nodes, whatever they end up being, need to be capable of storing fairly large amounts of data depending on how long communications are down. That implies that to build the infrastructure right, one would need to know, or make assumptions about, how long communications should or could be down and how much data nodes could store before they became overloaded.
Another key point is that the current set of applications would need to be re-built to use the new protocol so one would need a rebuilt browser, e-mail system, etc. to use this protocol.
Finally there is security. I mentioned at the beginning there are some groups out there that believe DTN might be the solution to many of the security issues that plague the Internet today. From what I have read and seen, that was never the intent of DTN and it would fail at that goal. The intent was to create a reliable method of store-and-forward data communications.
I have not seen greater inherent security in this protocol than there was in the original Internet protocols (TCP/IP). Like TCP/IP, the intent of DTN is to provide a functional and reliable means of communication to further scientific endeavors.
DTN will probably succeed at its goal and if it is co-opted for other purposes and comes into wide public use, it will probably be subverted by a subset of the population, just like the original Internet protocols. In evaluating any technology, always beware the mythical silver bullet fix to all your problems.
Contact Lee LeClair, a founder and chief technology officer of Ephibian, through the company’s website www.ephibian.com or (520) 917-4747. Ephibian, headquartered at 3180 N. Swan Road, provides software development, data integration and Web design services. LeClair’s Tech Talk column appears the third week of each month in Inside Tucson Business.
Comments