[gameprogrammer] Re: Multiplayer networking advice

["Taylor Peterson" <assbone@gmail.com>]

Wow thanks for all of the replys guys.  It's helping me a ton.  I
might ask a few more questions as I do more and more research and
coding.

> As for your image - why host it via a URL? Instead the client could
> (optionally) upload it as part of the login procedure. If you choose
> to use a database, the client could have their image stored on the
> server along with username/password.

I'm a bit worried about putting a big load on outgoing bandwidth.  :-|
 Although, I probably worry way too much about stuff like that.

Thanks,
Taylor

On Jan 28, 2008 5:51 AM, Brian <brian.ripoff@gmail.com> wrote:
> Threading can be too complicated for this kind of scenario. On a
> webserver each request is independant, so there is little reason not
> to use threads. In a game you would have to implement locking etc to
> prevent memory corruption or other concurrent programming issues,
> which will take more time and probably be slower than the alternative.
>
> The alternative is to use a function like select() on a group of
> sockets. This way you can tell which sockets you can recv() from
> without stalling your application. Another alternative is to set the
> sockets into non-blocking mode, in which case calling recv() on them
> will return immediatly if there is no data ready.
>
> Both of these scale better than threads for such an application, would
> be my guess. It depends on how many clients you want to serve
> simultaneously.
>
> Using UDP you only need a single socket, making the above slightly
> easier should you choose to go that route.
>
> Do consider using a high-level UDP protocol, not just "raw" UDP. There
> are a few libraries available which implement optional reliability and
> ordering. For example, chat could be reliable and ordered, movement
> could be reliable (and you manually discard out of order movement
> commands) etc. UDP usually delivers less latentcy, so is a good option
> to consider. On the other side, if you end up making every message
> reliable and ordered you probably should opt for TCP, since it does
> that anyway but also handles congestion in a more network friendly
> way.
>
> As for your image - why host it via a URL? Instead the client could
> (optionally) upload it as part of the login procedure. If you choose
> to use a database, the client could have their image stored on the
> server along with username/password.
>
> Be very careful writing code that accepts variable length data from
> the client - for example strings or raw binary data (like the image
> above) not to write buffer overflows. When I last wrote a server in
> C++ I found using the varous dynamic data structure in the Standard
> C++ Library to be invaluable (compared to using raw char arrays as
> demonstrated in your doc :).
>
> On 1/28/08, Alan Wolfe <alan.wolfe@gmail.com> wrote:
> > Multithreaded server
> >
> > If you haven't ever done anything with threads you may want to for the
> > server.  A model that web servers etc use that I've also used for
> > games with pretty decent success is this...
> >
> >  Have 1 main thread that is in a loop like this:
> >
> > while(GameRunning)
> > {
> >    while(NewConnections())
> >        AcceptNewConnectionAndSpawnNewThreadsForIt();
> >
> >    sleep(500);
> > }
>
>
> ---------------------
> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>
>
>

---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html