Several questions after getting basics going

[Moon Wizard]

After working with several network libraries, I liked TNet's ease of getting going. It's helping me get our prototype up and running more quickly from the networking side. Given that, I've got my eye on the next set of networking items I need to address, and wanted to get some feedback on the whether TNet can be set up or customized to help, or any suggestions on alternatives that can work alongside.

We have software where one player is the authoritative server, and all the other players connect to the master player instance. The interface is very Windows-like, unique to each user, and dynamically generated; so we don't have any synchronized network objects. All communication is done via custom message passing using RFC over a command channel. Also, we need to be able to transfer digital assets between server instance and player instances, and vice versa. This is done via an RFC over an asset channel. I've currently got this part working.

So, to the questions:

1. Can TNet be configured to accept both IPv4 and IPv6 connections? (I have concerns that people only on IPv4 internally on their LANs may not be able to connect to an IPv6 only server. Or maybe someone more network fluent can correct my view.)

2. Are the channels in TNet considered reliable? (i.e. as long as connection maintained, messages will retry until delivered or connection ends.)

3. Is the data in TNet channels delivered sequentially? (i.e. Data is received in order sent.) (I assume this might be different between TCP and UDP servers, but not sure.)

4. Are channels and/or RFCs handled separately for balancing throughput (or QoS)? (i.e. if one channel is very busy/full/blocked, messages to the other channels are still being interleaved and delivered.) (We would like file asset transfers to not block command channel.) (Eventually, we might look to streaming music/video/etc through another channel.)

5. We are looking to set up a facilitator server to handle NAT traversal by exchanging IPs/ports, as well as provide some basic presence and game tracking services. Is this something already built into TNet, or any suggestions? If so, best place to see examples. (Already aware of built-in UPnP for IPv4. We have this in a current product, and we need simpler user connections.) If so, can this be done for both IPv4 and IPv6?

My apologies if I missed some of this stuff in documentation or examples, and appreciate pointers to existing material. Thanks to anyone who can offer some insight.

Regards,
JPG

[cmifwdll]

1. Not simultaneously. You can launch the server in ipv6 mode with a commandline argument, otherwise it'll launch in ipv4 mode. Dual-mode sockets are weird. Unity doesn't currently support dual-mode sockets anyway (the socket option doesn't even exist in the runtime).

2. TNet uses TCP by default, so yes. TNObject.SendQuickly uses UDP which doesn't guarantee anything. TCP doesn't retry forever, though. There's a max retry option. I think it's controlled by the OS. You'll never need this.

3. TCP guarantees this. UDP does not. Packets are always processed in the order they're received.

4. No, but the server loop goes like this: pending connections are processed, *all* UDP packets are processed, up to 100 packets from each TCP socket are processed, timed out connections are killed.
If you're getting stuck somewhere I'd look at limiting UDP processing to 100 packets each loop. In 99.99% of cases you won't need to know this loop at all.

5. Presence & game-tracking (if I'm understanding you) is built-in via lobby servers.
TNet doesn't provide NAT traversal. If you need to implement hole-punching I'd suggest modifying the lobby server.
This is only necessary when the *server* is behind NAT though. From everything you've said so far it sounds like you're planning on having your game servers running on actual servers, so this won't be the case.

[Moon Wizard]

Thanks very much for the answers so far. I have a couple follow-up questions, if you can help.

1. I'm not sure if this is an issue; I'll have to do some more research on how how networks talk to each other when IPv4-only network clients go to Internet. If I need both, could I start two server sockets listening on different ports (one for IPv4, and the other for IPv6)?  (I'm thinking because of "static" attributes of some objects, I might need to clone TNet namespace; or otherwise customize the server code to support multiple sockets.)

2/3. Glad to hear that. I thought that was the case, but didn't want to assume.

4. It sounds like channels are not balancing data transfers, so I might need to get creative here. (like add yet another server socket, modify the code or balance the channels myself) (i.e. I'm worrying about 100 packets being loaded for an asset transfer, and a couple command packets get stuck behind.) All the connections are currently TCP connections. Any ideas?

5. Actually, there are not any Internet-based servers planned, since our product can run on closed networks. We only have plans for Internet servers to support lobby and NAT. It sounds like I'll need to customize the lobby code.

Thanks,
JPG

[Moon Wizard]

After talking with a couple others, I've been considering another approach as well. (local hosted and cloud relay) This would require the ability to host and connect to a room on a locally hosted server, and make a client connection to a cloud server and connect to a separate room there.

Does TNet support multiple client connections to different servers? (Well, at least 2.)

Thanks,
JPG

[cmifwdll]

1. My network knowledge is slipping so quickly - you lose it if you don't use it, etc -  so I'm really fuzzy on this, too. I think most ISPs have some sort of tunneling mechanism for ipv4<->ipv6.

Your idea of using 2 server sockets is something I've thought about, too. I'm not sure if it'd be that easy, though, as I'm sure ArenMook would've done that by now you'd have to modify the client, lobby server, and game server to support this, though. The server would need to supply its ipv4 and ipv6 address and port to the lobby server. The lobby server would need to send this to the clients. The client would need to determine which address family to use and connect to. Then, like you mentioned, state synchronization on the game server might have some challenges.
Or maybe not? The server listens for connections via .NET's TcpListener. When a connection is accepted a TNet TcpPlayer (inherits from TcpProtocol) object is instantiated and handles receiving from that socket. I think TNet's TcpProtocol is IP-agnostic? At least as used by the server. So if you just set up 2 TcpListeners (ipv4 and ipv6) and accept connections from both, you should be able to keep the single list of TcpPlayer's and not have to modify anything else on the game server (except for pushing both ipv4 and ipv6 endpoints to the lobby server).

4. I'd suggest implementing it and seeing if it's an issue first. If it is actually an issue, I dunno. Is it feasible to package & distribute the assets with your game? If not, could you cache them on each client for a long period of time?
Actually, I don't think it's a concern. 100 packets are *processed* each loop. The loop is very fast, and processing is very fast. Outbound packets (responses to processed packets) are placed in a queue. This queue is read from in the OnSend socket async callback thingy, so I don't *think* it impedes the processing thread. So it should be limited by the speed of the server's connection (which is the best case scenario). To summarize: I believe it's possible that the 101st packet could be *processed* even if the response to the 0th packet hasn't been *sent* yet (though such an extreme scenario will probably never happen).

5. I should clarify: UPnP does eliminate the need for holepunching when it works, and TNet attempts to use UPnP by default.

6. Client can only connect to 1 game server.

[Moon Wizard]

Thanks again for the answers.

With regards to UPnP and hole punching, the problem we're seeing is that the EU providers are moving to multi-level NAT64 setups, since they're out of IPv4 addresses over there for residential use. Our users are having to use VPN solutions to bypass in those cases.  I think the combo relay/local option might be a good workaround, if I can get multiple connections to work.

For multiple connections, I've been looking at the code, and I think I can get it working by cloning TNManager for my situation.  I'm going to be checking that out for a bit.

By the way, my thanks to ArenMook and team for well-written code; it was easy to drill in and understand what each class is doing.

Cheers,
JPG