nnet for game server about nnet HOT 13 CLOSED

Before talking about solutions, I'd like to first fully understand what what you are trying to achieve. Are you trying to do something like this:

Each user has a physical machine;
Each machine is running a game server;
Each machine might run multiple game clients;
Each game client wants to be able to send a message to a given game client;
Each game client wants to be able to broadcast a message to all game clients in the world.

My understanding is probably not accurate, please correct me if I'm wrong.

from nnet.

Hello,

To try to answer your flow:

Each user has a physical machine;
Each machine is running a game server;
Each machine might run one or more local game clients when they want connect to the local server;
Each game local server wants to be able to send client messages to other local server that send messages to local clients;

Basically, the local servers will be in P2P which allows for massive scaling.

from nnet.

That's more clear! One more question:

Each game local server wants to be able to send client messages to other local server that send messages to local clients;

When a server sends messages, do you want all other clients to receive the message (broadcast, no need to know recipients), or just one or a few specific clients (need to know recipient info)?

from nnet.

This is approximately correct, but what I will actually have will more likely be groups of local servers that would need to receive the broadcast but only for that group.

I could make the analogy of a chat server sending messages to people on that particular channel and I would also have multiple channels so it would need to keep the broadcasts to all users on one channel separate from a broadcast to users on another channel.

All of the local servers on one group "channel" should be able to broadcast to all of the other servers within that group (channel) but be separated from the other servers on another channel.

Does this help any?

from nnet.

There are a few potential ways in general when you want to nnet/nkn for network layer, from high level to low level:

• You can use NKN SDK in your client, without running any NKN node or using nnet yourself. It will use the public NKN network as your infrastructure. This is the easiest way but the performance is limited. Also it's not possible if you want some customized functions like broadcast.
• You can run your own private NKN network on those machines and use NKN SDK in your client. It's similar as above but you can control the quality of the nodes/network.
• You can use nnet as your p2p network layer in your game server (just like what NKN node does). You need more low level coding but it definitely gives you the best performance and flexibility.

So from what I understand, you might want to use the last option as you need a lot of customized feature and high performance bar since it's game server. If so you don't need to run NKN node or embed NKN SDK (although NKN node repo is a good reference as nnet use case). Did I understand it correctly?

from nnet.

@yilunzhang Thanks for the detailed information.

So then, what I will have on each physical computer is:

1. Modified Surge file manager -- This is being developed so that it can provide a virtual disk mounted system with systray integration. (i.e. Basically getting rid of the web Walis integration)

2. Game Server with NKN CPP SDK integrations -- This will allow the Game Server to communicate via the NKN network.

3. NKN node (this will be optional, but by default) -- The user can have a full/partial NKN node installed and running in which case (1) & (2) above will pass all messages (kcp) through that local node (3) or the user might choose not to have a local NKN
   node running at all in which case (1) and (2) above will send messages to the nearest neighbors. (Probably ping times).

Generally, each physical machine will have all 3 servers running at some point, but I would like to set it up so that the user would have a choice in the settings section that I will have set up, so that they can either run, or not, a full NKN node on the private network.

With this in mind, I will want to establish a "private" NKN network so that all of the local NKN nodes will be connected and running separately from the "real" NKN network as well.

For the nnet question, I will also want to figure out how to have an instance of nnet get a list of nearest neighbors and maybe one of your examples will show me how this can be done.

Best Regards, and have a good day.

from nnet.

So if you want to use NKN node and SDK for communication, you should keep in mind that some features might not be available without modifying NKN node/sdk code. An example is broadcasting, i.e. send messages to all possible clients without knowing their addresses. Basically NKN client is designed to do point to point communication (with end to end encryption). If you want to do something less secure but higher performance (broadcasting is an example), nnet could be a better option but need more work for sure.

NKN node (this will be optional, but by default) -- The user can have a full/partial NKN node installed and running in which case (1) & (2) above will pass all messages (kcp) through that local node (3) or the user might choose not to have a local NKN
node running at all in which case (1) and (2) above will send messages to the nearest neighbors. (Probably ping times).

In order for this to work, you will need to do some work when creating a NKN client. Basically you need to select appropriate identifier so that the client should be connected to the local node (their ID are close enough in ID space). This is because a client cannot choose the node he connects to arbitrarily, or other nodes won't know where to deliver the packets to.

With this in mind, I will want to establish a "private" NKN network so that all of the local NKN nodes will be connected and running separately from the "real" NKN network as well.

That would be a good idea.

For the nnet question, I will also want to figure out how to have an instance of nnet get a list of nearest neighbors and maybe one of your examples will show me how this can be done.

For nnet/nkn, "near" is based on ID distance, not physical distance, so "nearest" neighbors are typically not meaningful. For scalability and load balancing, all nodes in nnet/nkn form a Chord DHT based network. Each node connects to some sparse nodes in the ID space following the Chord DHT rules. For each nodes there are four types of neighbors: successors, finger tables, nodes that choose you as successors (a.k.a. predecessors), nodes that choose you as predecessors. You can get each type of neighbors using corresponding methods like https://github.com/nknorg/nnet/blob/master/overlay/chord/chord.go#L656 . But most likely you won't need them at all.

from nnet.

Thanks so very much for your wonderful discussion on this as it will prove to be extremely helpful as things get into place.

Right now, the Surge file transfer system is being worked on as well as the core game servers. Once the game servers are ready then I will try to use the NKN SDK to integrate some of the messaging stuff.

From another link, I have the CPP SDK (https://github.com/gdmmx/nkn-sdk-cpp) but may need to see if it can be used with nnet as well since the messaging will be from the game servers that are in CPP.

Thanks again for everything.

from nnet.

I'm not sure if you can use NKN SDK with nnet. Basically NKN is using nnet as p2p network layer and has its own protocol, so NKN and nnet are at different layer.

from nnet.

Hello @yilunzhang,

In our last discussion on this you mentioned as the last option:

You can use nnet as your p2p network layer in your game server (just like what NKN node does). You need more low-level coding, but it definitely gives you the best performance and flexibility.

Is it correct in that this option would not pass messages through any NKN network nodes?

Also, you mention "nearest" neighbor as being near in terms of ID. Is there any way to work out "near" neighbor in terms of physical location or in NKN network ping time as I need near to be physically close to the calling node?

This type of "near" will be critical for the forked version of the Surge that I have as well since, it too, will be sending/receiving from the local NKN node that in on that machine as its gateway node.

Thanks again and have a good day.

from nnet.

Maybe this discussion should move over to the NKN repo since these last questions are more about how to have and NKN node that is physically or in-network ping-time "near" a particular NKN node.

from nnet.

Is it correct in that this option would not pass messages through any NKN network nodes?

Yes that's right.

Also, you mention "nearest" neighbor as being near in terms of ID. Is there any way to work out "near" neighbor in terms of physical location or in NKN network ping time as I need near to be physically close to the calling node?

I don't think so to the best of my knowledge. Most scalable p2p networks are based on DHT like topology (e.g. Bittorrent/Ethereum use Kademlia DHT, NKN use Chord DHT), where "neighbor" and "distance" are defined in ID space. One way to make it geo aware is to make ID relying to geolocation, but that definitely need some heavy work, and has its drawback too.

Another workaround is to use random identifier on your client til it connects to your local node. But it probably won't improve the performance significantly because a typical client to client path has multiple hops. By connecting to local node as the first hop, you will only be able to optimize the first (and last) hop, all the other hops in between remain unchanged. If there are, for example, 6 hops in total, 4 of them will still be there.

Maybe this discussion should move over to the NKN repo since these last questions are more about how to have and NKN node that is physically or in-network ping-time "near" a particular NKN node.

I agree. Let's move to nkn repo for NKN node related discussion and keep this for nnet related discussion,

from nnet.

I have moved the discussion over to Discord so that we can chat more, ok.

Thanks again

from nnet.