I need a real-world example for network actors

[AristosQueue (NI)]

The biggest request I get for the Actor Framework these days is, "I want to launch actors on different machines and communicate with them."

So, I've been doing my homework studying general network technologies and strategies. I'm now interested in someone laying out for me a real-world use case for "Actor A is going to start Actor B, but wants to put Actor B on a remote machine." There are too many options for initialization, error handling, and shutdown when dealing with networks to design a one-size-fits-all networking mechanism, so I need to know what people's use cases are.

I'll start with the one I have in mind, and when you post yours, please follow suit as far as formatting as it'll make it easier for me to compare and contrast different submissions later.

===========================================

Goal: A distributed programming project like SETI At Home or GalaxyZoo

Details: I have a large data set that I want to get people's help analyzing. I have a main application actor that manages the database and spins up user actors as needed. The user actors receive messages from my application asking them to evaluate a given data set. The user actors do whatever is necessary to evaluate that data set -- maybe purely functional, as in the case of SETI At Home, or perhaps needing user interaction, as in the case of GalaxyZoo. As it works, the user actor may need to pass periodic updates back to the application actor, and it definitely needs to pass an "I'm done; here's the results" message.

Network Topology and Security: A public server on which I run my main application. Users in the world -- who may be behind firewalls -- will run my client software. The client connects to my server and registers itself as available for work. My application actor, running on the server, gets this registration and launches an actor on the user's machine. The user actor classes are already on the client machine -- they were built in as part of the client software -- and they are already loaded into memory, so there is no need for me to dynamically load the actor classes. [Support for dynamic load is a nice-to-have.]

I need to be able to prevent an EXE which is not really a client I wrote from spoofing the connection and prevent someone from corrupting the data, because social science projects tend to have people try to skew the data deliberately just for fun.

Error Behavior: If the network connection evaporates, the application actor gets a message that the user actor is gone. Because it does not have the last state of the user actor, it has to have stored knowledge of which data set that user actor was working on so it can give that data set to another user actor. The user actor immediately quits for lack of a network connection. [SETI At Home used to have a "work offline" mode back in the modem days, but such isn't needed as much today, and it is easier bookkeeping if the user actor just shuts down upon loss of its network connection.] There is no need to attempt to re-establish the connection.

Anything Additional Aristos Queue Needs To Know About Requirements: No. AQ is fully aware of this use case because he came up with it.

[drjdpowell]

Goal: Automated banks of multiple high-temperature furnaces.

Details: several racks of multiple high-temperature furnaces are controlled by Real-Time controllers (Thermocouple inputs, heater outputs, etc.).  Users, on a nearby desktop, configure individual furnaces to perform set temperature profiles, lasting from 8 hours to 30 days in duration, and record data throughout (data interval of 5 seconds).  Actors (one main actor for each furnace) will run these profiles. 

Network Topology and Security: Local net between one or more desktop computers that run a UI and several Real-Time controllers.  Security is handled by having all desktops and Real Time Controllers behind a Firewall Router (they are all in the same locked room), so extra security is not required.

Error Behavior:  Intermitant loss of the User Interface(s) expected (Windows desktops don't run for weeks or months reliably).  Furnace Actors must continue regardless of UI contact, and must seamlessly allow a newly restarted UI to reestablish control.  Thus, all configuration information and data needs to be kept on the Real-Time controllers.  When reconnecting, the UIs must be be sent this information so that it can provide the proper display.

Anything Additional Aristos Queue Needs To Know About Requirements:  Final results need to be uploaded to a database.  This can only be done from the desktop machines, not the Real Time units, meaning that there must be a final message containing a potentially large amount of data.  If no UI is online when a profile finishes, the Furnace actor should wait until a UI desktop is available (actually, perhaps there should be a separate "Upload Actor" that the Furnace Actor remote launches on the Desktop machine).  Multiple UIs are desirable, but not strictly necessary.

This project was done a few years ago using large numbers of Shared Variables.  Below is a current image of it running (one rack of 6 furnaces; the four of them are midway through temperature profiles of between 14 and 22 days; UI computer is rebooted weekly).  If I were doing this again, I would use my home-grown Actor system and TCP message passing instead of all the Shared Variables. 

PS> You might want to read about the various network messaging systems out there, such as zeroMQ, for ideas.

Message was edited by: drjdpowell

[AristosQueue (NI)]

What security (authorization/encryption/firewalling) requirements do you have?

[joernw]

Goal: Send large datasets to numberchrunching-clusters and get results back; also control remote machines during aquisition

Details: Scientics need to get a big as possible datafeedback from measurements to adjust and align the setup and see the results in realtime. So we need to transfer big datasets to from thin measurement-clients to big numbercrunchers. Then we we need the outcome to be sent back to its remote caller. also from hardware requirements (some work only on win xp, some need 64bit, etc) paired together with practical consideration (controlling a laser wich is fibercoupled to the experiment and stands in an another room) the need for controlling actors over tcp/ip. This implies low latency, since we are dealing with devices wich work on nanosecond timescale, so a less then 10ms ping should be in on local network!

Network Topology and Security: Local Network, Point to Point, need to transfer datasets > 1gb; Security: " I would be happy if someday somebody steals my measurementdata and analyze it me"

Error Behavior: Crucial Scripst run local (in local cable network), datalogging stores local until remote save is confirmed, experiment halted upon loss on connection (abort by user -> write partial, flush "stilltosendqueue". else wait for connection; remote clients check upon next connection if data was aborted -> write partial, else receive todoqueue

Anything Additional Aristos Queue Needs To Know About Requirements:  If an error with devices happens normally the measurement is thrown away and restarted. The key problem is to have methods to ensure data is received (I'd rather grab the the data together from various tempdirs than loosing it if it was a network error) and that we get high throughput or low latency (both are required, but not together, distinguish between command and data)

At the end we need a network-timersynchrochnisation. For any time-dependend distributed program a timesynch is mandatory. do you have any ideas on how to that?

lg joern

[AristosQueue (NI)]

joernw wrote:

> do you have any ideas on how to that?

No clue. That's the reason for this fishing expedition: to learn the stuff I need to go research. Ask again in a year or two. And let me know anything you figure out in the interim. 😉

[davidpcl]

The horse may have already bolted on this one, but here is how we are using Actors across a network if anyone is interested.

Goal: Create a complete car infotainment simulation system comprising GPS, FM/AM/DAB Radio, Zigbee, Bluetooth, various network protocols, ITS, CAN.

Details: We have been contracted to create a complete infotainment simulation system distributed across a number of PXI chassis - some real time. The whole system needs to be remotely controllable via TCP/IP, and there is a strong requirement to ensure that the system is future proofed and is easily modified without breaking the core code. We proposed Actor Framework as we believed it ticked all these boxes and are using Linked Network Actors to seperate out each modules View and Controller layer so that we can run the Controller on one PXI rack whilst the View is a sub panel within the main GUI, but also so that these modules can run as standalone actor applications (i.e. Localhost). So far this seems to be working really well and as of yet, no problems.

Network Topology and Security: Local Network

Error Behavior: Should behave identically to if one Actor was spawned as a child of another.

Anything Additional Aristos Queue Needs To Know About Requirements:  Don't think so.

Dave