Skip to content

[Draft]: NEX Service #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

[Draft]: NEX Service #5

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
7fd70fc
feat: add draft for kicking connections
jonbarrow Jun 18, 2025
8f8418d
feat: add draft for nex.v1.GetStats method
jonbarrow Jun 18, 2025
a312e2c
chore: bump PID size to uint64
jonbarrow Jun 18, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions protobufs/nex/v1/get_stats_rpc.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
syntax = "proto3";

package nex.v1;

message GetStatsRequest {}

message GetStatsResponse {
uint64 player_count = 1;
}
9 changes: 9 additions & 0 deletions protobufs/nex/v1/kick_user_aggressive_rpc.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
syntax = "proto3";

package nex.v1;

message KickUserAggressiveRequest {
uint64 pid = 1;
}

message KickUserAggressiveResponse {}
9 changes: 9 additions & 0 deletions protobufs/nex/v1/kick_user_rpc.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
syntax = "proto3";

package nex.v1;

message KickUserRequest {
uint64 pid = 1;
}

message KickUserResponse {}
9 changes: 9 additions & 0 deletions protobufs/nex/v1/kill_user_connection_rpc.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
syntax = "proto3";

package nex.v1;

message KillUserConnectionRequest {
uint64 pid = 1;
}

message KillUserConnectionResponse {}
21 changes: 21 additions & 0 deletions protobufs/nex/v1/nex_service.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
syntax = "proto3";

package nex.v1;

import "nex/v1/get_stats_rpc.proto";
import "nex/v1/kick_user_rpc.proto";
import "nex/v1/kick_user_aggressive_rpc.proto";
import "nex/v1/kill_user_connection_rpc.proto";

service NEXServiceV1 {

Check failure on line 10 in protobufs/nex/v1/nex_service.proto

View workflow job for this annotation

GitHub Actions / Run Protobuf Checks 

Service name "NEXServiceV1" should be suffixed with "Service".
Copy link
Member

@DaniElectra DaniElectra Jun 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It isn't necessary to add the V1 suffix to the service name since that is already handled by the package name nex.v1

Copy link
Member Author

@jonbarrow jonbarrow Jun 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is, gRPC differentiates services by their name. We just got lucky in the other services that we happened to rename them in their respective v2 updates

Copy link
Member

@DaniElectra DaniElectra Jun 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The service name isn't relevant here, so long as the package name is updated. Let's look at an example from the Go account service:

The "v1" version (with package name account) is located on "github.com/PretendoNetwork/grpc/go/account", and the server and client interfaces are prefixed with the service name: AccountClient

The v2 version (with package name account.v2), however, is located on "github.com/PretendoNetwork/grpc/go/account/v2" and the server and client interfaces are prefixed with the new service name: AccountServiceClient

Even if the service names were the same, they are still located at different scopes in code, so there isn't any issues with keeping the name as NEXService across versions, since the code for them would be stored at different locations and therefore they can't collision.

In this case, the package name is the following:

grpc/protobufs/nex/v1/nex_service.proto

Line 3 in a312e2c

package nex.v1;

So there won't be any issues with keeping the service name the same as long as the package name is updated to v2 accordingly when needed

Copy link
Member Author

@jonbarrow jonbarrow Jun 22, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was partially mistaken. gRPC uses both the service name and package name to create the identifiers (this can be seen in the account server, where our middleware checks path names and these path names include the service identifier. Examples being /api.API/GetUserData and /api.v2.ApiService/GetUserData), so the service name is still relevant, since it means we could keep everything under the same package but with different service names, or we could use different packages (like what we do now) with the same package names

That being said, I still believe it's good to version the service name as well for cases where we need to support multiple versions at the same time. The account server is a good recent example of that, where because we didn't version the service names and the names look so similar (AccountDefinition vs AccountServiceDefinition) it's hard to see at a glance what version each service is, resulting in code like:

import { AccountDefinition as AccountServiceDefinitionV1 } from '@pretendonetwork/grpc/account/account_service';
import { AccountServiceDefinition as AccountServiceDefinitionV2 } from '@pretendonetwork/grpc/account/v2/account_service';

But if instead we had versioned the service names, we would not need for a namespace import:

import { AccountServiceDefinitionV1 } from '@pretendonetwork/grpc/account/account_service';
import { AccountServiceDefinitionV2 } from '@pretendonetwork/grpc/account/v2/account_service';

rpc GetStats(GetStatsRequest) returns (GetStatsResponse) {} // This name kinda blows

// Remove a user gracefully using the built in DISCONNECT system
rpc KickUser(KickUserRequest) returns (KickUserResponse) {}

// Remove a user aggressively using methods like killing the internal RC4 stream along with graceful methods
rpc KickUserAggressive(KickUserAggressiveRequest) returns (KickUserAggressiveResponse) {}

// Remove a user by any means necessary
rpc KillUserConnection(KillUserConnectionRequest) returns (KillUserConnectionResponse) {}
}
Loading