• Advertisement
Sign in to follow this  

[.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.

If you intended to correct an error in the post then please contact us.

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 this post


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

Share this post


Link to post
Share on other sites
Quote:
Original post by Toolmaker
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

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 this post


Link to post
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 this post


Link to post
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]

Good luck with your project.
theTroll

Share this post


Link to post
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:
http://code.google.com/p/lidgren-library-network/

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

Share this post


Link to post
Share on other sites
Quote:
Original post by Toolmaker
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.


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

theTroll

Share this post


Link to post
Share on other sites
Quote:
Original post by Toolmaker
I want UDP because it's connectionless.


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

Share this post


Link to post
Share on other sites
Quote:
Original post by Toolmaker
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.


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 this post


Link to post
Share on other sites
Quote:
Original post by TheTroll
Quote:
Original post by Toolmaker
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.


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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Toolmaker
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.


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 Toolmaker
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.


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 this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement