If an error occurs, all client-application’s links with the Domain are disconnected (Displays, for example, show the ??? symbol instead of the values), as well as all Application.GetObject commands referring to the Remote Domain fail (which causes script errors). When the problem is solved, all links automatically reconnect to the Domain, but the Application.GetObject commands must be executed again.
Yes, this has been one of the system’s feature since version 3.1.Can I configure a Client-Domain to open screens from other Remote Domains?
No, you can’t.
Can I configure a Client-Domain to utilize users from other Remote Domains?
No, you can’t .
Can I connect a Domain to several other Domains?
Yes, you can. Check the figure below:
Yes, you can. Check the following architecture:
By using Remote Domains, you can create this architecture. On it, we have a “Communication Domain”, in Hot-StandBy, communicating with the devices. The data are read by another Domain, also in Hot-StandBy, which is the server to client computers (Viewers).
Can an E3Server be configured as both Server and Client Remote Domains at the same time?
No. This can cause the emergence of circular links, that is: A -> B -> C -> A, where A is a server to B, B is a server to C, and C is a server to A.
Even if there are no circular links, any synchronous operation can cause deadlocks between E3Servers. To work around this situation, we suggest the application be set up so that a Domain will work as either client or server, but never both.
Can Remote Domains be set up in machines that aren’t a part of a Microsoft network domain?
It depends. The domain file is always opened by the E3Server, which from E3 v3.0 on will only run in the SYSTEM account. You will need then to share this user to another machine, where it will arrive as Null Session. This Null Session can be set up as an anonymous user. Therefore, all you will need to do is to share the anonymous user as seen in 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, we have detected an incompatibility to this in operating system Windows 7 or higher; to work around this, we recommend the files in the remote application be copied and pasted in the same folder in the local computer. In the Remote Domain settings, configure Domain File field to point to the copied domain (in the same machine as E3Studio); the Main server field must be named after the remote computer. Therefore, you will be able to use the AppBrowser to generate all links via E3Studio, and when the application runs, these values will be retrieved from the remote machine.
Is Windows’s DCOM protocol used by Elipse E3 to communicate between Remote Domains and the Viewer?
No, these interactions use REC protocol (Elipse Software’s proprietary protocol).
What is REC? How can I view data traffic in E3’s log?
REC is a protocol developed by Elipse Software for communication purposes between different Elipse E3 modules.
REC packets have no fixed size. The volume of data passing through the protocol can be viewed in the same E3 logs and will the indicated by the amount of data (in kB) sent and received.
What are the minimum required settings to make REC work?
- E3Server must be running in the destination machine.
- The firewalls of both the destination and the local machines must allow TCP connections in port 6515.
- Connection parameters (timeout, ping, heartbeat) must be compatible with the network speed/reliability/latency between machines.
What are heartbeats? Where can I set them up? What is their impact on the system?
Heartbeats are a mechanism through which the client domain sends periodic messages to check whether the server domain’s connection is active while awaiting for a response.
To set up the heartbeat time, you must first make sure the Domain is loaded. Then, access the context menu E3Admin–Domain–Options–Remote Domains, select a server, click Advanced and set up Heartbeat period (ms) field.
When the double of this value is reached with no messages to the Client from the Server, the system understands the Server has failed or is offline, and an immediate disconnection is forced. If both PING and heartbeat are turned off simultaneously, the remote domain connection failure gets harder to be detected (when the server fails). In these cases, it may take 40 seconds or longer before the domain indicates the connection has been lost. We recommend both domains remain on whenever possible.
What should I do in case of an excessive amount of PING errors taking place on the network?
If this happens, check the network’s quality/performance and follow the procedures detailed at Network Settings in Elipse E3 for networks with high latency, low bandwidth and/or packet loss.
However, please notice that the default parameterization of remote domains (as well as REC protocol in general) is not suitable for WAN, only for LANs.
What are synchronous and asynchronous calls? Which one is the best alternative in terms of performance?
In a synchronous communication, both sender and receiver must remain in synch, and a request is only answered after the last one has been completed. In an asynchronous communication, on the other hand, data is sent intermittently, regardless of the requests’ results.
When a synchronous call is generated, the process awaits indefinitely for its return; in an asynchronous call, on the other hand, no type of return is expected.
For example: consider a Remote Domain architecture where there is an Operation Center connecting to several Remote Domains; if one of the domains hangs and a synchronous call is fired for this domain, the entire Operation Center hangs as a consequence.
To prevent situations like this, set up 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 the time-out value, the channel is closed and the process originating the call will “unhang”.
