Fieldpine Logo

 Quick Links: Site Home | Gds Documentation | All Documentation

Global Data Server Documentation


Gds (or Gds/2) is the name given to the transaction servers running Fieldpine and other applications. It typically runs silently in the background servicing requests and managing data. If you are using a POS system, then Gds is in the background supplying information and ensuring that sales are sent to head office. If you are working on a browser, iPad or using a mobile App, then you are almost certainly using Gds/2.

Gds/2 is the program inside appliances such as the Store Server

A Gds/2 server is capable of interacting with multiple different retailer databases at one time. This allows you to configure a "live" and "test" environment on the same server rather than installing a seperate copy of Gds/2 for each environment you have.

Information for System Administrators

Programs inside GDS

Gds & Mesh Technical Overview

Technical FAQ for Adminstrators and Analysts.

API and standard functions builtin to each Gds Server

Information for Developers

Control Bus messages

Query Exchanger Debugger

Configuration file Gds.ctl

In the root of a Gds folder is a file called Gds.ctl and Gds_sample.ctl. The Gds.ctl file is used to specify how Gds/2 should operate. This file is read by each cooperating agent program during startup.

The Gds/2 configuration file contains a number of sections seperated by a row of dashes (---------). Lines starting with a semi-colon (;) are treated as comments

system
priority=low
hardware=pc
watchdog=yes
flow=yes
-------------------------------------
interface
port=8310
filter-internet=allow(all)
type=debug,normal,internet,private
mac-check=mobile
-------------------------------------
environment Live
db=\LiveData\fpos.mdb
;db=ODBC;dsn=MyLiveDatabase
watchdog=yes

port=8310
dropbox-out=\LiveData\dropboxOut
export-datc=\LiveData\ExportDatc\
rank=ss
rmsystem=5,22,33,44
location=4
option(wordspb) emailcheckbounce=1

-------------------------------------
; Http, must have minimum 1 or cannot use the system interactively
agent http
minimum 1
; option(http) sender=3
; option(http) senderthreshold=132000
; option(http) so_sndbuf=1200000
; option(http) so_rcvbuf=800000
; option(http) maxagent=2

;; url-blacklist=/report/pos/sshome.htm

-------------------------------------

Gds.ctl: Interface Section

The interface section defines different TCP and UDP ports that the server will operate on. Each unique environment such as live or test requires a different TCP Port. The interface section is primarily used by http.exe

port=N
Specifies that Gds/2 should open and use Port N. If the port is not available, Gds will continue to keep trying until it becomes available.

If multiple http agents are running, they will share the incoming load using a modified round robin scheme

type=N
Defines what this port is able to do. It is comma seperated list of the following keywords

Gds.ctl: Agent Section

The agent section contains information directed to individual agent programs that make up Gds/2.

-------------------------------------
; Http, must have minimum 1 or cannot use the system interactively
agent http
minimum 1
; option(http) sender=3
; option(http) senderthreshold=132000
; option(http) so_sndbuf=1200000
; option(http) so_rcvbuf=800000
; option(http) maxagent=2

;; url-blacklist=/report/pos/sshome.htm

-------------------------------------

Agent sections can include agent specific options using the form "option(agent-name)". While naming the agent might seem redundant, some parameters can also be defined at the environment level, and the syntax is then identical.

If a section for an agent is missing, the agent will apply internal defaults. There is no need to create a section for every agent unless you wish to change some parameter.

minimum=N
Sets the minimum number of this agent that should be running. This can either by a fixed number or an offset to the number of cpu cores available using the form cpu-N or cpu+N
maximum=N
Sets the maximum number of this agent that should be running. Not all agents are capable of running multiple instances.
prefer=N
Sets the preferred number of this agent that should be running.
option(http) sender=N
Requests that N sending threads are created, the default is 1 thread. When data is due to be posted to a socket a sender thread might perform this task. One sender thread is easily able to keep up with thousands of sending sockets where the sockets are not all sending very large packets. A sender thread is calling send(), which only transfers data into the operating system buffers, it is not being blocked by wire transmission.

If your Gds/2 server is running with either a large number of clients performing very large data transfers, OR you have very slow network links to some stores then creating multiple senders can improve performance for more normal requests.

option(http) senderthreshold=N
Sets the size of small vs big requests when multiple senders are being used.
option(http) so_sndbuf=N
Supplies an optional value for the socket call
setsockopt(..., SOL_SOCKET, SO_SNDBUF, ...)
which requests that the TCP layer uses larger send buffers than normal. It is recommended this parameter is only set in rare circumstances and that TCP self tuning is used.
option(http) so_rcvbuf=N
Supplies an optional value for the socket call
setsockopt(..., SOL_SOCKET, SO_RCVBUF, ...)
which requests that the TCP layer uses larger receive buffers than normal. It is recommended this parameter is only set in rare circumstances and that TCP self tuning is used.

Documentation for: Users | Administrators | Developers | Reference Data | Natural Language Query | Machines

GDS User Documentation

GDS System Administrator Documentation

GDS Developer Documentation

GDS Reference Data Documentation

Gds provides a large amount of reference data in standardised formats. Much of this data is weak or incomplete and often subject to user opinion, but this data is still very useful.

More on Reference Data

GDS Site Specific Data Documentation

Gds may be used to catalog and store site wide data. Such data is encoded in a standardised form with defined read and write access points.

Messaging

GDS Natural Language Query (NLQ)

Natural Language Query (or NLQ) is experimental and not currently supported, but you are welcome to try it.

NLQ allows a search engine like query or phrase to be entered and have the system derive the intent of the question, much like requesting information from a search engine. NLQ however works within the scope of your current connected databases and available reports, not as a general internet search tool.

With NLQ, you can enter both search strings eg "Richard" or "taupo store" and also requests for reports, such as "list sales for april" or "sales for richard in april".

NLQ can also be used to decode inbound human messages such as responses to email or TXT and process these messages automatically.

GDS Machines Documentation

Machines are experimental and not currently supported.