(Page 2 of 2)
Last year, a group of researchers built a different programming framework, known as Haggle, for pocket-switched networks. The Haggle library adds collections of code to support manipulating data on pocket-switched networks using a variety of platforms, including Windows and Windows Mobile, Mac OS X and iPhone, Google's Android, and Linux.
The difference between Haggle and D3N is whether the intelligence--the knowledge of how to interact with pocket-switched networks--is inherent to the language or in a separate code library. D3N builds knowledge about the way pocket-switched networks work into the programming language. This makes programming for pocket-switched networks simpler. Programs written in D3N can, for example, grab data from the network with a simple command. Developers working with Haggle can still grab that data, but the programming is more complicated.
D3N code can also be tested more easily, an important feature if service providers are to be convinced to allow the programs on their phones. "[Mobile providers] want to make sure that the software that gets put on their phones is very, very reliable," Crowcroft says.
"So you need some alternative" to ease the creation of applications for pocket-switched networks, says Intel's Fall. "We have done it with [the Haggle] programming interface. They have taken it further and have written a language for development."
The embryonic D3N language, and pocket-switched networks in general, still have unaddressed issues. For example, one ill-studied topic is security on pocket-switched networks. Passing data from phone to phone could ease the spread of malicious software. In addition, attackers could flood the network with digital pollution such as spam.
"Pollution in a peer-to-peer system is a really hard problem [to solve]," Crowcroft says. "I hope it is not a deal breaker."
Getting people to actually use pocket-switched networks could also be a problem, as both wireless connectivity and Bluetooth drain power. Passing along data for other users could dramatically shorten battery life. The research group is working on a hybrid communications model that uses low-power Bluetooth to search for interesting data among the network nodes and then uses the more power-intensive wireless networking system built into the phone to transfer the data.
"We don't care what type of radio forwards the data," Crowcroft says. "Battery life is going to be a far more important aspect of this."
If the problems are solved, and cell-phone makers convinced that such additional functionality is useful and secure, such networks could give users an alternative high-bandwidth way to communicate.
The Open Network Foundation wants to let programmers take control of computer networks.
Backpacks that detect nuclear material form a wireless mesh network.
Ad-hoc wireless networks may soon tell emergency workers how to deploy transmitters.
When a plane ditches in the Hudson or the Jonas Bros announce a new concert tour, communications spike and capacity is exceeded. Peer means equal. Some groups and organizations are more equal than others.
Good design, not new programming languages is the solution
At first I thought "new language" meant a protocol for grid routing. But here it's a new programming language. I read the D3N paper-- it's a new language layer written on top of F# written on top of .NET. The prior project, Haggle, was OS independent with a C/C++ interface (deemed a bad thing). But successful communication needs standard protocols across all devices, and a compact, simple reference implementation with test suite is the way to achieve this. The Internet TCP/IP and HTTP exist because of simple (open-source) reference implementations available, written in C.
I have to object to the concept that a programming language makes a huge difference in programming design and implementation (at least for code widely used). The comments in the code are the most important part and should be a majority of the text. A clean well documented architectural design makes any extra syntax (e.g. procedure call vs operator keyword) of plain C insignificant.
What is most important is portability and compatibility, and there language does make a difference. In my opinion, there is nothing that comes close to plain C in ability to incorporate protocol layers into the microcomputers of phones, etc. A reference-app + new language + F# + .NET + MS-Only-OS is the opposite of what is needed. Besides, grid routing protocol code isn't all that hard, and really should be kept compact.
Sorry to be cynical, but I've been burned many times trying to get some app or development system to run. These days, "object oriented" means automatically suck in all kinds of self-documenting (a.k.a. poorly documented) code that in-turn sucks in more, to the point where it can't compile except with certain narrow versions of all the code and operating system. Trying to install on a 3 year old computer can be fruitless. You wouldn't even try to put something this on a $50 WRT54GL router, but people have put complex grid routing software on them.
I thought Don Knuth's "Literate Programming" was a major advance as it allows the documentation and design to be the main part of code, and produces simple C as an intermediate output. Too bad that didn't catch on.
Re: Good design, not new programming languages is the solution
I agree good design is always necessary. However, part of design is choice of tools, including programming language paradigm. This was Google's argument behind Mapreduce and Microsoft research's argument behind DryadLINQ.
Note Bene: we aren't religiously attached to basing D3N on F# - this was a prototype choice based in an earlier project decision to get a lot of Windows Mobile phones - indeed, all functional languages are largely equivalent and the switch to an open language like ML would be trivial.
For information, the underlying runtime Haggle project software also works on Android and iPhones (if jailbroken:) and would probably port to new Nokia linux phones (N900) easily. A Symbian OS port is deemed to be feasible, but not really a priority.
Many ML compilers target bytecode and porting this to a smart phone would be very easy (indeed F# and OCaml share this, but F# does depend on common runtime, which we'd rather not depend on for the reasons you allude to!)
But yes, there's no substitute, ever, for good design.
What I never understood is why cell phone providers could not use the the massive locational data from their clients to furnish city planers and service like google traffic hugely accurate real time info on said traffic patterns. One could use such data from these ad hoc networks to pinpoint abrupt changes in drivers speed ahead of oneself: ie a cop with a radar gun ;)
Manufacturing in the United States is in trouble. That's bad news not just for the country's economy but for the future of innovation.
Our list of the 50 most innovative companies, including the following:
On Twitter
Become a Fan on Facebook
Subscribe to the Feed
flyingmonster
29 Comments
battery life
By default the phones could only pass along data for other users when plugged into an external power source with a user setting allowing a user to change this. Another option is that these phones could be designed to do it for only a random minute or two an hour. The phones could also drop out of relaying data when they register battery power less than a certain amount.
Reply