So I've read the faq and some other posts and I've got a question. It seems to me that the arguments against each client connecting to each other client include: 1. o(n^2) connections vs. o(2*n) connections (and the related bandwidth) 2. Easier cheating (no central arbiration) and generally people say that for yoru run-of-the-mill multiplayer shooter, people should go through a host. However, if I'm making an game for a course project, and thus won't be releasing it to a large market, then there would be very little chance of cheating (2) and if I'm in a lan only to test this game then the bandwidth isn't that big of a deal (1). I agree that the server/host should be in charge of some things (such as when a round ends, joining/leaving the game, timing lag, etc.,) but should all communications go through the host? particularily, I was considering sending position/orientation updates to players directly, as well as I've-Hit-You-You're-Dead messages. I would've figured that the reduction in trip time would be more important than efficient bandwidth. Also, on a related question, is there a limit to the number of sockets I can open? How about opening both a TCP and a UDP socket to the same client? Thanks.

If you don't care about cheating and you'll only play on LAN... pretty much anything works, don't worry about reductions in trip time or bandwidth - just do what you find easiest. Server/client are easier to reason around, at least in my humble opinion.

Quote:Original post by whiterook6
I agree that the server/host should be in charge of some things (such as when a round ends, joining/leaving the game, timing lag, etc.,) but should all communications go through the host? particularily, I was considering sending position/orientation updates to players directly, as well as I've-Hit-You-You're-Dead messages. I would've figured that the reduction in trip time would be more important than efficient bandwidth.

It looks like you are confusing the network topology with the role of each machine.

Your game has a virtual network across the Internet. The topology of your network is how the packets move from computer to computer.

If everybody is talking to a central machine and that central hub redirects the packets to their target, that is a star topology. If every machine can talk with every other machine directly, you have a fully connected mesh. If machines can talk to each other with ad-hoc connectivity and you can pass packets along a from machine to machine until it gets to the destination, that's a partial mesh.

Exactly how you manage your virtual network is up to you. A partial mesh is the most work but most flexible in the real world. It allows for limited connectivity and can be written to reduce overall bandwidth requirements. A star is a medium amount of work because you still must look at the headers and redirect as necessary, but it doesn't handle the possibility that one or more machines cannot connect to the hub, and it also requires higher bandwith requirements on the central machine. A fully connected mesh is the least work to use because you have direct communications, it minimizes bandwith needs, but is the highest risk in a real-world network environment if any connectivity fails.



Regardless of how your packets are flowing between machines, you can make any machine can act as the authoritative simulation.

You generally want the authoritative machine to also be the best connected machine in the network. In a star, the best connected machine is the hub. In a mesh or partial mesh, the best connected machine is the one with the most connections and also the highest bandwidth.

Quote:Also, on a related question, is there a limit to the number of sockets I can open?

Yes, but you are unlikely to reach it. It varies based on the platform. On a *nix box, the number is in /proc/sys/fs/file-max, and it is most likely in the hundreds of thousands, or even in the millions. (My server box says almost 1.6 million.)

Quote:How about opening both a TCP and a UDP socket to the same client?

Not an issue. They are different protocols. They compete for the same network resources, but otherwise they can live together just fine.

Thanks guys--for the quick replies AND for not treating me like the nub I am.

Note: For Windows There are several limits that you can run into. The first limit is a compile time constant which is 64 by default. You can redefine it to more but after that you need to start checking what the system will support dynamically.

Quote:Original post by stonemetal
Note: For Windows There are several limits that you can run into. The first limit is a compile time constant which is 64 by default. You can redefine it to more but after that you need to start checking what the system will support dynamically.

I believe you are referring to the FD_SET size. That limit is only if you choose to use select() and related functions to wait for the sockets.

You can certainly use select() for small programs where you only have a small number of connections. If you advance beyond that very small number, which most game servers will do, then you need to use different methods that are more flexible.

Way back in the days of WinNT we could host around 5000 connections before starting to hit a performance issues. The issue there was memory and bandwith, not the number of sockets.

Quote:Original post by flodihn
Max number of sockets in an operating system is 65536 (think it is limited by the TCP/IP stack).

There is no real reason why an OS couldn't handle arbitrary number of sockets. It is also possible to have multiple network interfaces on same OS.

There is a historical precedent for this in form of eDonkey servers which had no problem handling hundreds of thousands (~300k+) of TCP connections on single CPU machines as far back as ~2004, with only limit being memory. Sadly, given the controversial nature of these servers, the article describing how it was done are long gone.

Quote:I have experienced that Ubuntu and Windows Vista limits max open files to 1024 by default.

Per process? Per thread? Per shell? Globally?

As far as sockets go, under Windows the number IIRC is limited by size of non-paged pool, which even on 32-bit machine should allow 100k+. On x64 there should be no realistic upper limit on number of connections.

In practice, Windows versions might put an artificial limit for different editions. Consumer versions tend (used) to be fairly restricted in this regard.

On Linux, upping the number of open files is a fairly trivial task, and 100k+ is typically not a problem. A bigger problem on Linux might be the socket API used to process these sockets.

This is different from FD_SET structure which can typically have 64 or 1024 connection limits, but this type of sockets isn't suitable for large numbers of connections anyway.

Quote:but I don't think UDP uses sockets

What does the SOCK in SOCK_DGRAM stand for :p

UDP usually uses a single socket to do all the communication, and they delegate remote address/ip pair management to user.
TCP handles those internally and exposes them to user via file descriptors/sockets.

A single IP address source will have a 32-bit remote IP address, a 16-bit outgoing port, and 16-bit incoming port. That's 64-bits worth of unique sockets coming from a single IP address. That's 18 PENTILLION unique values.

A single IP address connecting to a different single IP address with a single target port has only got about 16-bits of outgoing ports that it can assign -- roughly 64K connections between the two machines on a single port.

Factor in that a single machine can support an arbitrary number of IP addresses on a card, and an arbitrary number of cards. The *maximum* is extremely high.



The bottleneck is the resources on the computer, not the number of logical ports offered by the protocol. The operating systems just don't allocate the resources by default for more than a few thousands or tens of thousands.

If you want to get into the hundreds of thousands or millions of connections you will have to do some actual work. You will need to tell your system to allocate the resources for all those connections, and you will need to work with the system in managing those resources effectively.


As long as you stay below a thousand or so, it is fairly easy to work with. Some of the most trivial functions (like select() ) are not usable, but there are much more flexible listening techniques available.