2

I'm working on an online turn based card game for the PC. It features a lobby which will automatically update the list of active games so I'll be sending many updates to many clients. I will have a game server for this. Lag is not too big a deal for me, if players have to wait an extra 1/4 second sometimes until their card is shown, it dosn't really concern me. What concerns me is reliability and stability. I want to be able to host many 4 player games, I also allow people to watch a specific game too.

I also will need to log them in, and remember their session if they disconnect so they can get back in the game if they get disconnected.

What I am debating is if I should go with Enet which is UDP based with reliability, or plain old TCP/IP.

I will eventually need to be able to send them additional content created such as extra decks which will be in the form of a zip file. But for that I'm sure there is a library that could help me get these from an HTTP source.

If anyone has experience with either or both of these, I'd appreciate your input.

Thnks

jmasterx
  • 52,639
  • 96
  • 311
  • 557
  • The session management you're talking about would definitely make me lean towards TCP/IP. But I lack the familiarity with Enet to posit a more confident answer. – Michael Wilson Apr 09 '12 at 14:18

2 Answers2

2

I'd stick with classic TCP, not some library that has hacked in correct ordering and packet delivery reliability into a protocol not designed for it.

Enet's claim is to have a few of the benefits of TCP, while delivering speed for "real-time" games. That phrase makes me think of FPS, which isn't your app at all.

Lynn Crumbling
  • 12,985
  • 8
  • 57
  • 95
  • 1
    I agree and since you don't care much about speed, there's no motive for using UDP based library. – vidit Apr 09 '12 at 14:21
  • 1
    It's not fair to call projects like Enet hack jobs. "Clasic" TCP is just another protocol built on top of IP. UDP has very little difference when compared to basic "raw' IP packets and was meant specifically to provide a mechanism for building higher-level transports. – JSON Jun 20 '22 at 18:29
0

I haven't worked with ENet, but I had a quick read of it's documentation, and it seems like it could be useful in certain circumstances.

First question: Do you need a reliable packet delivery mechanism, or is unreliable OK? ENet can do reliable, but at that point it's getting kind of similar to TCP, and unless you need it's multi-stream support, I'm not sure it's worth fooling with.

If unreliable is OK, then the next question is: do you need the packet fragmentation support that ENet has? If your packets are going to be small, then I'd say just use UDP directly.

I'm unclear on how ENet uses UDP sockets and how it manages connections, so I'm unclear whether you're better off with lots of open TCP sockets or lots of open ENet connections.

Michael Kohne
  • 11,888
  • 3
  • 47
  • 79