Are the players logically grouped - do they group around virtual
	tables or rooms? If so, then one thread (or even process) per
	room would make sense, with each thread/process syncronising
	when players move tables. Seperate processes would even allow you
	to distribute it across multiple machines.

	Bear in mind sooner or later everyone is going to try to join
	the same table Just Because... so plan for that (table limit
	is probably easiest).

	It may just be easier to go with poll() and have a single list of
	all players - bearing in mind you can guarantee round robin
	behaviour, which is probably what you want.

		David/absolute		-- www.netbsd.org: No hype required --


On Thu, 15 Feb 2001, Erik Huizing wrote:

> Right now, I'm bound by non-disclosure agreement not to reveal the
> specifics, but I can say this: its like an online casino where the players
> can compete against each other. I need to have potentially a thousand or
> more simultaneous open sockets at a time.  I origianlly started with a
> java application, but it coudln't handle the numbers I needed, so I'm
> rewriting the whole thing in C. What I was thinking of doing was having
> maybe 10 or 20 threads each listening to 50 to 100 sockets (using an
> fd_set and select). Is this a good way to go, or is there a more efficient
> way?
>
> The first rule of Fight Club is You Do Not Talk About Fight Club.
>
> // Erik Huizing   huizing@cpsc.ucalgary.ca
> // www.cpsc.ucalgary.ca/~huizing
>
> On Tue, 13 Feb 2001, Jeremy C. Reed wrote:
>
> > So if I understand you (and this) correctly, it looks like using syslog is
> > the correct way and using syslog wouldn't be reinventing the wheel.
> >
> > Tell us more about your project.
> >
> >    Jeremy C. Reed
> >    http://www.reedmedia.net/
> >
> >
>
>