# [.net] .NET network library?

This topic is 3727 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm currently in the process of looking into a network library for my C# game. My initial thought was using RakNet, but after I checked, there is no official RakNet .NET binding. I'm looking for a network library that supports both TCP and UDP. For UDP is must ensure that my data WILL arrive, and that it will arrive in order. It's pretty important that the data is ensured to be delivered. I did some googling, but there's a massive amount of libraries, so it's pretty difficult to narrow down which ones are good, and which ones provide a good API. Toolmaker

##### Share on other sites
What's wrong with the .NET networking libraries?

##### Share on other sites
Ok, you want guaranteed, ordered delivery for UDP ... so why don't you just use TCP?

##### Share on other sites
Quote:
 Original post by ToolmakerI'm currently in the process of looking into a network library for my C# game. My initial thought was using RakNet, but after I checked, there is no official RakNet .NET binding.I'm looking for a network library that supports both TCP and UDP. For UDP is must ensure that my data WILL arrive, and that it will arrive in order. It's pretty important that the data is ensured to be delivered.I did some googling, but there's a massive amount of libraries, so it's pretty difficult to narrow down which ones are good, and which ones provide a good API.Toolmaker

UDP with garaunteed, ordered arrival of packets is exactly TCP. TCP is built on top of UDP for the very reason to provide it with garaunteed, ordered arrival of packets.

Check out the System.Net and System.Net.Sockets namespaces. They are very featureful. They are not just a simple wrapper of WinSock.

##### Share on other sites
I want UDP because it's connectionless. When the host is being dropped, it's much easier to maintain connections to the other clients. I'm making an RTS, so having connectionless connections is an added pro. UDP also has the added goodness that the opened tunnel stays open for a while in a NAT environment. Players don't have to open ports to play the game, except the player that hosts the initial connection.

However, during my research on RTS games in a networked environment, I ran into the "1500 archers over 28.8K" article on Gamasutra. One of the things they mentioned was UDP and garantueed delivery. However, it might be a good idea to drop the demand for delivery in order of sending. But, I want garantueed delivery.

Toolmaker

##### Share on other sites
I ask again: What is wrong with the built in networking classes for .NET? They handle UDP and TCP. You can mix and match.

##### Share on other sites
[opinion]
If you care about guaranteeing order and delivery then there is no reason not to go with TCP. Anything you code for UDP that does that will be slower then just using TCP in the first place. That is not a slam against you, I don't know of anyone that could do it. If you really do care about that, then just use the "correct" protocol for what you are trying to do.

For the NAT issue, just look up "TCP" and "NAT punch through". It is pretty easy.

[/opinion]

theTroll

##### Share on other sites
The problem with TCP is that you cant have non-garanteed packets. Thats why there are libraries for garanteed UDP packets.

Look here:

I havent used this library yet, but it looks very good.

##### Share on other sites
Quote:
 Original post by ToolmakerI'm looking for a network library that supports both TCP and UDP. For UDP is must ensure that my data WILL arrive, and that it will arrive in order. It's pretty important that the data is ensured to be delivered.

If you read the OP, he wants guaranteed delivery. So why use UDP?

theTroll

##### Share on other sites
Quote:
 Original post by ToolmakerI want UDP because it's connectionless.

If you read the OP, he wants UDP. So why use TCP?

##### Share on other sites
Quote:
 Original post by ToolmakerI want UDP because it's connectionless. When the host is being dropped, it's much easier to maintain connections to the other clients. I'm making an RTS, so having connectionless connections is an added pro. UDP also has the added goodness that the opened tunnel stays open for a while in a NAT environment. Players don't have to open ports to play the game, except the player that hosts the initial connection.

He wants UDP because he doesn't understand TCP. It is very easy to maintain connections when a TCP client drops. As for the NAT issue, that is really a non-issue. So he really doesn't want UDP he just thinks he wants UDP.

theTroll

##### Share on other sites
Quote:
Original post by TheTroll
Quote:
 Original post by ToolmakerI want UDP because it's connectionless. When the host is being dropped, it's much easier to maintain connections to the other clients. I'm making an RTS, so having connectionless connections is an added pro. UDP also has the added goodness that the opened tunnel stays open for a while in a NAT environment. Players don't have to open ports to play the game, except the player that hosts the initial connection.

He wants UDP because he doesn't understand TCP. It is very easy to maintain connections when a TCP client drops. As for the NAT issue, that is really a non-issue. So he really doesn't want UDP he just thinks he wants UDP.

theTroll

Actually, I do understand how TCP works. However, I basically don't need garantueed order of sending, but I do need garantueed delivery. The problem with TCP is that when 1 packet is delayed, everything that's after it is delayed aswell.

With UDP, this isn't(Without garantueed order delivery) the case. If 1 packet is too late, the orders might just arrive.

I based my demands upon the AOE / AOE2 networking postmortem, which used UDP and mentioned garantueed delivery(including order). Altho garantueed ordering isn't really needed, the article mentioned it. But, I assume this was a mistake on their side, because earlier they mentioned that packets arrived for a previous or current turn would be dropped.

However, TCP does allow NAT punchthrough, from inside -> outside. Not the other way around. If I want my game to use a P2P star-topology, all players will have to open their ports in order to play the game. With UDP this isn't the case(Try playing AOE / AOE2, only the host will need to open the ports).

The answer to the question on WHY I want to use a 3rd party library: I don't want to be building my own layer around UDP, nor want to be building a system for either re-sending packets or ACKing for their arrival. Ofcourse, I could do this, but I see no reason as to why I should re-invent the wheel. Important is, that if a packet times out(say, 100ms), it will be re-sent even without a "I missed packet xyz" confirmation.

Toolmaker

##### Share on other sites
Checkout the Lidgren network library already posted. Really nice imho. Supports reliable ordered, reliable unordered, unreliable ordered, or unreliable. Pretty easy to use as well.

I preferr UDP over TCP just because it's package based accutually. When using TCP, I usually end up emulating packets anyway. Also, doesn't TCP have way bigger overhead than UDP anyway (in bytes that is)?

##### Share on other sites
Quote:
 Original post by ToolmakerFor UDP is must ensure that my data WILL arrive, and that it will arrive in order. It's pretty important that the data is ensured to be delivered.

That is the reason I said TCP was the way to go. UDP with ordering and guaranteeing that it arrives would do the same thing that TCP does.

The only .Net lib for Networking I know about that would do what you are looking for is SocketWrench .Net, but that is $195.00 for a license. theTroll #### Share this post ##### Link to post ##### Share on other sites Quote: Original post by TheTroll Quote:  Original post by ToolmakerFor UDP is must ensure that my data WILL arrive, and that it will arrive in order. It's pretty important that the data is ensured to be delivered. That is the reason I said TCP was the way to go. UDP with ordering and guaranteeing that it arrives would do the same thing that TCP does. The only .Net lib for Networking I know about that would do what you are looking for is SocketWrench .Net, but that is$195.00 for a license.

theTroll

I came back from my original demands, so that's not longer an issue. I'll try the earlier mentioned lidgren lib. It looks what I need.

Toolmaker

##### Share on other sites
I believe this article has some valid points as to why not to use tcp.

I'm kind of wondering this as well, but am looking to target mono, which lidgren doesn't seem to support, and it'd be nice not to have to reinvent things if I don't have to(ENet and Raknet work fine in C/C++)

##### Share on other sites
"TCP is evil. Don’t use TCP for a game."

I can't believe I just read that in an article without any "just kidding!" after it. Goes to show that you never want to use just one source for information when it comes to the internet. TCP works fine for certain games. Tile-based RPG, older RTSes, turn-based. I'm using TCP right now for a platformer MORPG with no problems (of course, have to test it under high stress still).

"Also, doesn't TCP have way bigger overhead than UDP anyway (in bytes that is)?"

TCP header is 20 bytes, UDP is 8. Thats just for the protocol, though - theres more to packet headers like the IPv4 header which is 20 bytes.