PARC's New Networking Architecture

Sandeep writes " PARC announces a new software architecture , named Obje, to establish a device-independent networking system. Essentially, it allows two devices to teach each other how to talk amongst themselves. It does this by sending actual code over the network."

Comments

Whats wrong with generated code?

[SkunkPussy]

There is nothing wrong with generated code if you trust the sender. Plus if the code sent over the network is executed in a sandbox/jvm it shouldnt be incredibly risky (obviously a lot of potential for DoS attacks).

Code can be a very concise way to express an algorithm.

Re:Only two possible outcomes.

[Dachannien]

About 34 years too late.

DMCA and other viruses

[buckhead_buddy]

The propogation of code is worrisome, but I'm also unsure of the legal implications of allowing your code to accept the code and restrictions of others by automatically allowing it to run.

This may be a neat new way to logically propogate code, but once all the kinks are worked out it seems like it simply opens new doors for lawyers to battle out THEIR logic.

Brrrr

Sounds safe to me - pwned

[orthogonal]

It does this by sending actual code over the network.

Nothin' to worry about here!

I "can'tse" any way this could develop into a security hole bigger than the goatse guy's famous anus.

This reverses years of tradition -- Microsoft is supposed to steal its "innovations" from from PARC, not the other way around.

And doesn't this sound like what goes way too wrong in Vernor Vinge's A Fire Upon the Deep, or an Iain Banks novel?

Could be horribly insecure

[moberry]

Almost everyone knows that if it can be protected, it can be cracked. There could be horrible implications to this, just imagine sending actual code across a network. It will take some "1337" hacker just a couple of hours to crack the system wide open. And if he/she can send raw code to tell the network how its going to work, and tell the devices connected to it how they work. he/she could essentially control them a lot easier than todays more "traditional" methods.

Parc = Real PnP

[SunCrushr]

So from what I've read in the article, this looks to be Plug'n'play as it was meant to be:
Devices which use simple initial aggreed upon standard to extend their various servcies to each other without all the protocols having to be aggreed upon ahead of time, just a few simple initial protocols which are used to communicate and extend the other protocols and services between the devices. If this is applied correctly by the industry, it could change computing a lot, opening more complex systems to users with less experience and requiring less support resources. I'll be watching this closely.

Re:Parc = Real PnP

[silas_moeckel]

I'ts been tried to an extent. USB and BlueTooth were supposed to work by providing a few standard interfaces making drivers standard. It seems to work somewhat. Windows has some very broken USB handaling try getting a serial dongle to work and you will find it asks for a disk often enough that disk most often contains the same dll as the system allready had for serial over USB, pretty much so it can say belkin usb to serial cable rather than generic usb to serial cable. IDE seems to be the only reliable usb driver.

Bluetooth has similar issues with things like headsets there are multiple possible drivers and one each end and no automated facility to match up the best capability profile that will work.

This would seem to be going to the way of i2o where you made a framework of half drivers the OS side that just had to get to i2o's middle ground and the card would provide the rest. With this you loosing some performance because you have arbitrary limits by the i2o framework.

I think the big stumbling block is going to be added cost it takes memory to store the driver. People want there devices cheap it would seem a better idea to fix bluetooth and usb as they are nearly there. Realy it's just a question of making devices pick the best match via a autonegotiation.

Re:First thoughts...

[Wingchild]

... what article were you reading? The article doesn't talk at *all* about letting devices communicate independantly and learn to talk to each other.

It provides a `standard` that `allows` such communications to, in theory, take place. It does it by removing some of the intelligence apps currently have to have in order to talk, so long as you adhere to the standard. But it's not like they're inventing new protocols here.

If TCP/IP is a vast highway to transfer information, Obje is a new kind of tire.

Re:Parent should be "Insightful," not "Funny"

[Short Circuit]

Perl supports "tainting" of data, so you don't do accidentally anything stupid with information that isn't secure. (Including exec'ing it.)

I imagine this would be a similar set up.

Or it could be done inside a virtual machine ala JVM, with a stream output to the part of the device that actually uses whatever the communication is intended to transmit in the end.

Re:Parent should be "Insightful," not "Funny"

[jilles]

With Java you can do this. Just run the code in a sandbox. Alternatively you can use some trusted third party and signatures. Or you can do both (authenticate other party and allow verified and validated code to do whatever it is authorized to do). The JINI architecture works along these lines (although it seems rather dead nowadays). It can be very secure if you set it up properly.

*ALARM BELLS*, but this IS PARC

[ItsIllak]

OK, I read the headline and could practically see the red lights circling into view and hear the alarm bells ringing. It's a really really obvious way of making life even more difficult!

However, I do have to remember that this is PARC we're talking about. They've got a pretty good track record of innovation. At very least I think they should be given a bit of rope. Hopefully they won't hang themselves with it!

Of course, I find it hard to see how this simplifies or improves computing and networking in any way, and it rips SO hard through the OSI models that it could be pretty damaging in that respect too.

Re:How to use it?

[standard method]

Oh, I know what you mean, I had kind of a similar thought when I read the end of the article, but my point remains the same. For understanding the idea, it's great for "the community" to get a hold of the code, but that's ignoring the fact that this is a company, and a company that researches for a living. (Keep in mind this post isn't designed to shoot you down or anything, more of a clarification of my own points.) These people do research on stuff exactly like this, and the reason that this story was actually notable was because this is at least semi-revolutionary. It's something noteworthy, because time/money/effort was put into this project, and none of those things are free. Particularly not the middle quotient.

1: Research
2: Open Source your results
3: No profit!

Of course, profit is evil, because it represents the minimization of freedom, money is bad, etc etc.. But I would think that not making any money on things like this, or at the very least not breaking even, would kind of hamper future developments. Yes, there are research grants, etc, but are they enough?

And, the possibility that I am in fact quite wrong is very likely. So. I've just showed you!

... Yeah.

Finally, a use for Java.

[torpor]

Seems to me a mini-JVM would be good for this application, sitting in between the transport layer and the application.

Actually, come to think of it, why hasn't this been thought of before?! SO OBVIOUS!!

Ah well. I'm now happy that after all this time, I've finally come to understand that in fact there is a use for Java after all...

(j/k, don't slay me!)

Re:Parent should be "Insightful," not "Funny"

[BlueTooth]

and then the sytem decides what you are based on your capabilities and treats you accordingly.

This assumes that the system already knows about all possible capabilities and that it knows how to talk to everyone else.

I think the idea is that devices teach each other of their existence. It would be like if I bought a USB device (say a camera) that Windows didn't support, the camera would be able to bootstrap Windows with some drivers from its own firmware. The only thing that has to be prearanged is a protocol for this transaction. I don't need to maintain an extensive driver library for this to work.

Re:Sun already tried this

[NSash]

This sounds like what Sun tried to do with Jini. Judging buy the success (or lack there of) of Jini, I don't believe this will be successful.

On the contrary, a sign of a great idea is that even if the market doesn't accept it at first, it keeps on returning until its time has come.

Re:Why even have a network?

[truthsearch]

If code is instruction for a computer, why not send instruction over the network? As opposed to pure data ("Here's a packet of info"), it makes sense to send "I'm here and I'm a device of type X. When Y happens, send me Z." If the code is limited in its abilities, and isn't just run arbitrarily, the network itself can contain much logic. Devices could then use the network is much more logical and efficient ways.

Re:Parent should be "Insightful," not "Funny"

[goatwhip]

What portion of detecting whether code sent to you over the network is doing something 'strange', do you find simple? I hate it when people preface comments with "Simply enough" or "Obviously". It automatically makes anyone who doesn't understand what the person is talking about, feel stupid.

Platform independent embedded device driver?

[ahg]

It seems like this offers a way of embedding the device's driver. - Just having the driver doesn't bypass any other security mechanisms already in place. Depending upon how it's used, it may not open any new security holes. Being able to just plugin the latest printer and have it work without installing any drivers is not a Bad Thing.

If Microsoft had "innovated" this we'ld be seeing printers being distributed with Windows binaries drivers in firmware, that only Windows machines could make use of. Coming from Parc, it will be available for multiple platforms but unfortuantely they're not making this an open standard.

<Paranoid Speculation>: Microsoft will copy the idea, but their standard will only communicate with Windows (and it's mobile derivatives) and give it away to hardware vendors. Free stuff from MS that will make your device truly PnP for 95% of computer users is an eash choice.</Paranoid Speculation>

Active Networks - deja vu all over again

[decoy999]

More power to the network !!! Wunderbar ! What the active networks community has been trying to solicit for all these (well, not all that many) years.

Of course most fashionably cynical geeks obviously have strong opinions about "new" technologies (e.g. MDA etc. etc.) because they know everything that there is to know ... right ?

I once read an article in Spectrum or something about degrees of ignorance (about not knowing something, or not even knowing that one doesn't even know and stuff) well all these meta-models are a little difficult to digest if you've spent the last 40 of the 50 or so yeas of the computer age reinventing and relabeling technologies over and over again and patting each other on the back.

Dammit, GUIs (ala windowing intfcs) haven't changed in 40 years, basic networking hasn't changed in 30 years ... simply because un-insightful programmers heavily dependent on psuedo-geeky-techno-jargon-crap feeding idiots hype up brain dead hacks as "bleeding edge technology" (ever notice how happy we feel relabeling or re-"inventing" design patterns ?)

So of course, the lesser mortals who compare malicious viruses to mobile code, obviously don't appreciate the nuances of responsible meta-models. I think PARC has a good thing going. I wish them luck...hopefully Steve Jobs and/or Bill Gates will productize this one too :-) ... and shame on you non-abstract thinking pseudo-geeks ...

Re:Sun already tried this

[deanj]

Cisco uses Jini for some of it's products/projects (notably, Spanish Inquistion), as do other companies.

Re:Parent should be "Insightful," not "Funny"

[JohnnyCannuk]

Uhm, try going here and see how "dead" Jini is...

'Cuz it's not. Not even close

Re:Sounds Like Sun's JINI

[Anonymous Coward]

I think you're being a bit generous to them - it sounds like they're willfully misrepresenting JINI.

I think they'll suffer from the same "a priori knowledge" problem that JINI does - sure you can find a service (even one of a type you didn't know about when you were compiled) and get a little program that lets you interact with that service (talk to it, call its functions, turn parts of it on or off, etc) but the trick is to know what that stuff _means_ (I think the AI boys would say "lacks a shared ontology" or something). It's very hard to meaningfully call a method when you've got no idea what the method does.

In a few cases you can show the received information in some kind of "service browser" or some other UI, and let a person (who hopefully does share an ontology with the program's author) figure out what to do. In circumstances where that's not appropriate, you end up having to overlay some system of understanding (like a "printer" definition) so that programs can do something meaningful with it.

This is one serious place where the common practice in Open Standards has been a consistent let-down - everyone is shy about stomping around defining stuff, instead leaving it to some standards body (which often doesn't exist, doesn't understand, or just doesn't care). Microsoft, on the other hand, are perfectly happy to define the requisite schemas, ontologies, and taxonomies, and impose them on everyone else - and the device/network manufacturers go along with this because they want anything that works.

Beyond Contact

[Hythlodaeus]

This sounds a lot like the main idea in the book "Beyond Contact" - rather than try to send aliens little pictures coded in radio (like a lot of reverse-SETI ideas) send them a description of a VM followed by lots of little programs.

Solves a GPL problem

[Smallpond]

One thing this could solve would be keeping the details of the driver for a new device closed-source. That way a manufacturer could supply hardware and a built-in driver for use in Linux without having to open up the architecture to their competition.

This assumes that its not trivial to extract the details from the Obje code, of course.

Re:the same ideas, over and over and over again

[JohnnyCannuk]

Ohh, touchy.

Well, I never claimed that Sun "invented" mobile code with Jini, just that the ideas espoused by Obje have been done before and are currently available for anyone to download from www.jini.org .

So, seriously, what other past implementations of this have there been? I am really curious.

As for your cracks about the real problem being a Java-based implementation, I will take it you are one of those "if it ain't GPL it ain't free" zealots. So please, provide links to the C++ version of a Jini-like framework. Or the Ruby version. Or the Python. Or C. Anything as long as it is OSS certified. While your at it, point me to the one that has the default sand-box for running the mobile code, making it more secure - other than a Java implementation.

My idea of giving "props" was because the referenced article mentions that "Obje can be built on top of mobile-code frameworks like Jini"...and Jini has historically been "ignored" even within Sun.

Or did you not bother with the formality of actually reading the article?

Hmmm?

And if Jini and Obje address different problems, perhaps you can enlighten me just what problems they each address that is so different, 'cuz it looks pretty identical to this Jini programer.