Very Computer

by **Robert J. Sprawl** » Wed, 14 Oct 1998 04:00:00

Hi,
I'm working on a client/server space combat game for the internet,
and just got done reading a socket tutorial and FAQ. In both of these
documents, they show using fork() and creating a another process to handle
multiple users. If the game does well and I get lots of players, perhaps a
hundred or so, fork() may not be an option, since as I understand it,
fork() creates a similar child process. Hundreds of these would make IPC
really difficult, and possibly cause a severe CPU crunch

The players should be able to interact with each other rather
freely and with non-player combatants as well. It is possible to handle
multiple users without having to fork() a child process? Perhaps multiple
players per phoneline with a homegrown packet header with a player ID in
it? I have rudimentary documentation on my webpage if your interested in
reading what I am doing.

Tactical Dynamics http://home.att.net/~sprawlsr

by **Christer Enfo** » Wed, 14 Oct 1998 04:00:00

Quote:> The players should be able to interact with each other rather
>freely and with non-player combatants as well. It is possible to handle
>multiple users without having to fork() a child process? Perhaps multiple
>players per phoneline with a homegrown packet header with a player ID in
>it? I have rudimentary documentation on my webpage if your interested in
>reading what I am doing.

Yes, it's possible. If it's a real time combat game you're doing, take
a look at the UDP protocol.

--
-=-=- Christer "Floppy now, hard later" Enfors -=-=-

"I do my music in pure machine code using an assembler."
- Rob Hubbard

by **Bjorn Ree** » Wed, 14 Oct 1998 04:00:00

Quote:> freely and with non-player combatants as well. It is possible to handle
> multiple users without having to fork() a child process? Perhaps multiple

Use non-blocking sockets (fnctl() with O_NONBLOCK) and select() to
handle the connections.

by **Robert J. Sprawl** » Thu, 15 Oct 1998 04:00:00

> My approach is to try to distribute the server. This way the communications
> can be restricted to position and state data of the game objects between
> servers. The intense stuff, like graphics can then be kept to high speed
> LANs.

I intend to keep graphics local to each machine and have effects such as
explosions even driven. I'm hoping to keep packets under 50 bytes( not
including header ). The overall idea is done( just needs to be put into
words which I'm doing now ). The low-level stuff( message packets, events,
data structures ) are being worked on now as well. Gonna be awhile as I'm
also doing it in my spare time.

Tactical Dynamics http://home.att.net/~sprawlsr

by **bill davids** » Sat, 17 Oct 1998 04:00:00

| I'm working on a client/server space combat game for the internet,
| and just got done reading a socket tutorial and FAQ. In both of these
| documents, they show using fork() and creating a another process to handle
| multiple users. If the game does well and I get lots of players, perhaps a
| hundred or so, fork() may not be an option, since as I understand it,
| fork() creates a similar child process. Hundreds of these would make IPC
| really difficult, and possibly cause a severe CPU crunch

If you are running on a single machine, you might want to look at
message queues. Unlike multiple threads polled with select() a message
queue is a single data stream, with multiple reads and writers. This
opens the possibility of having multiple servers reading the queue on an
SMP machine.

I'm looking at doing this for the next rewrite of MBS (a sort of BBS
thing).
--

Never underestimate the power of stupid people in large groups

by **Dan Kege** » Mon, 19 Oct 1998 04:00:00

> | I'm working on a client/server space combat game for the internet,
> | and just got done reading a socket tutorial and FAQ. In both of these
> | documents, they show using fork() and creating a another process to handle
> | multiple users. If the game does well and I get lots of players, perhaps a
> | hundred or so, fork() may not be an option, since as I understand it,
> | fork() creates a similar child process. Hundreds of these would make IPC
> | really difficult, and possibly cause a severe CPU crunch

> If you are running on a single machine, you might want to look at
> message queues. Unlike multiple threads polled with select() a message
> queue is a single data stream, with multiple reads and writers. This
> opens the possibility of having multiple servers reading the queue on an
> SMP machine.

The technique I like is to use select() to handle lots of client file
descriptors. Go check out http://www.acme.com and look at thttpd. It's
a server that uses this technique. It has very low RAM requirements,
and handles zillions of clients well.

Another technique usable only for UDP services is to use a single
socket for all clients. I use this technique in production, but it's
kinda unusual to have a UDP service these days.
- Dan
--
(speaking only for myself, not for my employer)

by **David Suga** » Mon, 19 Oct 1998 04:00:00

Quote:>That statement is perhaps most true in business or science apps. However,
>I think in real-time client/server games UDP is more prevelant. Most UDP
>packets are used for positioning/orientation, and perhaps gunfire where a
>lost gunfire message packet is taken as blanks, duds, misfire, or a just
>plain miss. A lost, corrupted, or out of order packet now and then can be
>neglected without much loss to playability. TCP OTOH, is too slow for a
>comtinual stream of positioning and orientation messages, but just fine
>for occasional messages that MUST get through( radio talk, projectile
>fire, etc ). In non-realtime games, such as strategy board games, card
>games, chess games, TCP is probably the best ticket.

Actually, the problem with TCP is not one of speed. A TCP session can in
fact transfer (stream) data faster than a UDP session used for the same
purpose. The key difference is that if something goes 'wrong' with the
connection, it pauses in a flow control state, and it's often such pauses
that cannot be tolerated in specialized media streaming services.

I make some use of UDP in some server apps I write in part because I like
not having to tie up resources with additional sockets dedicated to each
client session, and in part because they are NEVER meant to be used over the
public internet, but instead within a local organization or even a single
server.

by **Robert J. Sprawl** » Tue, 20 Oct 1998 04:00:00

> The technique I like is to use select() to handle lots of client file
> descriptors. Go check out http://www.acme.com and look at thttpd. It's
> a server that uses this technique. It has very low RAM requirements,
> and handles zillions of clients well.

> Another technique usable only for UDP services is to use a single
> socket for all clients. I use this technique in production, but it's
> kinda unusual to have a UDP service these days.

That statement is perhaps most true in business or science apps. However,
I think in real-time client/server games UDP is more prevelant. Most UDP
packets are used for positioning/orientation, and perhaps gunfire where a
lost gunfire message packet is taken as blanks, duds, misfire, or a just
plain miss. A lost, corrupted, or out of order packet now and then can be
neglected without much loss to playability. TCP OTOH, is too slow for a
comtinual stream of positioning and orientation messages, but just fine
for occasional messages that MUST get through( radio talk, projectile
fire, etc ). In non-realtime games, such as strategy board games, card
games, chess games, TCP is probably the best ticket.

Tactical Dynamics http://home.att.net/~sprawlsr

by **Joerg Beye** » Tue, 20 Oct 1998 04:00:00

> The technique I like is to use select() to handle lots of client file
> descriptors. Go check out http://www.acme.com and look at thttpd. It's
> a server that uses this technique. It has very low RAM requirements,
> and handles zillions of clients well.

so your machine can have zillions of fd's open at the same time :-?
Is a zillion round about the same as 256?

just asking...
Joerg
--
There are two ways of constructing a software design. One way is
to make it so simple that there are obviously no deficiencies
and the other is to make it so complicated that there are no
obvious deficiencies. -- C A R Hoare

Very Computer

Development of multi-user servers.

Development of multi-user servers.

Development of multi-user servers.

Development of multi-user servers.

Development of multi-user servers.

Development of multi-user servers.

Development of multi-user servers.

Development of multi-user servers.

Development of multi-user servers.

Development of multi-user servers.