1. Introduction
Several E3 settings pertaining network connections management may not be suitable for all networks. Usually, E3’s default settings work well in a local network (LAN) Ethernet (10Mbps) or higher.
This article lists the usual adjustments (sometimes even mandatory) that must be made in the application settings and the computer (via E3Tweak) for the better functioning of E3 nonlocal networks. In the case of the settings made at E3 Server via E3Tweak, its effect will be global, applying to all incoming connections by E3 Server, be them from a local area network (LAN) or a remote one (WAN), and be it a Viewer/WebViewer, Studio connection , or from another E3 Server (ho t-standby and Remote Areas).
In case of the Viewer/WebViewer, you can make adjustments directly in the Viewer object of the application, from within the Studio.
In case of Remote Domains, some settings can be made in the configuration window of the remote domains in E3 Admin, and applied separately to each connection later.
2. E3Tweak Settings
E3Tweak settings regarding the characteristics of the network are at sub-item E3 Server and sub-item REC. Note that in general they apply to various types of connections E3 Server can receive. That is, they are not selective settings.
2.1 REC
2.1.1 Compression level (Ellipse Software\E3\REC\CompressionLevel)
Where bandwidth is reduced (e.g., less than 10Mbps), it is recommended to enable compression. Usually, it may be better to simply use the maximum compression, which is value 9.
This configuration must be done in all server machines (where E3 Server is running), and optionally there may be a (lower) gain in doing this also on machines running the Viewer/WebViewer (clients), if these machines are pre-determined.
This option applies to all E3 Server connections, the most important being its use in the case of the Viewer/WebViewer and Remote Domains.
2.1.2 Connection Timeout (Ellipse Software\E3\REC\ConnectionTimeout)
Occasionally, if the network’s latency is very high (e.g., > 500 ms), it may be necessary to set the connection’s timeout. It should be set on machines that run Studio (hot-standby has this time set automatically according to exchange time configured; remote domains have a separate configuration; and the Viewer/WebViewer does not use this timeout). Another possibility is to allow more time while waiting for E3 Server to find hardkey, if E3 Server has been recently initialized. This applies to the Studio running on the same machine as the E3 Server.
NOTE: This setting does not affect Viewer/WebViewer, Remote Domains, and Hot-standby connections.
2.2 E3 Server
2.2.1 Timeout for Ping (Ellipse Software\E3\E3\PingTimeout)
This setting makes E3 Server detect client failure earlier, so it will stop sending (and accumulating) messages regarding that connection.In high-latency networks, you can simply use a value greater than the default 2 seconds (2000). If your E3 version is 3.2 or older, on networks with very limited bandwidth, and/or where packet loss simply occurs, the ideal may be to turn off this feature by using value 0 (zero). If your E3 version is 3.5 or higher, you should also use the following configuration (PingRetries).This configuration must be done in all the server machines (where E3 Server is running).
NOTE: If E3 Server receives connections (either from the Viewer/WebViewer, Remote Domains, etc.) from several networks, this configuration must contemplate the worst case scenario, that is, the network with higher latency and/or losing more packets.
2.2.2 Number of retries if ping fails (Ellipse Software\E3\E3\PingRetries)
These settings work alongside the previous configuration (PingTimeout). In congested networks (limited bandwidth) and/or where packet loss occurs, ping failure can occur even with very high timeouts. In fact, ideally you should use retries to differentiate a simple packet loss from a “real” network failure. Use it alongside the correct setting of PingTimeout so that an occasional loss of ping packet will not cause a client to disconnect (Viewer, Remote Domain, etc.). For example, if during normal network usage the latency measured by the Windows ping is 700 ms, the PingTimeout can be used in 2800 ms, alongside PingRetries 2 or 3. This must be set in all the server machines (where E3 Server is running).
NOTE: Since the disposal of ping packets (ICMP protocol) may depend on various network characteristics, you should always test the worst case scenario to see how the ping behaves. Occasionally, it may be necessary to leave PingTimeout as 0, even when working with E3 version 3.5.
2.2.3 License heartbeat (Ellipse Software\E3\E3\LicenseHeartBeat)
This configuration provides verification for the presence of the client on the network once REC connection is established. This allows the E3 Server to quickly detect a client’s failure and shut down its connection with this, releasing the associated license. This applies only to connections that consume licenses, i.e., Viewers, Studios and Remote Domains (hot-standby’s heartbeat is configured automatically according to exchange time set). This configuration must be done in all the server machines (where E3 Server is running). If the network latency between the client and E3 Server is high, this value should be adjusted accordingly, so that the E3 Server does not disconnect the client for no reason.
NOTE: If the E3 Server receives connections (be they Viewers, Remote Domains, etc..) from several different networks, this configuration must contemplate the worst case scenario, that is the network with higher latency.
3. Viewer Settings
REC protocol allows the use of network checks both from the client and from the server. As for the Viewer, there are two possibilities:
3.1 PING
By using the option /NOPING on the command line (or NOPING option on the WebViewer page), you can make the Viewer/WebViewer not depend on PING to try to connect to the server. This can be useful if the PING (ICMP protocol’s “echo” request) is blocked at the network and/or losses occur frequently with this kind of package. You might also want to turn this off if network latency is too high and the Viewer’s default value of 4 seconds is not appropriate. But with such high latency, Viewer usage will not be accepted anyway. This setting is effective only when the Viewer connects to a remote server (i.e., not on the same machine as the Viewer).
3.2 EnableHeartbeat, HeartbeatPeriodMs, HeartbeatTimeoutMs
With EnableHeartbeat, HeartbeatPeriodMs, and HeartbeatTimeoutMs properties, you can make the application check for the presence of the server in the machines running Viewer/WebViewer. This allows the Viewer to detect servers exchange and/or a connection failure with E3 server faster.
EnableHeartbeat: The default value of this property is False, but must be set to True if you want the Viewer to respond more quickly to exchanging servers, for example.
HeartbeatPeriodMs: controls the minimum frequency with which the server must send messages to the Viewer. The default value of this property is 2000 (2 seconds), but it must be increased if the network latency is high. Notice that its value must be between 200 and 30000, and cannot be larger than HeartbeatTimeoutMs.
HeartbeatTimeoutMs: controls the maximum time that the Viewer will accept messages from the server running out. This property’s default value is 5000 (5 seconds), but must be increased if the network latency is high; the recommended value is 2 to 3 times the value of HeartbeatPeriodMs property.
NOTE: If the Viewer/WebViewer can be opened from several different networks, this configuration must contemplate the worst case scenario, that is, the network with higher latency.
4. Settings for Remote DomainsSince E3 version 3.2 Build 106, the settings of network parameters of client connections to remote domains are made individually, thereby allowing the best values to be used in each case, according to the specific characteristics of the network between the client and each different remote server. The settings are accessed via “Advanced” button for each defined connection.
4.1 Connection Timeout
This time can be increased if the network latency is high, so as to allow the connection to be completed. The value should be a few times higher than the network latency in real use. In a network where latency is very low (<1 ms), we recommend you to keep the default value. Usually, this only contemplates any additional network latency. 4.2 Checking PING / PING timeout
With this option, you can keep the remote domain client from depending on ping to try to connect to the server. This can be useful if the PING (ICMP protocol’s “echo” request) is blocked at the network and/or these kinds of packages are frequently lost. If this option is enabled, the ping check is made before and after connecting, in order to detect either the presence or failure of network connection. The timeout value should be adjusted if the network latency is high, and we recommend that this value is two to three times higher than the latency. Notice that the value 0 will disable the use of PING (which is equivalent to unchecking the option).
4.3 Using heartbeat in the connection / heartbeat period
We recommend that you leave this option always checked; only increasing the value of the heartbeat period so it will be compatible with the network latency. That is, the value should be a few times higher than the network latency in real use. If this option is turned off, it is recommended that at least the option Check PING is used, otherwise the client may occasionally be locked for a long time in the event of failure of network connection. Notice that value 0 turns the use of heartbeat off (which is equivalent to unchecking the option).
4.4 Using asynchronous link creation
We recommend that you leave this option always checked, because it allows the navigation on screens or any other operation that creates new links in batches to be directly affected by the slow response of the domain server. The exception to this case is if the domain server is a version 3.1 or lower, in which case it should stay off work for the connection to work, since the asynchronous creation of links did not exist before version 3.2 Build 106.
