Current Status
MarianoGnu opened this issue · 5 comments
Hello, i'm a developper in the Godot team and was assigned to research Network API. I just realized this module exists, can you tell me about the current status of this module?
Great, I'm glad you've decided to pick up the torch! I was going to help with the Godot networking stack, but I've become to busy with other things. So, if there's any questions you want to ask pertaining to network programming in Godot (or Juan's unreasonable expectations), don't hesitate to ask and I will do my best to answer. I will leave this issue open for that purpose.
As for this module, it's currently only being maintained and is not under active development. Juan does NOT want to include ENet (the module this is based on) in Godot proper. The reason for this is that this module only works for UDP and there may be other protocols (e.g. for game consoles) that might need to be supported in the future (Bluetooth maybe?).
The new stack cannot use the raw socket interface because it will not support proxies on Android - this needs to be implemented in JAVA. Juan also wants the new network stack to seamlessly support stream based protocols (TCP) and packet based protocols (UDP), where the packet based protocols can handle pinging, connections, sequencing, and reliability as in ENet. He also wants RPC calls on scene tree objects (good luck!).
My advice is to start by creating a module and design an interface that works well with TCP and UDP, and write your own abstraction for the network interfaces. I would also suggest that you use a client/server model rather than peer to peer as this significantly cuts down on the complexity. Also, have a look at the code for PacketPeer(UDP) and StreamPeer(TCP) as they contain good examples of techniques used in network programming (e.g. lock-free ring buffers).
When you have all of that working, then bring it into Godot proper and start working on RPC (again, good luck... but I may have some ideas once you get that far).
Hope this helps!
What's ENet capable of itself? does it support TCP too or only UDP?
And asking your opinion from the user's point of view, how would you chose what protocol to use? Abstract is ok, but at some point the user mur have ocntrol of what's he using, this means a protocol must be used by default. I've thought on some ways Networking may be implemented:
-Nodes in the scene tree, traking, sending, retriving and setting the values of selected properties in especified nodes
-Method overloads to push and pull values on every stream phase
-All Child's of the "NetworkView" node have it's properties streamed completely and only procesed on the "Owner's" machine and reflected on the others (this is completely utopic, it needs some filtering somehow, because you can't pretend to stream all fransform animations positions, same happens when you call a function, sometimes you will want this very same function be called in the other player's computers)
I'm listening sugestions on the workflow the user may expect, GdNet module is awesome by itself, but it's still a little low level, like HttpClient class, and lacks signals to connect, because it's not a node or a resource (as long as i saw on the example)
Most importantly, how would an used select what protocols to use?
TcpClient node? UdpClient node? BluetoothClient node?
NetworkClientNode with a Protocol propertie?
How to bind clients to connections?
probably best choice are NetworkClient, NetworkConnection and NetworkServer nodes, this way the NetworkConnection and NetworkServer handles the ProtocolStack and NetworkClient's just bind to the NetworkConection they want to listen and write, but still, how should the stream travel beatwhen client and server? how do i select what NetworkClient send an specific stream? (i mean a byte array or a dictionary or whatever)
I'm all ears :P
Hi! Sorry, I've been really busy for the last week and haven't had a chance to respond until now.
I think your idea of a "NetworkView" is a good idea and could be used to attach a client or server instance to the SceneTree which would make RPC a possibility.
You will still need to support low-level network operations. I would suggest you have a look at my snapshot interpolation and state sync demos. Those are demos of how to implement networked physics, which is used in lots of games. Even these demos send variants over the network without compression (compression is why I wrote my raw packer module) which would certainly bog down the server, and perhaps the clients, in a large simulation (i.e. one with many interacting bodies). I would suggest browsing through Glen Fiedler's site (http://gafferongames.com/) before you implement anything as he is one of the foremost authorities on game networking.
I think having TcpClient, UdpClient, and BluetoothClient objects (not nodes) is a good idea, provided that the packet based protocols (UDP, and Bluethooth for now) have the ability to support pings, connections, sequencing, and reliability. If you need some basic algorithms for these features, I would be happy help if I can.
I'll start with Glen Fiedler's web page for now, i have studied the networks matter in general, but have not seen anything yet aimed to games and how to manage streams.
I'll talk again in some days if i make a discovery or need any help or if (hope not) i'm just clueless...
I think studying Fiedler's stuff is a great idea. I acquired most of my game networking knowledge from him. I think he also has some tutorials about game physics which is good to know a little bit about if you plan on implementing networked simulations.
Let's keep the lines of communication open. It's always a good idea to have someone to bounce ideas off of.