4.Zinx Global Configuration
Published: 2023-06-14 08:23:29

### [Zinx]

[<1.Building Basic Services with Zinx Framework>](https://dev.to/aceld/1building-basic-services-with-zinx-framework-296e)
[<2. Zinx-V0.2 Simple Connection Encapsulation and Binding with Business>](https://dev.to/aceld/2-zinx-v02-simple-connection-encapsulation-and-binding-with-business-4p9g)
[<3.Design and Implementation of the Zinx Framework's Routing Module>](https://dev.to/aceld/3design-and-implementation-of-the-zinx-frameworks-routing-module-583n)
[<4.Zinx Global Configuration>](https://dev.to/aceld/4zinx-global-configuration-3jam)
[<5.Zinx Message Encapsulation Module Design and Implementation>](https://dev.to/aceld/5zinx-message-encapsulation-module-design-and-implementation-3fmc)
[<6.Design and Implementation of Zinx Multi-Router Mode>](https://dev.to/aceld/6design-and-implementation-of-zinx-multi-router-mode-19nn)
[<7. Building Zinx's Read-Write Separation Model>](https://dev.to/aceld/7-building-zinxs-read-write-separation-model-ihj)
[<8.Zinx Message Queue and Task Worker Pool Design and Implementation>](https://dev.to/aceld/8zinx-message-queue-and-task-worker-pool-design-and-implementation-12gl)
[<9. Zinx Connection Management and Property Setting>](https://dev.to/aceld/9-zinx-connection-management-and-property-setting-28ha)

### [Zinx Application - MMO Game Case Study]

[<10. Application Case Study using the Zinx Framework>](https://dev.to/aceld/10-application-case-study-using-the-zinx-framework-3ich)
[<11. MMO Online Game AOI Algorithm>](https://dev.to/aceld/11-mmo-online-game-aoi-algorithm-l7d)
[<12.Data Transmission Protocol: Protocol Buffers>](https://dev.to/aceld/12data-transmission-protocol-protocol-buffers-1jek)
[<13. MMO Game Server Application Protocol>](https://dev.to/aceld/13-mmo-game-server-application-protocol-5adl)
[<14. Building the Project and User Login>](https://dev.to/aceld/14-building-the-project-and-user-login-b7p)
[<15. World Chat System Implementation>](https://dev.to/aceld/157-world-chat-system-implementation-18li)
[<16. Online Location Information Synchronization>](https://dev.to/aceld/16-online-location-information-synchronization-3cp1)
[<17. Moving position and non-crossing grid AOI broadcasting>](https://dev.to/aceld/17-moving-position-and-non-crossing-grid-aoi-broadcasting-4nb9)
[<18. Player Logout>](https://dev.to/aceld/18-player-logout-3eln)
[<19. Movement and AOI Broadcast Across Grids>](https://dev.to/aceld/19-movement-and-aoi-broadcast-across-grids-46fe)

---

## source code
https://github.com/aceld/zinx/blob/master/examples/zinx_release/zinx-v0.4.tar.gz

---

As the framework grows, the number of parameters increases. To avoid the hassle of frequently modifying parameters later, Zinx needs a module to load configurations and an object to globally access Zinx parameters.

## 4.1 Implementation of Global Configuration in Zinx-V0.4
First, let's design a simple configuration loading module. We'll choose the widely used JSON format for the configuration file. The configuration information is as follows:

> zinx.json
```json
{
    "Name": "demo server",
    "Host": "127.0.0.1",
    "TcpPort": 7777,
    "MaxConn": 3
}
```

Now, Zinx needs to create an object to store global configuration information.


#### 1. Create the Global Parameters File

Create a folder named `utils` in the `zinx` directory. The `utils` folder will mainly contain shared utility modules of the Zinx framework. Inside the utils folder, create a file named `globalobj.go`. Initially, write the code as follows:

> zinx/utils/globalobj.go
```go
package utils

import (
    "encoding/json"
    "io/ioutil"
    "zinx/ziface"
)

/*
    Stores all global parameters related to the Zinx framework for use by other modules.
    Some parameters can also be configured by users in zinx.json.
*/
type GlobalObj struct {
    TcpServer ziface.IServer // Current global Server object of Zinx
    Host string // Current server host IP
    TcpPort int // Current server host listening port
    Name string // Current server name
    Version string // Current Zinx version
    MaxPacketSize uint32 // Maximum size of data packet to be read
    MaxConn       int    // Maximum number of allowed connections on the current server host
}

/*
    Define a global object
*/
var GlobalObject *GlobalObj

```

The above code defines a `GlobalObject` object globally, and the variable is capitalized to be exposed to other modules. This allows other modules to access the parameters inside it.

The global configuration includes the following parameters:



* `TcpServer`: This is an IServer type attribute, representing the current running Server object of Zinx. This attribute cannot be configured through zinx.json. It is added to the global object after the Server instance is started, allowing other modules to access the current Server instance of Zinx.
* `Host`: The IP address on which the Zinx service listens. It is a string type and can be configured in the zinx.json configuration file.
* `TcpPort`: The port number on which the Zinx service listens. It is an integer type and can be configured in the zinx.json configuration file.
* `Name`: The name of the current Zinx service, which has the same meaning as the Name attribute in the Server.
* `Version`: The version number of the current Zinx, used for management and differentiation in logs.
* `MaxPacketSize`: Currently, Zinx does not utilize this capability. It represents the maximum length of the data packet that the Zinx service reads from the remote end.
* `MaxConn`: Currently, Zinx does not utilize this capability. It represents the maximum number of connections allowed on the current server. It will be used in future versions to limit the number of Zinx connections.

#### 2. Providing the init() Initialization Method

Next, we'll provide an init() method for `globalobj.go` to initialize the GlobalObject object and load the server application configuration file `conf/zinx.json`. The code implementation is as follows:

```go
// zinx/utils/globalobj.go

// Read the user's configuration file
func (g *GlobalObj) Reload() {
    data, err := ioutil.ReadFile("conf/zinx.json")
    if err != nil {
        panic(err)
    }
// Parse the JSON data into the struct
// fmt.Printf("json: %s\n", data)
err = json.Unmarshal(data, &GlobalObject)
    if err != nil {
        panic(err)
    }
}

/*
    Provide the init() method, which is automatically loaded.
*/
func init() {
    // Initialize the GlobalObject variable and set some default values
    GlobalObject = &GlobalObj{
        Name: "ZinxServerApp",
        Version: "V0.4",
        TcpPort: 7777,
        Host: "0.0.0.0",
        MaxConn: 12000,
        MaxPacketSize: 4096,
    }

    // Load some user-configurable parameters from the configuration file
    GlobalObject.Reload()
}
```

When each module is loaded, the `init()` method of that module is executed. In the `init()` method, the `Reload()` method is called to load the local configuration file zinx.json and load the configurable parameters into the Zinx memory.

Note: The translation assumes that the path `"conf/zinx.json"` refers to the configuration file `zinx.json` located in the `"conf"` directory relative to the current module file.

#### 3. Replacing Hard-coded Parameters and Server Initialization Parameter Configuration

Next, we will replace the configurable parameters from the global configuration into the existing implementation logic of Zinx.

First, when creating a new `Server` using the `NewServer()` function, we will assign the Server properties using `GlobalObject`:

```go
// zinx/znet/server.go
/*
   Create a server instance
*/
func NewServer() ziface.IServer {
    // Initialize the global configuration file first
    utils.GlobalObject.Reload()

    s := &Server{
        Name:      utils.GlobalObject.Name,        // Get from global parameters
        IPVersion: "tcp4",
        IP:        utils.GlobalObject.Host,        // Get from global parameters
        Port:      utils.GlobalObject.TcpPort,     // Get from global parameters
        Router:    nil,
    }
    return s
}
```

To verify that the parameters have been successfully loaded, we'll add some debug information in the `Server.Start()` method:

```go
// zinx/znet/server.go

// Start the network service
func (s *Server) Start() {
    fmt.Printf("[START] Server name: %s, listener at IP: %s, Port %d is starting\n", s.Name, s.IP, s.Port)
    fmt.Printf("[Zinx] Version: %s, MaxConn: %d, MaxPacketSize: %d\n",
        utils.GlobalObject.Version,
        utils.GlobalObject.MaxConn,
        utils.GlobalObject.MaxPacketSize)

    // ...
    // ...
}
```

Of course, there are other fixed hard-coded parameters that can be configured in the configuration file and replaced with global parameters. We won't list them here.

The current directory structure of the Zinx framework looks like this:

```go
├── README.md
├── utils
│   └── globalobj.go
├── ziface
│   ├── iconnnection.go
│   ├── irequest.go
│   ├── irouter.go
│   └── iserver.go
└── znet
    ├── connection.go
    ├── request.go
    ├── router.go
    ├── server.go
    └── server_test.go
```

## 4.2 Completing the Application with Zinx-V0.4

Now, in order to complete the server based on Zinx, we need to prepare a configuration file `conf/zinx.json`. The project code path for the Zinx application is as follows:

```bash
├── Client.go
├── conf
│   └── zinx.json
└── Server.go
```

Now, let's modify `Server.go` by removing unnecessary `PreHandle()` and `PostHandle()` methods, and keeping only the `Handle()` method for business logic. The code is as follows:

```go
// Server.go
package main

import (
	"fmt"
	"zinx/ziface"
	"zinx/znet"
)

// Custom router for ping test
type PingRouter struct {
	znet.BaseRouter
}

// Test Handle
func (this *PingRouter) Handle(request ziface.IRequest) {
	fmt.Println("Call PingRouter Handle")
	_, err := request.GetConnection().GetTCPConnection().Write([]byte("ping...ping...ping\n"))
	if err != nil {
		fmt.Println("Callback ping ping ping error")
	}
}

func main() {
	// Create a server instance
	s := znet.NewServer()

	// Configure the router
	s.AddRouter(&PingRouter{})

	// Start the server
	s.Serve()
}
```
To start the server-side program `Server.go`, use the following command:

```bash
$ go run Server.go
```
The expected output is as follows:

```bash
$ go run Server.go 
Add Router success! 
[START] Server name: demo server, listener at IP: 127.0.0.1, Port 7777 is starting
[Zinx] Version: V0.4, MaxConn: 3, MaxPacketSize: 4096
start Zinx server demo server success, now listening...
```

## 4.3 Conclusion
Now, the configurable parameters can be passed through the developer's configuration file. Readers can optimize the implementation logic of this configuration file or use other configuration file protocols as well. The purpose of the configuration file is to allow developers to debug or deploy the program without recompiling, by changing some necessary parameters to switch service capabilities or functionality. Generally, a backend daemon service-type application should have the capability to use a configuration file.

---

## source code
https://github.com/aceld/zinx/blob/master/examples/zinx_release/zinx-v0.4.tar.gz

---
### [Zinx]

[<1.Building Basic Services with Zinx Framework>](https://dev.to/aceld/1building-basic-services-with-zinx-framework-296e)
[<2. Zinx-V0.2 Simple Connection Encapsulation and Binding with Business>](https://dev.to/aceld/2-zinx-v02-simple-connection-encapsulation-and-binding-with-business-4p9g)
[<3.Design and Implementation of the Zinx Framework's Routing Module>](https://dev.to/aceld/3design-and-implementation-of-the-zinx-frameworks-routing-module-583n)
[<4.Zinx Global Configuration>](https://dev.to/aceld/4zinx-global-configuration-3jam)
[<5.Zinx Message Encapsulation Module Design and Implementation>](https://dev.to/aceld/5zinx-message-encapsulation-module-design-and-implementation-3fmc)
[<6.Design and Implementation of Zinx Multi-Router Mode>](https://dev.to/aceld/6design-and-implementation-of-zinx-multi-router-mode-19nn)
[<7. Building Zinx's Read-Write Separation Model>](https://dev.to/aceld/7-building-zinxs-read-write-separation-model-ihj)
[<8.Zinx Message Queue and Task Worker Pool Design and Implementation>](https://dev.to/aceld/8zinx-message-queue-and-task-worker-pool-design-and-implementation-12gl)
[<9. Zinx Connection Management and Property Setting>](https://dev.to/aceld/9-zinx-connection-management-and-property-setting-28ha)

### [Zinx Application - MMO Game Case Study]

[<10. Application Case Study using the Zinx Framework>](https://dev.to/aceld/10-application-case-study-using-the-zinx-framework-3ich)
[<11. MMO Online Game AOI Algorithm>](https://dev.to/aceld/11-mmo-online-game-aoi-algorithm-l7d)
[<12.Data Transmission Protocol: Protocol Buffers>](https://dev.to/aceld/12data-transmission-protocol-protocol-buffers-1jek)
[<13. MMO Game Server Application Protocol>](https://dev.to/aceld/13-mmo-game-server-application-protocol-5adl)
[<14. Building the Project and User Login>](https://dev.to/aceld/14-building-the-project-and-user-login-b7p)
[<15. World Chat System Implementation>](https://dev.to/aceld/157-world-chat-system-implementation-18li)
[<16. Online Location Information Synchronization>](https://dev.to/aceld/16-online-location-information-synchronization-3cp1)
[<17. Moving position and non-crossing grid AOI broadcasting>](https://dev.to/aceld/17-moving-position-and-non-crossing-grid-aoi-broadcasting-4nb9)
[<18. Player Logout>](https://dev.to/aceld/18-player-logout-3eln)
[<19. Movement and AOI Broadcast Across Grids>](https://dev.to/aceld/19-movement-and-aoi-broadcast-across-grids-46fe)


---
Author:
discord: https://discord.gg/xQ8Xxfyfcz
zinx:   https://github.com/aceld/zinx
github: https://github.com/aceld
aceld's home: https://yuque.com/aceld