Talk:Realtime server

Client/Server Module
--tesswilliams 1:30, 30 October 2013 (UTC)

A new class will be developed that will eventually be the main way of creating communication links with entities external to the simulation. It will supplant server mode, as well as the link directive (both of those will maintained while still in active use). Each different modes of communication will be created by an individual object; there may be multiple in a given simulation. The new class is still being spec'ed and input is welcome.

Different communication links may be local/remote, a/synchronous, or client/server. All of the information about ip addresses, protocols, ports, error handling, variables to import/export, etc., will be properties of the communication link object. Communication link objects will be able to access the global variable that controls whether or not the simulation is in realtime and to adjust it at any point in the simulation. Communication links will be made compatible with subsecond calculations.

Currently communication may only start at the initialization of a simulation. Objects in this new class will be able to start or stop at any time due to:
 * initialization or completion of simulation
 * a pre-set timestamp reached
 * a player
 * a toggle of a flag that is externally accessible
 * or a condition on a property being met

Open questions include but are not limited to:


 * What should the new class should be called?
 * Server and link already refer to existing items. Linkage is too close to link and already has too many meanings. Communication is already used in a particular unrelated way in GridLAB-D. Suggestions are welcome. What do people feel about commlink?
 * I'm not really keen on "commlink" as a module name because it sounds an awful lot like telecommunications links are being simulated. Another angle is "cosimulation" but I can see a problem that not all the other apps are necessarily simulation. "Interoperability" might be another idea but ditto that it's not broadly applicable.  Tough one.  Maybe it's time to make up a word from nowhere. --Dchassin 23:31, 30 October 2013 (UTC)


 * Which properties should be read-only and which should be able to be set via information coming in?
 * There are security considerations. Should ip address of a link be dynamically changeable? Should a link be able to influence another link? Should a local gui interface be able to change the properties of a link?
 * Obviously maximum flexibility is desired, but some of the implications are serious. It would be nice if we could develop the capabilities requirements without security considerations and have a separate security requirements section without capabilities considerations.  We can then reconcile/compromise between the two before we dive into specifications. --Dchassin 23:31, 30 October 2013 (UTC)


 * How many different kinds of objects are needed?
 * One for asynchronous HTTP1.1 to replace server mode. One synchronous (to replace link)? Should JSON and MATLAB link protocols be separate objects or the same object with a different set of properties? How specialized to make objects?
 * I would advocate for one object per interface to keep things from getting complicated. However there may be many common components which should be implemented in the module in a common place (using inheritance or a library). --Dchassin 23:31, 30 October 2013 (UTC)


 * How to transition objects such as climate from reading data from a tmy file or from a player to receiving data via a communication link and updating?
 * Create a new chameleon-like object that can take in data from a variety of places and send data to climate object in a consistent form?
 * The chameleon object is potential powerful but challenging to develop. Let's start with what we'd like in an ideal world and then prototype it to see what we can get away with given the current state of the Module API. --Dchassin 23:31, 30 October 2013 (UTC)


 * When to allow changes to communication link objects?
 * Only after a commit? At any time?
 * That may very well depend on the specifics of the system on the other end of the connection. --Dchassin 23:31, 30 October 2013 (UTC)

Recommendations
--Dchassin 16:58, 11 November 2013 (UTC)


 * Module name : Recommend the module name be connection. This idea is that this is for connection-based data exchange protocols.


 * Class names : Recommend the class names be based on the protocol, e.g., connection:xml, connection:json, connection:dnp3, etc.


 * Abstraction : Recommend that the classes all be derived from several abstract classes "tcp", "udp", "server", and "client". Depending on the protocol, options, and user-settings the appropriate abstract class will be used.  The abstract classes will determine what is exposed, writable, etc.


 * Synchronization : The manner of core synchronization should be determined by the abstract classes implementing the method. For example, "server" will typically synchronize very late in the process whereas "client" would synchronize very early.

For example:

module connection {   // default security levels could be     //  NONE (everything is permitted and nothing can be forbidden) // MINIMAL (everything is permitted unless forbidden) // STANDARD (property access determines what is permitted unless forbidden) // HIGH (property access determines what is forbidden unless permitted) // EXTREME (everything is forbidden unless permitted) security_level STANDARD; } class xml {   mode SERVER; // enable server mode transport TCP; // use TCP for data transport from 127.0.0.1; // only accept incoming connections from the local host port 8080; // use port 8080 version 1.0; // use XML version 1.0 encoding UTF8; // use 8bit character encoding schema "http://www.gridlabd.org/gridlabd_3.0.xsd"; // use 3.0 schema stylesheet "http://www.gridlabd.org/gridlabd_3.0.xsl"; // use 3.0 stylesheet security HIGH; // override default module security link "file:datamap.txt"; // datalink map from file (allows external link command lists); link "allow:local_object.var1 -> remote_1"; // permit data send link "forbid:local_object.var2 <- remote_2"; // forbid data receive link "presync:local_object.var3 -> remote_3"; // force data send on precommit, presync, sync, postsync, commit, or finalize }

This work is tracked by [/797 Ticket 797].