zpostfacto
commented
3 years ago 1: Connections are encrypted by default using a TLS-like handshake. HOWEVER, without a public key infrastructure, there really is no protection against man in the middle. This is just fundamental to networking, it's not specific to this library. Another option would be for the peers to somehow share the session AES key ahead of time through a trusted channel, and not use DH key exchange to derived the session key. There's not an API for that right now, but it probably could be added. There are existing mechanisms for the certificate infrastructure. But that stuff is just unavoidably complicated, depending on your threat model. (E.g. does your threat model include a malicious client who can get inside the process, or does it only include malicious guys trying to peek in from the outside, or do they have the ability to interpose, etc.) So that's a long way of saying that yes, right now connections are encrypted using a TLS-like mechanism, with only one encryption alg supported (25519 keys for signatures and key exchange, AES-GCM-256 for packet encryption). That is definitely good enough to protect against casual eavesdropping. But it is not sufficient to protect against MITM.
2: It depends on the type of connection and data rates, etc. We do have a partner who has created hundreds of P2P connections, which are more expensive than direct UDP connections. So I think it should be fine. Certain patterns are more efficient than others, of course. For example, using poll groups is much more efficient than iterating a long list of connections polling for messages.
3: This code has been ported to android and ios before. It's been a while, so something has probably atrophied somewhere, most likely with some dependency like openssl or protobuf. The low level socket stuff is really very thin wrapper on BSD sockets, so that probably still is good. I really would like to get the CMake configuration to just work for ios and android -- see issue #102. When it was ported before we just had custom makefiles for android and ios.
4: We don't really maintain any bindings. We just provide the plain C "flat" interface. So I can't really say if the bindings can be updated.
Hello,
I’d like to ask a few question, sorry if the questions sound stupid, I am a newbie.
Question 1 : I would like to ask is if the connections encrypted? Let’s say a C++ client uses ConnectByIpAddress to a golang server of mine which is using the Go binding of this library, is the communication encrypted once the connection is established? I know the readme file said Encryption but I wanted to make sure, as we may have some trading system.
Question 2 : How many max connections can this library handle? Let’s say I’m building an light PvE multiplayer game where not every position is updated every second, more so like every few seconds during a battle where the client sends the input and the server calculate what happens. (More like a medium paced turn base game. Higher Latency is tolerable as long as it’s not ridiculously high, eg: 5000ms+) Simple input, no collision calculation, no position calculation, only calculates hp, mana, damage etc and sends it back to the few client (2-3 not everyone in the server) in the same server. The server will be a Golang using Go bindings for this library and the machine will be a 8 core 16gb ram. The server will also be frequently (15-35 per second peak maybe 50 per second) accepting new connections as player joins their own “room”. We have a load balancer configured infront of our servers, but would like to spin up as few server as possible as we don’t want to manage too many servers at once. TLDR : are they suitable for extremely lightweight MMO hoping to achieve 5000-10000 concurrent connections? Could I get please get a ballpark of the figure?
Question 3 : Can I cross-compile this lib to Android and iOS? Are there any platform-specific dependencies I should be aware of?
Question 4 : Any plans to update the Go Binding of the library? The binding is unmaintained since last year as far as I know.
Any reply is appreciated! Thank you in advance!