From GridLAB-D Wiki
Jump to: navigation, search

--tesswilliams 10:35, 14 November 2013 (UTC)

Note: This discussion began on the Talk:Realtime server page before the name of the new module had been decided. The beginning of this discussion can be found on that page, and has also been cut and pasted below.

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.

The current implementation of realtime requires that the simulation refer to the system clock. However, this can create lack of repeatability if a simulation has schedules or players. Propose change to realtime to make it possible to simulate at 1 second-per-second, but not tied to clock time. Example use case: start in simulation time to initialize and diversify house models, then after some set time transition to realtime and initiate a connection. If realtime is always tied to system time, then it will be difficult to transition a simulation seamlessly in and out of realtime. --tesswilliams 12:09, 15 November 2013 (UTC)

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
}


--Jcfuller 18:06, 15 November 2013 (UTC)

Discussion about time synchronization.

There is a need for a few orthogonal modifications to the way real time mode currently handles time. While these are not all directly related to the new module, it should be taken into consideration. There are probably others, so please add as needed.

  • Allowance for a slight drift in the clock from real time. Some function calls or solutions may take longer than the available real-time synchronization. This currently causes a hard failure. Users should be able to set an absolute drift (or maybe a drift rate?) that allows for a little flexibility, with the default being zero tolerance. For example, if the simulation were to fall slightly behind real time, could it then accelerate on the next time step to "catch up". Other limits should also be considered, such as how many timesteps have I been behind or ahead of real time.
  • Simulation time in real-time mode should not be hard-wired to machine/wall clock. If the user specifies a clock, it should be assumed they are requesting that this be the simulation time. This will become especially important when federating across timezones or when trying to repeat a simulation event with slight modifications. This implies a relationship between the change in time, not the actual time, between synchronizations.
  • Users should be able to move in and out of real time versus accelerated time. This is important in initializing simulations. This may have an impact on the way the module connects, disconnects, and reconnects to external simulations/devices.

This work is tracked by Ticket 797.