Communicating Even When the Network Is Down

coondoggie writes to mention a NetworkWorld article covering efforts to maintain network connectivity even when the network has holes. Building off of the needs of the military, the end goal is to create a service which will route around network trouble spots and maintain connectivity for users. From the article: "Researchers at BBN Technologies, of Cambridge, Mass., have begun the second phase of a DTN project, funded by $8.7 million from the Department of Defense's Defense Advanced Research Projects Agency (DARPA). Earlier this year, the researchers simulated a 20-node DTN. With each link available just 20% of the time, the network was able to deliver 100% of the packets transmitted." The article is on five small pages, with no option to see a linkable, printable version.

So can SMTP.

[khasim]

The spec provides for "intermediate" servers receiving the message and passing it on.

Years ago this was duplicated with the old BBS's and phone lines. I'm talking about the single user at a time boards. One phone line. Lots of waiting.

The boards had the numbers of different boards that they would call as the lines were free (their's and the recipient's). Messages would be passed along whatever route was available until they were received at the destination.

This model is heavily dependent upon storage, though. If one of the nodes loses its hard drive, the messages stored there were lost. You can have unreliable connections, but you cannot have unreliable storage.

Also, think "routing loops". The tail of the messages gets really long in some of these schemes. You don't want the message routing back over connections it has already traversed, do you?

Which leaves the possibility of the "route to nowhere". Where messages go to die.

Re:Wait a minute...

[jmorris42]

> Wasn't that the point of the original ARPANET? To route around broken parts of the network? BBN was involved
> in that, too. What, have they been double-billing the DoD this whole time?

Not really, the Internet assumes nodes can change but there is an end to end link possible, if not instantly within a couple of seconds of reconfiguring or outage. This is more like reinventing packet radio or meteor scatter. Mebe they should go talk to some old hams to get some ideas instead of spending millions to reinvent the wheel.

I'm remembering old QST articles where it was a cool thing that they could pass a message via packet radio all the way up the coast of CA most days.

Roger That, what?

[SuperStretchy]

Yes, SMTP is an amazingly strong example of redundancy. However, we installed redundant fiber at a school I work for within a few days, and just for fun we'd pull plugs randomly and monitor the response time while a alternate link was used. I think 10ms was about average... Then it stopped being fun after a while. We even tested load balancing.

So my question is.. why are we treating this like its a new thing? This seems like another one of the frequent quasi-ads which seem to be more common lately here on /.

This is day 1 stuff, ppl.

[WillyPete]

Welcome to networking 101. The trouble with a fully meshed, multi-vendor layout is the cost, and few companies are willing to pony up the required loot to maintain a completely redundant network.

Re:wow, a press release from 1983!

[Anonymous Coward]

Well, actually a lot of the oldies didn't rely on end-to-end communication.. IP, X25, and probably proprietary LAN protocols didn't.. but Decnet, some IBM mainframe messaging deal I forget the name of, Fidonet, UUCP, all forwarded data without end-to-end communication. You could get file transfer, E-Mail, and with someting fancy like IBM's deal, remote program execution with you getting the results back, and a super-laggy telnet thing apparently.. (well, to avoid 5-hour lag you'd want end-to-end communication for that..)

          When I saw the short description, that was what caught me, "Oh, snap they're reinventing Fidonet". But, based on the article description, getting DNS, cache, etc. to store and forward requests.. well, that's pretty trick to get this to work for standard web browsing. Store-and-forward proxies I guess.. it'll be interesting to see how good the speed gets on this.