An idea I just had to get out there before it dies
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. 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? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
Real programmers use butterflies
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.
Robust Services Core | Software Techniques for Lemmings | Articles
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. 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? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
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.
Latest Articles:
Proxy class for TypeScript/Intellisense DOM manipulation -
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.
Latest Articles:
Proxy class for TypeScript/Intellisense DOM manipulationMarc 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. ;P
Real programmers use butterflies
-
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.
Robust Services Core | Software Techniques for Lemmings | Articles
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
-
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).
Robust Services Core | Software Techniques for Lemmings | Articles
-
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).
Robust Services Core | Software Techniques for Lemmings | Articles
That reminds me of a plum creek project i consulted on. huge.
Real programmers use butterflies
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. 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? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
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 :suss: 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.
-
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 :suss: 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
-
Quote:
There are two problems with this - complexity security and security.
FTFY
- I would love to change the world, but they won’t give me the source code.
You beat me to it ;)
cheers Chris Maunder
-
: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!
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. 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? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
Real programmers use butterflies
Sounds like you want Erlang.
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. 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? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
Real programmers use butterflies
I think it is great idea, because... I have also thought of it :-D 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 ()
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. 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? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
Real programmers use butterflies
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
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. 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? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
Real programmers use butterflies
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". :sigh: :doh:
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. 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? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
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.
Like what? *crickets* Oh. Right.
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. 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? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
Real programmers use butterflies
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).
I live in Oregon, and I'm an engineer.
-
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).
I live in Oregon, and I'm an engineer.
patbob wrote:
One that's missing off your list, is who pays for the hardware and electricity to run your VM?
I think your thinking of something like the JVM or CLI, not something like a Pike VM, which is a microvm that accepts a very limited instruction set suited for it's particular purpose, not general programming. Because the instructions are geared for what the service does, how much extra overhead the VM causes really depends on how crappy you designed your instruction set. It's a special purpose, not general purpose VM, and being dedicated, the inefficiency on introducing one is reduced considerably. Of course, it wouldn't be appropriate to use such a technology in all places.
Real programmers use butterflies
-
Message passing allows you to send something to another thread or perhaps process or machine(s), to be processed on the remote end. 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? Doing that would allow your service to be extensible by its clients. As the clients upgrade their capabilities the server follows suit, sometimes without changing it at all. There are two problems with this - complexity and security. There is a solution to both - something like a Pike VM like this Regex as a Tiny "Threaded" Virtual Machine[^] Except with more than 7 or so instructions. It could be built up to be mini VM that understands say 20 different bytecode instructions. If you find that's eating up bandwidth add more instructions that do more complicated things, making them "chunkier", until the VM is mature. Once it gets there you can do like I said with the extensible service. This is either the dumbest idea I've had in the past two weeks to the best. I'm still not sure. Maybe coffee will clear it up. :-D
Real programmers use butterflies
Sounds great. You can do the debugging!
-
patbob wrote:
One that's missing off your list, is who pays for the hardware and electricity to run your VM?
I think your thinking of something like the JVM or CLI, not something like a Pike VM, which is a microvm that accepts a very limited instruction set suited for it's particular purpose, not general programming. Because the instructions are geared for what the service does, how much extra overhead the VM causes really depends on how crappy you designed your instruction set. It's a special purpose, not general purpose VM, and being dedicated, the inefficiency on introducing one is reduced considerably. Of course, it wouldn't be appropriate to use such a technology in all places.
Real programmers use butterflies
Doesn't matter what the code is, or what it runs on, there's still a hardware cost (physical electronic circuitry) and electricity cost to running code. You simply cannot escape thermodynamics.
I live in Oregon, and I'm an engineer.
