Global Settings GTNet

The GTNet functionality is controlled via specific global parameters. These parameters can be found in the Global Settings view. They carry two different prefixes: “g.gnet” for the parameters of the GTNet infrastructure itself, and “gt.gtnet” for those that concern the exchange of price data.

Administrator-Managed Parameters

These parameters can be configured by the administrator to customize GTNet behavior.

g.gnet.use

Enables or disables the entire GTNet functionality. A value of 0 means disabled, a non-zero value enables GTNet. By default, GTNet is disabled. Without this activation, no data exchange with other instances takes place.

g.gnet.use.log

Controls the logging of data exchanges. When enabled (non-zero value), all exchange operations between instances are recorded. These logs can be viewed in the Exchange Log view. Logging is disabled by default and can be enabled for diagnostic purposes or to monitor network activity.

g.gnet.connection.timeout

Defines how many seconds your server waits when it contacts another instance before it treats the attempt as failed. The default value is 30 seconds and the valid range is 5 to 40 seconds. An individual instance can be given its own timeout in the GTNet and Messages view; this global parameter applies to every instance for which no separate value has been entered.

gt.gtnet.lastprice.delay.seconds

Defines an additional delay in seconds for calculating the freshness threshold for last price requests. This value is used together with the watchlist timeout to determine whether a received price is still current enough. Prices older than (current time - watchlist timeout - this delay value) are rejected as stale. The default value is 300 seconds (5 minutes).

gt.gtnet.quote.retry

Defines how many additional retries take place via GTNet once the configured connector has reached its retry limit gt.history.retry or gt.intra.retry. Within this additional budget, GTNet keeps the price data up to date without resetting the connector’s retry counter to 0. This way the connector failure remains visible to monitoring while the user still receives price updates. The default value is 8 and the valid range is 0 to 50. A detailed description of the behaviour can be found under Retry Counter and GTNet Fallback.

g.gnet.del.message.recv

Controls the retention period for received exchange messages in PropertyString format. The format is “LP=days,HP=days,SL=days”, where:

• LP (LastPrice): Number of days before last price exchange messages (codes 60, 61) are deleted
• HP (HistoryPrice): Number of days before historical price exchange messages (codes 80, 81) are deleted
• SL (SecurityLookup): Number of days before instrument lookup messages (codes 90 to 95) are deleted

The valid range for all three values is 1-10 days. The default value is “LP=1,HP=5,SL=5”, meaning last price messages are deleted after 1 day, and historical price and instrument lookup messages after 5 days each. This cleanup is performed by background task 22.

g.gnet.log.aggregate.days

Controls the thresholds for exchange log aggregation in PropertyString format. The format is “D=days,W=days,M=days,Y=days”, where:

• D: Number of days before individual entries are aggregated into daily summaries
• W: Number of days before daily entries are aggregated into weekly
• M: Number of days before weekly entries are aggregated into monthly
• Y: Number of days before monthly entries are aggregated into yearly

The default value is “D=1,W=7,M=30,Y=365”. This aggregation is performed by background task 22.

System-Managed Parameters

These parameters are automatically set by the system and should not be modified manually.

g.gnet.my.entry.id

Contains the unique ID of the own instance in GTNet. This value is automatically set when the own server is registered in the GTNet and Messages view. The ID serves as a reference for identifying the own instance in the network.

In rare cases this parameter stays empty when the own server is registered, or it keeps an old value. Grafioschtrader recognizes the own entry by the registered URL pointing at an address of the machine the application runs on. When it runs in a container or behind an address translation, it only knows the address of that environment and not the one it is reachable at from outside; the match then fails without any message being shown. The same happens after importing the personal data of another instance, because this parameter is carried over while the server list is not — it afterwards points at an entry that does not exist here.

It shows itself in the GTNet and Messages view still displaying the red hint that your own server has to be registered, although it already was. The parameter is then set by hand to the ID of the own entry. That ID is given by the tooltip of the URL column in the server overview, where it precedes the URL. After the change a restart of the application is advisable, so that the own entry is listed as “Online” again.

gt.gtnet.exchange.sync.timestamp

Stores the timestamp of the last successful synchronization of exchangeable entities. This value is automatically updated after a synchronization process is completed. It is used to determine which entries have changed since the last synchronization.

Status Synchronization Between Servers

GTNet automatically keeps server status information synchronized between connected instances. This section explains when status changes are published to remote servers and when updates from remote servers reach your instance.

Outgoing Status Changes (Your Server → Remote Servers)

Status changes from your server are broadcast to all remote servers with which you have an established communication (completed handshake with exchanged tokens).

Automatic Broadcasts

Manual Broadcasts

The following status messages can be sent manually via the context menu in the GTNet and Messages view:

How these messages are entered and how the peers act on them is described under Maintenance and Discontinuation.

Incoming Status Changes (Remote Servers → Your Server)

Your server receives status updates from remote servers in two ways:

1. Explicit Status Messages

When a remote server broadcasts a status change (online, offline, busy, maintenance, etc.), your server receives and stores this message. These messages are visible in the message history of the GTNet and Messages view.

2. Automatic Settings Synchronization

Every message received from a remote server includes the sender’s current GTNet configuration in the message envelope. Your server automatically extracts and updates the remote server’s settings from this envelope, ensuring that:

• Daily request limits are always current
• Accept request states (Closed, Open, Push-Open) are synchronized
• Server states (None, Open, Push-Open) are up to date
• Maximum instrument limits are current

This means that even without explicit status messages, your local copy of a remote server’s settings stays synchronized through regular communication.

Server Lifecycle Events

Application Startup

When your GT server starts:

1. If g.gnet.use is enabled (value > 0), GTNet functionality is activated
2. An “Server is now online” message is automatically sent to all connected peers
3. Remote servers update their records to show your server as online

Application Shutdown

When your GT server shuts down gracefully:

1. An “Server is now offline” message is automatically sent to all connected peers
2. Remote servers update their records to show your server as offline

Practical Implications

For Administrators

• Changes made in the GTNet and Messages edit dialog are immediately broadcast to all connected peers
• No manual action is required to notify peers of configuration changes
• The message history shows both sent and received status messages for auditing purposes

For Network Participants

• Your server automatically respects the current limits and states of remote servers
• When a remote server becomes busy, your server reduces request frequency
• When a remote server goes offline, no requests are attempted until it comes back online