taking remote control through a socket

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Post Reply
adventuresofgreg
Posts: 349
Joined: Tue Oct 28, 2008 1:23 am
Contact:

taking remote control through a socket

Post by adventuresofgreg » Wed Jan 18, 2017 3:35 pm

Is this even possible, or would it fall under the script limitations?

I want to make a socket connection between 2 different stacks, and I want to send LC commands from one stack to the other - basically take remote control of the second stack.

The following example using VALUE() does not work:

Sending stack message: "set the hilite of button "A" to true"

Receiving stack script:

on newMessage theMessage
value (themessage)
read from socket theIP until return with message "newMessage"
end newMessage

Klaus
Posts: 14208
Joined: Sat Apr 08, 2006 8:41 am
Contact:

Re: taking remote control through a socket

Post by Klaus » Wed Jan 18, 2017 3:38 pm

Hi Greg,

not sure, but sounds like a job for DO (best in a TRY statement!):

Code: Select all

on newMessage theMessage
  try
    do theMessage
  end try
  read from socket theIP until return with message "newMessage"
end newMessage
Best

Klaus

adventuresofgreg
Posts: 349
Joined: Tue Oct 28, 2008 1:23 am
Contact:

Re: taking remote control through a socket

Post by adventuresofgreg » Wed Jan 18, 2017 3:49 pm

Thanks Klaus - That was actually quite easy "Call theMessage"

Klaus
Posts: 14208
Joined: Sat Apr 08, 2006 8:41 am
Contact:

Re: taking remote control through a socket

Post by Klaus » Wed Jan 18, 2017 4:56 pm

CALL? :shock:

I would never have thought of that according to its description in the dictionary!

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10057
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Re: taking remote control through a socket

Post by FourthWorld » Wed Jan 18, 2017 6:02 pm

If this is for use only on your local machine, what's been described will work but may not be needed, given how much more easily stacks can communicate when running within the same process.

If this is for use on a LAN, you'll want to be careful to check connecting IP ranges to restrict access in the event that network changes may expose the app to the Internet.

If this is for use across the Internet, you'll want to be VERY careful about how instructions are sent, and how they're validated. DO NOT USE "value", "do", dispatch" or other such calls to handle arbitrary commands coming across the Internet. LiveCode is a powerful language, and allowing arbitrary code execution can be profoundly dangerous.

What is this app for? I'm sure we can help craft a messaging architecture that meets those needs, and safely.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

adventuresofgreg
Posts: 349
Joined: Tue Oct 28, 2008 1:23 am
Contact:

Re: taking remote control through a socket

Post by adventuresofgreg » Sat Jan 21, 2017 3:09 pm

Thank Richard:

I have a standalone running on a Linux VM + LC server also running on the VM. I need to communicate between LC server and my standalone. In tests, I can make a socket connection between 2 standalones running on the same local machine to grab data and take remote control, but I have been unable to establish a socket connection between lc server and my standalone on the VM.

So instead, I have the LC server export an "instructions" text file and then have the standalone pole the file for changes. When there are changes, the standalone opens the file and fires off the commands, then exports a "return" text file which is parsed by the LC server and data is sent back to the requesting web browser. I imagine that I will encounter script limitations doing it this way... unless I limit commands to 10 lines of code which may be possible.

This text file method of communicating works, but it's not as elegant as a socket connection. But, could be more secure. Any advice/comments/input is welcome!

Cheers,
Greg

Post Reply