What network library is the best?

[3ddev]

Hi! I need network library in my game. However, I preferably want one that is released totally opensource ( i.e. not RackNet, since you need a license to sell commercially ). I am not planning to make any games in the future which I might sell. However, it is nice to learn only one library and not a dozen later. I really liked the looks of Enet, but it doesn't support Mac Os. I also really would like a platform indepentdant network library. What library would work best for my needs?
(NOTE: I like the UDP protocol for games the best, since it is so fast! )

[Spintz]

UDP is not a network library, it's a network protocol ( Unreliable Datagram Packets ). Unless there's a library I don't know about that is called UDP.

[BlindSide]

Another opensource worth trying is Ziglite, it uses a UDP connection with only one port open so it is good to by pass NAT.

[Luke]

I can see what’s so bad about raknet

“are only required to pay when you ship your product” (commercially)

“you choose how much to pay based on what you can afford”

Come on, that’s got to be the coolest commercial library I’ve ever seen.

I don’t see how you cannot afford pay any money when you are selling your game?

[stef_]

You have not read the next phrase:

Choose what to pay based on what you can afford by the value RakNet has brought to your development. If you can only afford the minimum we appreciate that.

The minimum is 100$.

Bye

[trooper]

WOW,

This could be a very in-depth topic

Well to start here is a quote from the GameDev Forum:

TCP is a reliable protocol. Although this sounds like I'm paying it a compliment, it can be a bad thing for games.

Reliable means that the packets you send are received in the same order. If you send packets:

X -> Y -> Z they are received as X -> Y -> Z

This is great for chat/communication, but horrible for just about anything else.
In UDP packets are received in the order that they arrive. Which is great for movement, or actions, because the last action is less important than the current action. You can mitigate the problems with out of order sequences on UDP very easily, simply by queuing the messages as they arrive, and then re-requesting those that didn't make it. Once your packets are ordered, then you can process them.

Unfortunately there is no mitigation for the reliability of TCP. If a packet is dropped, then no new packets will be accepted until the missing packet arrives. This can cause a great amount of perceived lag. Have you ever played a game where you are moving your sprite, and then all of a sudden you stop moving, so you keep hitting the forward button. Then, all of the sudden your sprite bursts into a fast-forward sprint. This is because the movement packets were sent with TCP.

I would strongly suggest that you use a network API that mitigates these problems for you. Most of them do. I see no feasible reason to use TCP, except to be lazy.

With that said, you have to way up many factors and priorities.

Firstly, I understand the need for knowledge and future experiance, but as you say you don't plan on releasing a game.
With that in mind way up the factors that mean most to you.

Do you care about reliability, speed, maximum number on connections (clients) and No.1 has got to be security.

Some will disagree, you may release a game, and get the odd lag, or you have a maximum of 32 clients, or what ever the limitation is, but you will get slammed by the industry and critics, if you have security issues

Let's face it, we all hate Microsoft & Bill Gates, and any other product that causes us problems with security.

I'll be keeping an eye on this thread, as I'm sure it will spark MUCH debate hee hee

Happy Holidays Friends

[trooper]

Just for information

A quote from the Author of "Game Server Programming":

The most commonly found advice that I would suggest (after "use eNet") is: "Use TCP until the point where it causes your game to not work properly; then investigate UDP". If you have a game that will definitely need UDP and you know it, then you just have to bite the bullet and enter the world of low-level protocol debugging (not fun). Despite what I said above it's far from impossible to get it right, it's just painful and dull.

http://enet.cubik.org/
eNet License:

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.