GTXclient C API GTXserver-16.0.2

- Main Page
- Related Pages
- Data Structures
- Files
- Examples

# GTXserver

This part describes the server. The user must remember that this is a client/server application. A client (which can be modified by the user) will talk (using sockets) with a server and through this server will get access to the Isatis file system without running the Isatis application.

The server can be mono-session or multi-session.

If started mono-session, the server waits for a client connection. The client connects and obtain an exclusive communication channel with the server. It does what it needs with the server and disconnects. At this moment, the server exits.

If started multi-session (-multisession flag), the server waits for a client connection. When a client connects, the server forks (duplicates itself) and open a new port. It gives the new port to the client. The client closes connection with the master GTXserver and connects to its child. The master server it still available for another connection during the transaction between the client and the child server. When the client disconnects, the child server stops but the master one remains there.

To avoid making your application's user run a GTXserver each time you need to read/write Isatis filesystem, you can use the C API function GTXClientRunGTXServer. It will locate the installed Isatis and run the appropriate GTXserver.

But with this, you can only run local GTXservers. If one needs to read data on another machine, this wouldn't work. So you should include in your application, an option to run a local GTXserver or to use an already running one given the host and port the server is running on. The user can then run GTXserver each time it is needed on the "data" machine or use a multi-session one to avoid this.

Both mono and multi sessions have advantages and drawbacks:

A mono session server will have to be restarted after each disconnect. It can only answer one client at a time. If you need to run several clients, you need to run several servers on several ports. However it is quite simple to use and when ran by the client there is no problem with filesystem access rights. The client starts a server with the same rights as an Isatis run.

A multi session server runs as a given user which may not be the one running the client. In an heterogeneous environment like reading data with the GTXserver on UNIX and a client on a PC, the mapping between users may not be easy and would require administrator privileges. For now, when the server forks, it is still running as the same user so it will have its rights to read files from the database and will create file with its own user ID whatever the client user ID is.

Here is a list of the options available when running GTXserver:

-help | Prints help on command usage
-debug | Prints client/server messages. Interesting to follow the dialog between the server and its client.
-fork | Start the server in background
-port port_number | Port used to communicate with the client. The default is the same for the server and the client. If for any reason the default port number is not correct on your machine, you can change it (you must use the same port number in the server and the client).
-multi[session] | Start the server as multi-session. The server will create a new process for each connection