|
It seems to me you are describing a stripped down version of sending something like java code somewhere to be executed on a virtual machine. To me, this raises the question of why bother stripping it down?
In other words, it seems like a bit of a twist on the HTML browser-server model.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I guess it kind of is. After i wrote the post i thought about javascript, and extending a Javascript machine to run on the server, but i think other commenters have talked me down from the edge of this particular cliff.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: Usually, you have a fixed number of "messages" that the other side understands, but what if you could send code in the stream, even across process or network?
The first thought that crossed my mind when I read this was "ActiveX".
I'll leave it at that.
|
|
|
|
|
:shudder:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Sorry. If I've suffered through that, others should too... 
|
|
|
|
|
To be fair they didn't use a VM but i hear you.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: Usually, you have a fixed number of "messages" that the other side understands, but what if you could send code in the stream, even across process or network?
In the Human world, this is known as "education", or "training". You are suggesting that we give the client computers an ability to "learn" - a non-trivial task.
At minimum, you would need a "compiler" on the client, with capabilities known to the server. the client would, at minimum, have to understand a "message definition" message which defines both the message format and the code to be executed when the message is sent.
If you wish an adaptive system, i.e. one that improves as the capabilities of the client are upgraded, you will need a "send capabilities" message which would allow the client to communicate its capabilities to the server. If you want to get really fancy, you could have the client use a "message definition" message as well, which would allow it to educate the server about unexpected capabilities that it has developed.
I'm unsure if that way lies madness or genius. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: At minimum, you would need a "compiler" on the client, with capabilities known to the server. the client would, at minimum, have to understand a "message definition" message which defines both the message format and the code to be executed when the message is sent.
Yes.
Also I wasn't talking about making it learn so much as giving the client software the ability to send remedial software to the server that it could run to perform a task - which instructions are available would be specific to whatever the server does.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: which instructions are available would be specific to whatever the server does.
That is still learning. Humans may be hard-wired to learn language (the "message definition" message), but no human language is universal; every language has some things that cannot be said in it.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Except the instructions are fixed. It could be adapted into a learning system.
Real programmers use butterflies
|
|
|
|
|
Like what?
*crickets*
Oh. Right.
|
|
|
|
|
I worked on a product that did this. The primary server downloaded code to access servers at run time, on a per-session basis. It took the form of opcodes in an interpreted language, running on a virtual stack machine. The access servers were also preloaded with "scripts" that the downloaded code could invoke, which reduced its size. This was an embedded system, so security wasn't an issue. It wasn't too complex, but a detailed spec didn't have to be written: it was proprietary, so however the access devices worked was the de facto spec. New access devices had to be backward compatible, which sometimes meant replicating the idiosyncrasies of the original access devices with regard to how the language was interpreted. All of this generally worked well, but you can add backward compatibility as a third problem if trying to do this for more complicated applications.
|
|
|
|
|
That's interesting. I like embedded stuff, and certainly that can either disappear security issues, or it can make them much worse.
I'm remembering the radiation dosing machine decades ago that was multithreaded and overdosed and killed 3 people because of a race condition. At least if I remember the story correctly. It was taught to me as a lesson about multithreaded code.
So I guess it depends on what it controls.
Real programmers use butterflies
|
|
|
|
|
This was a very large embedded system, a telecom call server with tens of millions of lines of code if you added up all the product lines that used the same platform (and that could theoretically be built into one distributable).
|
|
|
|
|
That reminds me of a plum creek project i consulted on. huge.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: but what if you could send *code* in the stream, even across process or network?
I did a test case of that using Docker and Python, including the ability to do some basic UI layout, etc. I really liked the idea and it worked well - spin up a Docker instance, run the code, and after a period of inactivity or when the user logs out, kill the Docker instance. Given that one is working in essentially a VM, the only thing one has access to is one's own Linux instance, so I wasn't too concerned with security, haha. For example, you could, in Python, list the contents of the OS folders, etc., but I didn't really care.
The impetus for this are those sites that let you run C# code snippets, and I was curious how they might do such a thing, especially given the security issues.
|
|
|
|
|
Marc Clifton wrote: especially given the security issues.
There's always the possibility they're relying on .NET's Code Access Security feature to do the heavy lifting.
It works pretty well. I could probably find out if I tinkered with the C# code enough to see what it let you do and what it didn't but it's work.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: but what if you could send *code* in the stream, even across process or network?
Silverlight?
Dunno. Maybe you could call it Flash?
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I wasn't thinking anything quite that ambitious. Mostly the instructions would be service specific. A graphics rendering server for example, would have instructions to create new filters and such but they all deal in polygons, pixels and math. A DSP application might accept instructions to do FFTs or other operations to transform a stream. That sort of thing.
Real programmers use butterflies
|
|
|
|
|
Sounds like you want Erlang.
|
|
|
|
|
I think it is great idea, because... I have also thought of it 
I don think it is useful for replacing message passing in general, but in specific cases where you don't know beforehand what types (e.g. structure and contents) of messages you will need.
An example is debugging, where you would need to query the state of the program and optionally change the value of some variables. Its probably easier to write a small program for the debugging actions you need, than to add support for all of the possible messages you think you might need in the future. Security wise, they are both risky, though.
Another example is to use the replace communication protocols. Instead of adapting an existing protocol to your needs, or worse creating your own, you can use the VM to implement a domain specific language (DSL) suitable for your needs. So instead of "byte zero is the header, byte two is type of message, bytes 2 to 10 are optional and if present ...." you could simply have "write this octet string to memory address X, set variable Z to 42, restart thread W".
I think SQL is a good example of what it could become of passing programs instead of messages. SQL has made it very easy to interact with databases, no matter the underlying implementation. But there also security dangers in using it (<obligatory "boby="" drop="" tables;"="" reference="">)
|
|
|
|
|
Just few quick thoughts:
distributed systems like kubernetes and service fabric already implement rolling updates, i.e. update application components while the application is running (included is also rollback/failover strategy if things go wrong)
if you want to make your own distributed functionality upgrade on the run you might send a "reference" to the new functionality instead of the actual code instructions. You could add some kind of "authorized store" containing validated code. The message receiver gets a reference to the function to use to process that message, if not already available locally it downloads it from the store (only from the authorized one). This way you could mitigate security risk and avoid to implement a complicated code validation strategy at instruction level.
Again these are quick thoughts, I didn't spend much time to validate my ideas but maybe they can be useful to you... I guess that's the spirit of this forum
|
|
|
|
|
Congratulations. You just invented (the worst bits of) Windows 10. 
You know, the server sends messages to the client, that include new "capabilities" and "instructions". The only capabilities that can't be changed are the capacity for the server to totally screw up the client, and for the client to stick its fingers in its ears and reject the "messages".  
|
|
|
|
|
In a way that is what SQL does.
|
|
|
|
|
Sorry to rain on your idea, but it's called grid computing, and has been around for at least 30 years now. Use of a VM is a tweak to the idea, but doesn't address all of the concerns. One that's missing off your list, is who pays for the hardware and electricity to run your VM?
Most people want some benefit to themselves for letting you use their hardware. Doesn't mean it's impossible, for example people donate their resources to things like SETI and protein folding. However, when they get nothing from it, they don't like it (e.g. the bitcoin mining browser exploits).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
