Accessing program data from another computer
Author
I have a program running on a computer that needs to monitor and manipulate variables from another program on another machine. I have source code for both programs so the possibilities are just about limitless. Lets call the program that is going to manipulate and monitor the client, and the other the server for clarity purposes. The server has a lot of variables and these variables are updated very frequently (many times a second). The client will need to monitor all of them, but not all of them at the same time. It is too much information for the server to send all of the potentially monitored variables. The client does not even need to know the new value every time it changes. The client just needs to know when a variable or set of variables matches a particular criteria. Then the client needs to be informed and possibly take some kind of action.
My idea for this is:
1. Upon start up, the server will register all available variables using in a name/address pair. the name given to the variable and the address space of the variable.
2. After server startup, the client will submit a script to the server.
3. The script will request the address of the variables by name (this would be through an exposed function call in the server code).
4. The script would use the returned address to monitor the variable until the script's criteria is met (which could take anywhere from no time at all to months). Once met, it will inform the client.
Is there something out there like this? Can I get Lua or something similar to do this for me? Or is there another path I should be taking to do this?
You probably don't want to do it at that low of a level. Think of it more abstractly: the client sends a message saying "I want X to happen", and the server decodes the message, determines if the change is acceptable, makes updates, and possibly sends a message back to the client.
The general design of this sort of thing - when the client needs to be aware of messages from the server and respond to them - can get quite tricky. This so-called "message-passing architecture" doesn't behave like ordinary procedural programming, because all sorts of things happen asynchronously. Some experience with multithreaded programming is useful. :)
The client can't "monitor" memory on the server. What you do is, instead of having the server tell the client an address for the memory, have it wait until the change occurs and then tell the client "the change you requested has occurred".
The general design of this sort of thing - when the client needs to be aware of messages from the server and respond to them - can get quite tricky. This so-called "message-passing architecture" doesn't behave like ordinary procedural programming, because all sorts of things happen asynchronously. Some experience with multithreaded programming is useful. :)
The client can't "monitor" memory on the server. What you do is, instead of having the server tell the client an address for the memory, have it wait until the change occurs and then tell the client "the change you requested has occurred".
Author
Quote:Original post by Zahlman
The client can't "monitor" memory on the server. What you do is, instead of having the server tell the client an address for the memory, have it wait until the change occurs and then tell the client "the change you requested has occurred".
The client wouldn't monitor the memory directly. What I was referring to is that the client would send a script text that the server would then run in its own thread. The script running in the server's thread would actually monitor the variable.
I should mention that the type of variable I would monitor would change very quickly such as the number of wolves in a certain area, but the variable I would change through a client request, such as the reproduction rate of those wolves, would not change without a specific request.
So a possible scenario is that I would like a certain area to be overrun with wolves to create a problem in a certain area. To do that, I would change the reproduction rate of the wolves. Then when the number of wolves reaches a certain number, they would be sent to attack a nearby village. After which the reproduction rate of the wolves would go back to normal.
In this scenario, I would change the reproduction rate, monitor the wolf count, and then change the reproduction rate back when wolf count got high enough.
Well, this just described what real time distributed control systems are all about.
The frameworks that solve a million and one issue involved in such systems are the likes of J2EE, CORBA, ..., the real time ones use systems like SCADA or lesser known ones.
If real time control is used, then the tricky part becomes system feedback. Enterprise-grade systems usually do not deal with it, or simply fail when a resource is exhausted, or even cause a cascading failure. More reliable ones are data driven with either interlocks or other types of fail-safes built in.
It may seem like an exaggeration, but consider a two scripts which start responding one to one another. When there are enough wolves, one sends them to attack, wolves start dying. Other script sees wolves are dying and starts spawning more. Since there are enough wolves, they are sent attacking.... Then there are other problems to handle, such as one script failing to start up for whichever reason, leaving 5000 things just sitting there, for event that will never arrive. These scenarios are fairly common if not taken care of by the underlying system.
Business apps tend to use rule engines to handle this type of tasks, but they can afford high processing overhead.
Short answer - it is non-trivial problem, unless the system is designed within very rigid constraints, something which is undesirable due to high upfront cost of planning.
A simpler and more accessible way to implement this is to expose the data through RESTful API.
Control can be implemented in similar way.
But above all - limit the rate of queries clients can make. Either unique per IP, by caching the results, and by returning 403/408/410/5xx codes as appropriate.
And obviously - HTTP and web browser are used primarily - it saves you writing dedicated client application.
The advantage of this approach, despite original problem not being entirely webapp-like, is that REST exposes a fairly standard interface, allows for liberal caching, and due to polling nature can be fairly well-controlled from client-side. It does not however pretend to be real time control, so the rates at which data is handled should be measured in seconds or minutes. This minimizes the impact on actual servers.
The frameworks that solve a million and one issue involved in such systems are the likes of J2EE, CORBA, ..., the real time ones use systems like SCADA or lesser known ones.
If real time control is used, then the tricky part becomes system feedback. Enterprise-grade systems usually do not deal with it, or simply fail when a resource is exhausted, or even cause a cascading failure. More reliable ones are data driven with either interlocks or other types of fail-safes built in.
It may seem like an exaggeration, but consider a two scripts which start responding one to one another. When there are enough wolves, one sends them to attack, wolves start dying. Other script sees wolves are dying and starts spawning more. Since there are enough wolves, they are sent attacking.... Then there are other problems to handle, such as one script failing to start up for whichever reason, leaving 5000 things just sitting there, for event that will never arrive. These scenarios are fairly common if not taken care of by the underlying system.
Business apps tend to use rule engines to handle this type of tasks, but they can afford high processing overhead.
Short answer - it is non-trivial problem, unless the system is designed within very rigid constraints, something which is undesirable due to high upfront cost of planning.
A simpler and more accessible way to implement this is to expose the data through RESTful API.
instance1/zone17/mobs?type="wolf"Control can be implemented in similar way.
instance1/zone17/spawn20?command="suspend"But above all - limit the rate of queries clients can make. Either unique per IP, by caching the results, and by returning 403/408/410/5xx codes as appropriate.
And obviously - HTTP and web browser are used primarily - it saves you writing dedicated client application.
The advantage of this approach, despite original problem not being entirely webapp-like, is that REST exposes a fairly standard interface, allows for liberal caching, and due to polling nature can be fairly well-controlled from client-side. It does not however pretend to be real time control, so the rates at which data is handled should be measured in seconds or minutes. This minimizes the impact on actual servers.
Author
I am not sure if REST will provide the frequency that I require or give me the flexibility I need. For instance, my criteria might be based on a combination of several variables. I don't know that polling over a network connection would provide the data real time enough, but I will definitely look into it more.
Another option I thought of was to just create a function in my server code that would allow Lua access to variables by name.
I am not too worried about conflicting scripts as mentioned in your example because there will only be one client. Basically, the client is a workflow engine and the server is a game server. My situation hopefully will not require a full enterprise level solution.
Edit: the other problem is that to use REST I would have to host my program in a web server which definitely causes problems for me. I don't think REST will work for me.
[Edited by - landagen on February 22, 2010 4:06:54 PM]
Another option I thought of was to just create a function in my server code that would allow Lua access to variables by name.
I am not too worried about conflicting scripts as mentioned in your example because there will only be one client. Basically, the client is a workflow engine and the server is a game server. My situation hopefully will not require a full enterprise level solution.
Edit: the other problem is that to use REST I would have to host my program in a web server which definitely causes problems for me. I don't think REST will work for me.
[Edited by - landagen on February 22, 2010 4:06:54 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
