<< Click to Display Table of Contents >>
Remote Domains |
The E3 Server executing the Client Domain, as well as the one executing the Server Domain, must have a specific license for Remote Domains. When this license exists, the E3 Server executing as Server Domain starts accepting an unlimited number of external connections from other Domains. Likewise, in case of a Client E3 Server, users can establish an unlimited number of connections. For more information about limitations of Elipse E3's Demo mode, please check topic Limitations of Demonstration Mode.
When an error situation happens, all Links from the client application referring the Domain are disconnected. Displays, for example, show an I/O error message, according to Elipse E3 Viewer settings, as well as all Application.GetObject methods referring the Remote Domain fail, that is, cause script errors. When this problem is solved, Links should reconnect automatically. However, Application.GetObject methods must be executed again.
Yes, starting with Elipse E3 version 3.1 users can view and acknowledge alarms in Remote Domains by using, in E3Alarm's AlarmServer property, the syntax REMOTE_DOMAIN:ALARM_SERVER, where REMOTE_DOMAIN is an alias given to a Remote Domain on the Remote Domains tab of Domain configuration and ALARM_SERVER is the name of an Alarm Server. For versions earlier than 3.1, users must duplicate Alarms in a Remote Domain.
No, it cannot.
No, it cannot.
Yes, it can, as seen on the next figure.
Connecting one Domain to several other Domains
Yes, it can. Consider the architecture of the next figure.
Connecting one Domain to a Domain in Hot-Standby
By using Remote Domains this architecture is possible. There is an I/O Domain, in Hot-Standby, communicating with devices. This data is read by another Domain, also in Hot-Standby, which would be the server for client computers (Elipse E3 Viewers).
No, it cannot. This may cause circular links, that is, A » B » C » A, where Domain A has Domain B as its Client, Domain B has Domain C as its Client, and Domain C has Domain A as its Client.
Even if these Links are not circular, Link writings, or other synchronous operations, may cause deadlocks among E3 Servers. To prevent this situation, it is advisable to change the application so that a Domain works only as a Client or as a Server, but never as Client and Server at the same time.
That depends. The Domain file is always opened by the E3 Server, which starting in Elipse E3 version 3.0 executes exclusively in the SYSTEM account. Thus, users must open a sharing for the SYSTEM user, which arrives on the other computer as a Null Session message. This Null Session can be configured to be accepted as an anonymous user. Therefore, configure an anonymous user sharing according to the articles Configuring Remote Domains in machines that are not part of a Microsoft network domain and Configuring Remote Domains in machines that are not part of a Microsoft network domain (Windows XP/Windows XP).
However, there is an incompatibility identified in Windows 7 or later. To prevent this situation, it is advisable that the files of the remote application be copied and pasted on the same folder on the local computer. On Remote Domain settings, configure the Domain File field to point to the copied Domain, which is on the same Elipse E3 Studio computer. The Main server field must be configured with the name of the remote computer. This way, users can use AppBrowser to create all Links via Elipse E3 Studio and, when the application is executed, these values are retrieved from the remote computer.
No, these interactions use REC protocol, Elipse Software's proprietary protocol.
REC is a protocol developed by Elipse Software for communication between different Elipse E3 modules. REC packets have no fixed size. The amount of data passing through this protocol can be viewed on the same Elipse E3 logs and it is indicated by the amount of data, in KB, sent or received.
1.E3 Server must be executing on the destination computer.
2.Firewalls on the destination and local computers must allow TCP/IP connections on port 6515.
3.Connection parameters (time-out, ping, and heartbeat) must be compatible with network's speed, reliability, and latency between the local computer and the destination computer.
A heartbeat is a mechanism through which a Client Domain sends periodic messages to check whether a Server Domain's connection is active, and waits for a response.
To configure a heartbeat time, the Domain must first be loaded. After loading the Domain, right-click E3 Admin icon on Windows Notification Area and select the Domain - Options option. On E3 Admin - Domain Configuration window, select the Remote Domains tab. Select a server, click Advanced, and configure the Heartbeat interval (ms) field.
When the double of this interval is reached without the Client receiving a message from the Server, the system understands that the Server failed or is offline, and forces an immediate disconnection. If both ping and heartbeat are turned off simultaneously, a Remote Domain connection failure becomes harder to detect, when the Server fails. In these cases, it may take 40 seconds or longer before a Client Domain indicates that the connection was lost. It is advisable that both Domains remain turned on whenever possible.
If this happens, please check the quality and performance of the network and follow the instructions of article Network settings in Elipse E3 for networks with high latency, low bandwidth and/or packet loss. However, please notice that the default configuration of Remote Domains, and REC protocol in general, is not adequate for WAN (Wide Area Network) networks, only for LAN (Large Area Network) networks.
In a synchronous communication, both sender and receiver must remain in sync, and a request is only answered after receiving a response for a writing or a request. In an asynchronous communication, on the other hand, data is sent intermittently and does not depend on the result of any request to start the next request.
When a synchronous call is generated, the process awaits indefinitely for a response to that call. When an asynchronous call is generated, on the other hand, no return is expected.
For example, consider an architecture of Remote Domains where there is an Operation Center connecting to several Remote Domains. If one of the Domains is locked and a synchronous call is triggered to that Domain, the whole Operation Center locks.
To prevent that situation, configure the Call time-out (ms) option, available in Elipse E3 since version 4.6, individually for each Remote Domain connection. If a synchronous call takes longer than this time-out value, the channel is closed and unlocks the process that triggered that call.