SDL Multiplayer Game

Hi,

How can I do a multiplayer game with SDL_net? My doubt is how can I do to
"create a game" in a server machine, so that all the other machines in the
same LAN can see the “game room” created, without specifying the host IP
adress, like Warcraft III or other games where you can play in LAN. I have
followed this tutorial:

http://www.breakersgambit.com/?p=24

that is like the chat tutorial that came with SDL_net, but in these cases
the host IP was explicitly specified.

Thanks!–
Yuri David Santos
Aleva Games
games.aleva.com.br http://www.aleva.com.br

In general, broadcasting. The client broadcasts a packet on the network. The
server would be listening for these type packets, and when it does, it
replies to the sender with “Hey, I have a game!”

PatrickOn Fri, Oct 21, 2011 at 3:27 PM, Yuri David Santos wrote:

Hi,

How can I do a multiplayer game with SDL_net? My doubt is how can I do to
"create a game" in a server machine, so that all the other machines in the
same LAN can see the “game room” created, without specifying the host IP
adress, like Warcraft III or other games where you can play in LAN. I have
followed this tutorial:

http://www.breakersgambit.com/?p=24

that is like the chat tutorial that came with SDL_net, but in these cases
the host IP was explicitly specified.

Thanks!


Yuri David Santos
Aleva Games
games.aleva.com.br http://www.aleva.com.br


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I set up this exact thing for the LAN play mode of tuxmath. Feel free to
look at our code if you like:

git://git.debian.org/git/tux4kids/tuxmath.git

The relevant functions are in server.c and network.c. I can’t promise that
it is world-class code, as it was the first network programming I had done,
but it works as intended.On Oct 21, 2011 3:30 PM, “Patrick Baggett” <baggett.patrick at gmail.com> wrote:

In general, broadcasting. The client broadcasts a packet on the network.
The server would be listening for these type packets, and when it does, it
replies to the sender with “Hey, I have a game!”

Patrick

On Fri, Oct 21, 2011 at 3:27 PM, Yuri David Santos wrote:

Hi,

How can I do a multiplayer game with SDL_net? My doubt is how can I do to
"create a game" in a server machine, so that all the other machines in the
same LAN can see the “game room” created, without specifying the host IP
adress, like Warcraft III or other games where you can play in LAN. I have
followed this tutorial:

http://www.breakersgambit.com/?p=24

that is like the chat tutorial that came with SDL_net, but in these cases
the host IP was explicitly specified.

Thanks!


Yuri David Santos
Aleva Games
games.aleva.com.br http://www.aleva.com.br


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi,

Thank you two. David, I would like to see your code, but how do I do that?
There are many directories… I have no idea what file I must to download.
Sorry for the ignorance (and my bad english).

2011/10/21 David Bruce > I set up this exact thing for the LAN play mode of tuxmath. Feel free to

look at our code if you like:

git://git.debian.org/git/tux4kids/tuxmath.git

The relevant functions are in server.c and network.c. I can’t promise that
it is world-class code, as it was the first network programming I had done,
but it works as intended.
On Oct 21, 2011 3:30 PM, “Patrick Baggett” <baggett.patrick at gmail.com> wrote:

In general, broadcasting. The client broadcasts a packet on the network.
The server would be listening for these type packets, and when it does, it
replies to the sender with “Hey, I have a game!”

Patrick

On Fri, Oct 21, 2011 at 3:27 PM, Yuri David Santos wrote:

Hi,

How can I do a multiplayer game with SDL_net? My doubt is how can I do to
"create a game" in a server machine, so that all the other machines in the
same LAN can see the “game room” created, without specifying the host IP
adress, like Warcraft III or other games where you can play in LAN. I have
followed this tutorial:

http://www.breakersgambit.com/?p=24

that is like the chat tutorial that came with SDL_net, but in these cases
the host IP was explicitly specified.

Thanks!


Yuri David Santos
Aleva Games
games.aleva.com.br http://www.aleva.com.br


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Yuri David Santos
Aleva - Solu??es em Software
www.aleva.com.br

Hello !

git://git.debian.org/git/tux4kids/tuxmath.git

There is also a nice gitweb available :

http://anonscm.debian.org/gitweb/?p=tux4kids/tuxmath.git;a=tree

CU

And, Patrick

I got the idea, but any clue about how do I do this with SDL_net?

2011/10/21 Yuri David Santos > Hi,

Thank you two. David, I would like to see your code, but how do I do that?
There are many directories… I have no idea what file I must to download.
Sorry for the ignorance (and my bad english).

2011/10/21 David Bruce

I set up this exact thing for the LAN play mode of tuxmath. Feel free to
look at our code if you like:

git://git.debian.org/git/tux4kids/tuxmath.git

The relevant functions are in server.c and network.c. I can’t promise
that it is world-class code, as it was the first network programming I had
done, but it works as intended.
On Oct 21, 2011 3:30 PM, “Patrick Baggett” <baggett.patrick at gmail.com> wrote:

In general, broadcasting. The client broadcasts a packet on the network.
The server would be listening for these type packets, and when it does, it
replies to the sender with “Hey, I have a game!”

Patrick

On Fri, Oct 21, 2011 at 3:27 PM, Yuri David Santos wrote:

Hi,

How can I do a multiplayer game with SDL_net? My doubt is how can I do
to “create a game” in a server machine, so that all the other machines in
the same LAN can see the “game room” created, without specifying the host IP
adress, like Warcraft III or other games where you can play in LAN. I have
followed this tutorial:

http://www.breakersgambit.com/?p=24

that is like the chat tutorial that came with SDL_net, but in these
cases the host IP was explicitly specified.

Thanks!


Yuri David Santos
Aleva Games
games.aleva.com.br http://www.aleva.com.br


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Yuri David Santos
Aleva - Solu??es em Software
www.aleva.com.br


Yuri David Santos
Aleva - Solu??es em Software
www.aleva.com.br

Hi Yuri,

Thank you two. David, I would like to see your code, but how do I do that?
There are many directories… I have no idea what file I must to download.
Sorry for the ignorance (and my bad english).

https://alioth.debian.org/frs/download.php/3571/tuxmath_w_fonts-2.0.3.tar.gz

If you want to actually build tuxmath, you also need our common library:

https://alioth.debian.org/frs/download.php/3540/t4k_common-0.1.1.tar.gz

Again, I’m not an expert programmer, so I can’t guarantee my code is
optimal, but it does work. I figured it out by:

  1. Reading Beej’s sockets programming tutorial (google for it)
  2. Googling for SDL_net tutorials.
  3. Asking on this list.

Basically, I used TCP for the actual game connection as tuxmath has
very minimal network performance needs. You may find folks saying
"Use UDP for games because it is faster" but my type of game didn’t
need it.

The client finds the server on the LAN by making a UDP broadcast.
When the server gets a packet from a client, it then knows the
client’s IP address and sends a packet back saying “server at IP
xxx.xxx.xxx.xxx”. There can be more than one server on the network.
The client program then can pick which server to connect to with TCP.

I would bet that there are many other open source games that do the
same thing and were written by more knowledgable programmers than me.
In particular, I can’t promise that my code doesn’t have security
holes in case your program is going to be exposed to the internet at
large. (Note that the broadcast autodetection routine wouldn’t work
over the internet anyway, although the connections themselves would
work).

Hope that helps,–
David Bruce

For all your software needs, visit The Apt Store:
deb http://ftp.us.debian.org/debian stable main

Hi Bruce,

I read some parts of your code and it has the answer for some of my
questions. About TuxMath, why do you use the server in a separate thread or
process? To keep listening to client messages? Could I do the server message
handling and game updates in the same thread?
I would like to see your game working, it is on the ubuntu repository?

Thank you very much!! :smiley:

2011/10/22 David Bruce > Hi Yuri,

Thank you two. David, I would like to see your code, but how do I do
that?
There are many directories… I have no idea what file I must to
download.
Sorry for the ignorance (and my bad english).

https://alioth.debian.org/frs/download.php/3571/tuxmath_w_fonts-2.0.3.tar.gz

If you want to actually build tuxmath, you also need our common library:

https://alioth.debian.org/frs/download.php/3540/t4k_common-0.1.1.tar.gz

Again, I’m not an expert programmer, so I can’t guarantee my code is
optimal, but it does work. I figured it out by:

  1. Reading Beej’s sockets programming tutorial (google for it)
  2. Googling for SDL_net tutorials.
  3. Asking on this list.

Basically, I used TCP for the actual game connection as tuxmath has
very minimal network performance needs. You may find folks saying
"Use UDP for games because it is faster" but my type of game didn’t
need it.

The client finds the server on the LAN by making a UDP broadcast.
When the server gets a packet from a client, it then knows the
client’s IP address and sends a packet back saying “server at IP
xxx.xxx.xxx.xxx”. There can be more than one server on the network.
The client program then can pick which server to connect to with TCP.

I would bet that there are many other open source games that do the
same thing and were written by more knowledgable programmers than me.
In particular, I can’t promise that my code doesn’t have security
holes in case your program is going to be exposed to the internet at
large. (Note that the broadcast autodetection routine wouldn’t work
over the internet anyway, although the connections themselves would
work).

Hope that helps,


David Bruce

For all your software needs, visit The Apt Store:
deb http://ftp.us.debian.org/debian stable main


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Yuri David Santos
Aleva - Solu??es em Software
www.aleva.com.br

Hi Yuri,
I think I can answer that. When your running a server, it is almost
impossible, especially in a game situation, to run on a single thread. This
is because some socket functions are blocking (the program waits until the
operation is complete), or generally slow. Blocking can be resolved with
using select (i believe SDL_net uses socket sets which in the background use
this call). Mostly, if your server is handling multiple clients and each
need near-real time responses, it is ideal for each client to have its own
thread so the server can process each client in isolation and fairly
quickly.
If your server only gives data to the client after the client asks for it,
having each client thread have blocking sockets means your server isn’t
burning through cpu time/power, and each blocking call doesn’t affect other
clients. In a game situation, clients don’t necessarily need their own
blocking thread, but it is nice to handle client connections in a separate
thread for speed, and a certain sense of sterileness.
I hope that explains a little bit of it :slight_smile:
-AlexOn Sat, Oct 22, 2011 at 9:08 PM, Yuri David Santos wrote:

Hi Bruce,

I read some parts of your code and it has the answer for some of my
questions. About TuxMath, why do you use the server in a separate thread or
process? To keep listening to client messages? Could I do the server message
handling and game updates in the same thread?
I would like to see your game working, it is on the ubuntu repository?

Thank you very much!! :smiley:

2011/10/22 David Bruce

Hi Yuri,

Thank you two. David, I would like to see your code, but how do I do
that?
There are many directories… I have no idea what file I must to
download.
Sorry for the ignorance (and my bad english).

https://alioth.debian.org/frs/download.php/3571/tuxmath_w_fonts-2.0.3.tar.gz

If you want to actually build tuxmath, you also need our common library:

https://alioth.debian.org/frs/download.php/3540/t4k_common-0.1.1.tar.gz

Again, I’m not an expert programmer, so I can’t guarantee my code is
optimal, but it does work. I figured it out by:

  1. Reading Beej’s sockets programming tutorial (google for it)
  2. Googling for SDL_net tutorials.
  3. Asking on this list.

Basically, I used TCP for the actual game connection as tuxmath has
very minimal network performance needs. You may find folks saying
"Use UDP for games because it is faster" but my type of game didn’t
need it.

The client finds the server on the LAN by making a UDP broadcast.
When the server gets a packet from a client, it then knows the
client’s IP address and sends a packet back saying “server at IP
xxx.xxx.xxx.xxx”. There can be more than one server on the network.
The client program then can pick which server to connect to with TCP.

I would bet that there are many other open source games that do the
same thing and were written by more knowledgable programmers than me.
In particular, I can’t promise that my code doesn’t have security
holes in case your program is going to be exposed to the internet at
large. (Note that the broadcast autodetection routine wouldn’t work
over the internet anyway, although the connections themselves would
work).

Hope that helps,


David Bruce

For all your software needs, visit The Apt Store:
deb http://ftp.us.debian.org/debian stable main


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Yuri David Santos
Aleva - Solu??es em Software
www.aleva.com.br


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

If you’re using UDP, then one thread to check the all of sockets is probably
fine. Basically, that thread reads data, validates it, and then packages it
in a way that the rest of the game engine can understand it (i.e. does
little to no processing on it all). This has two major points. The first is
that you don’t spend much time trying to process network traffic on the
thread that is responsible for fetching it, so the latency is lower. Two,
you separate the network details from the game engine stuff. That way, you
can have a client who is local that mimics the network protocol by packaging
stuff like keyboard/mouse input into a game-undestandable format. Really
though, that is a discussion more about software architecture and
interfaces.

For the purposes of < 16 clients, 1 thread that handles network I/O is
probably fine. When you call [non-blocking] recv(), the data isn’t being
read from the network card – it is already in memory in the OS kernel, so
it isn’t like you are handling the delay of network transmissions when you
call it. As far as burning through CPU, even a simple hack like Sleep(1),
however unclean, would stop you from absolutely hogging a single CPU core.
More appropriately, you can use as Alex mentioned a select() / event
notification system with a timeout. Even waiting a few msec for traffic will
keep the CPU utilization near 0.On Sat, Oct 22, 2011 at 9:14 PM, Alex Barry <alex.barry at gmail.com> wrote:

Hi Yuri,
I think I can answer that. When your running a server, it is almost
impossible, especially in a game situation, to run on a single thread. This
is because some socket functions are blocking (the program waits until the
operation is complete), or generally slow. Blocking can be resolved with
using select (i believe SDL_net uses socket sets which in the background use
this call). Mostly, if your server is handling multiple clients and each
need near-real time responses, it is ideal for each client to have its own
thread so the server can process each client in isolation and fairly
quickly.
If your server only gives data to the client after the client asks for it,
having each client thread have blocking sockets means your server isn’t
burning through cpu time/power, and each blocking call doesn’t affect other
clients. In a game situation, clients don’t necessarily need their own
blocking thread, but it is nice to handle client connections in a separate
thread for speed, and a certain sense of sterileness.
I hope that explains a little bit of it :slight_smile:
-Alex

On Sat, Oct 22, 2011 at 9:08 PM, Yuri David Santos wrote:

Hi Bruce,

I read some parts of your code and it has the answer for some of my
questions. About TuxMath, why do you use the server in a separate thread or
process? To keep listening to client messages? Could I do the server message
handling and game updates in the same thread?
I would like to see your game working, it is on the ubuntu repository?

Thank you very much!! :smiley:

2011/10/22 David Bruce

Hi Yuri,

Thank you two. David, I would like to see your code, but how do I do
that?
There are many directories… I have no idea what file I must to
download.
Sorry for the ignorance (and my bad english).

https://alioth.debian.org/frs/download.php/3571/tuxmath_w_fonts-2.0.3.tar.gz

If you want to actually build tuxmath, you also need our common library:

https://alioth.debian.org/frs/download.php/3540/t4k_common-0.1.1.tar.gz

Again, I’m not an expert programmer, so I can’t guarantee my code is
optimal, but it does work. I figured it out by:

  1. Reading Beej’s sockets programming tutorial (google for it)
  2. Googling for SDL_net tutorials.
  3. Asking on this list.

Basically, I used TCP for the actual game connection as tuxmath has
very minimal network performance needs. You may find folks saying
"Use UDP for games because it is faster" but my type of game didn’t
need it.

The client finds the server on the LAN by making a UDP broadcast.
When the server gets a packet from a client, it then knows the
client’s IP address and sends a packet back saying “server at IP
xxx.xxx.xxx.xxx”. There can be more than one server on the network.
The client program then can pick which server to connect to with TCP.

I would bet that there are many other open source games that do the
same thing and were written by more knowledgable programmers than me.
In particular, I can’t promise that my code doesn’t have security
holes in case your program is going to be exposed to the internet at
large. (Note that the broadcast autodetection routine wouldn’t work
over the internet anyway, although the connections themselves would
work).

Hope that helps,


David Bruce

For all your software needs, visit The Apt Store:
deb http://ftp.us.debian.org/debian stable main


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Yuri David Santos
Aleva - Solu??es em Software
www.aleva.com.br


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

In my experience, UDP has such low overhead that one thread can handle thousands of packets per second per socket.

It’s one of the reasons that UDP is so loved in the game industry.

Mostly TCP is used only by turn-based games and MMOs, where the rubber-banding latency issues are usually unimportant (TCP can lag for minutes at times!).

There are also a number of realtime low-latency games that use TCP and should be using UDP instead :slight_smile:

I still regard the QuakeWorld Server design as good practice for realtime games… It allocates only one socket (which makes it easy to portforward), and simply services incoming packets as they come
in (using select to sleep between packets), when a client input packet comes in, it updates the game world (if enough time has passed to justify it, like 20ms or so), and replies with a new game state
for that client (detailing the game objects near the client, and any events that occurred since the last packet, such as chat messages).

UDP vs TCP, point by point:

GREAT: Low latency despite packet loss - TCP has “rubberbanding” lag when packet loss occurs because it must repeatedly try to send the same packet again (even if it’s now rather out of date), and
won’t deliver the packets to the app until the preceding packets are delivered, in order.

GOOD: Exact control over bandwidth - TCP has very erratic bandwidth utilization as its only goal is to deliver the stream as fast as possible, UDP delivers distinct packets as you see fit.

GOOD: Non-blocking API - simply enabling non-blocking I/O on the socket is enough to avoid all need for threading of the network layer.

BAD: Out of order delivery - UDP packets are not guaranteed to arrive in order, in general games address this by numbering all the packets and dropping ones that are older than previously received ones.

BAD: Duplicate packets - UDP packets are not guaranteed to arrive only once, they may arrive multiple times (went the routers sent them on multiple paths due to uncertainty), again this is addressed
by checking packet numbers and dropping ones that are not new.

BAD: Packet loss - UDP packets are not guaranteed to arrive (ever), in general games address this by checking for gaps in the packet numbers and acknowledging receipt of every packet number to the
peer in the next packet (may be more than one packet recieved per packet sent, depending on your send/receive frequencies), if a peer acknowledges a given packet number then you can safely use that
packet for compression or other purposes (for instance repeating a reliable message in a future packet if a gap in packet numbers was detected).

BAD: Maximum packet size - UDP packets can not be fragmented, and thus can only be up to 1400-1500 bytes safely on the internet (some routers may pass 9000 bytes, but I wouldn’t bet on it).

So on the whole, UDP is vastly superior for realtime games, but a lot more work.

Some games use both a UDP socket (for rapidly updating data) and a TCP socket (for important communication), and send different kinds of data on each connection, but this means blocking I/O hassles on
the TCP sockets, and can still experience the rubberbanding lag behavior on the TCP-carried data.

P.S. UDP fragmenting actually exists but is deeply flawed, so internet routers don’t pass UDP fragments.On 10/22/2011 07:31 PM, Patrick Baggett wrote:

If you’re using UDP, then one thread to check the all of sockets is probably fine. Basically, that thread reads data, validates it, and then packages it in a way that the rest of the game engine can
understand it (i.e. does little to no processing on it all). This has two major points. The first is that you don’t spend much time trying to process network traffic on the thread that is responsible
for fetching it, so the latency is lower. Two, you separate the network details from the game engine stuff. That way, you can have a client who is local that mimics the network protocol by packaging
stuff like keyboard/mouse input into a game-undestandable format. Really though, that is a discussion more about software architecture and interfaces.

For the purposes of < 16 clients, 1 thread that handles network I/O is probably fine. When you call [non-blocking] recv(), the data isn’t being read from the network card – it is already in memory in
the OS kernel, so it isn’t like you are handling the delay of network transmissions when you call it. As far as burning through CPU, even a simple hack like Sleep(1), however unclean, would stop you
from absolutely hogging a single CPU core. More appropriately, you can use as Alex mentioned a select() / event notification system with a timeout. Even waiting a few msec for traffic will keep the
CPU utilization near 0.

On Sat, Oct 22, 2011 at 9:14 PM, Alex Barry <alex.barry at gmail.com <mailto:alex.barry at gmail.com>> wrote:

Hi Yuri,
I think I can answer that.  When your running a server, it is almost impossible, especially in a game situation, to run on a single thread.  This is because some socket functions are blocking (the
program waits until the operation is complete), or generally slow.  Blocking can be resolved with using select (i believe SDL_net uses socket sets which in the background use this call).  Mostly,
if your server is handling multiple clients and each need near-real time responses, it is ideal for each client to have its own thread so the server can process each client in isolation and fairly
quickly.
If your server only gives data to the client after the client asks for it, having each client thread have blocking sockets means your server isn't burning through cpu time/power, and each blocking
call doesn't affect other clients.  In a game situation, clients don't necessarily need their own blocking thread, but it is nice to handle client connections in a separate thread for speed, and a
certain sense of sterileness.
I hope that explains a little bit of it :)
-Alex


On Sat, Oct 22, 2011 at 9:08 PM, Yuri David Santos <yuri at aleva.com.br <mailto:yuri at aleva.com.br>> wrote:

    Hi Bruce,

    I read some parts of your code and it has the answer for some of my questions. About TuxMath, why do you use the server in a separate thread or process? To keep listening to client messages?
    Could I do the server message handling and game updates in the same thread?
    I would like to see your game working, it is on the ubuntu repository?

    Thank you very much!! :D


    2011/10/22 David Bruce <davidstuartbruce at gmail.com <mailto:davidstuartbruce at gmail.com>>

        Hi Yuri,

         > Thank you two. David, I would like to see your code, but how do I do that?
         > There are many directories... I have no idea what file I must to download.
         > Sorry for the ignorance (and my bad english).

        https://alioth.debian.org/frs/download.php/3571/tuxmath_w_fonts-2.0.3.tar.gz

        If you want to actually build tuxmath, you also need our common library:

        https://alioth.debian.org/frs/download.php/3540/t4k_common-0.1.1.tar.gz


        Again, I'm not an expert programmer, so I can't guarantee my code is
        optimal, but it does work. I figured it out by:
        1. Reading Beej's sockets programming tutorial (google for it)
        2. Googling for SDL_net tutorials.
        3. Asking on this list.

        Basically, I used TCP for the actual game connection as tuxmath has
        very minimal network performance needs.  You may find folks saying
        "Use UDP for games because it is faster" but my type of game didn't
        need it.

        The client finds the server on the LAN by making a UDP broadcast.
        When the server gets a packet from a client, it then knows the
        client's IP address and sends a packet back saying "server at IP
        xxx.xxx.xxx.xxx".  There can be more than one server on the network.
        The client program then can pick which server to connect to with TCP.

        I would bet that there are many other open source games that do the
        same thing and were written by more knowledgable programmers than me.
        In particular, I can't promise that my code doesn't have security
        holes in case your program is going to be exposed to the internet at
        large.  (Note that the broadcast autodetection routine wouldn't work
        over the internet anyway, although the connections themselves would
        work).

        Hope that helps,

        --
        David Bruce

        For all your software needs, visit The Apt Store:
        deb http://ftp.us.debian.org/debian stable main
        _______________________________________________
        SDL mailing list
        SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
        http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org




    --
    Yuri David Santos
    Aleva - Solu??es em Software
    www.aleva.com.br <http://www.aleva.com.br>


    _______________________________________________
    SDL mailing list
    SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
    http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org



_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

I can suggest reading this article: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
The article mentions that using both TCP & UDP can be a bad decision, because TCP connections can lead to packet loss in UDP.
There is also another Source cited, but it is quite old. So maybe if you need the performance of UDP you should benchmark if using TCP at the same moment works for you.On 23.10.2011 06:33, Forest Hale wrote:

Some games use both a UDP socket (for rapidly updating data) and a TCP socket (for important communication), and send different kinds of data on each connection, but this means blocking I/O hassles on the TCP sockets, and can still experience the rubberbanding lag behavior on the TCP-carried data.

Hi,

First, thank you all! I understood the differences between UDP and TCP. So,
can I use a UDP non-blocking socket to my game in the same thread/loop that
I process the game? I’m trying to develop a real time strategy game… So
the performance is important. But I want to wrap the network stuff in a
library, and it will be a little more complicated if I use multi-threading.
Moreover, I want to use the same program to behave like server sometimes
(when the player create the game) and like client sometimes (when the player
join a game already created), instead of creating two programs, a server and
a client.
Anyone knows a tutorial that can show how to write (with minimum code) a
program like:

int main(…)
{
initialize_game();

while(!quit)
{
    switch(GAMESTATE)
    {
        case IM_THE_GAME_HOST:
            if(!server_started()) start_server();

            handle_client_messages();
            game_stuff_server();

            break;

        case IM_A_GAME_CLIENT:
            while(!connected()) find_servers();

            handle_network_messages();
            game_stuff_client();

            break;
    }
}

}

I have read some examples of network games, but I’m a little lost with too
much functions… The examples I got have about a thousand lines, and some
game logic within it… I only want to know the basics of doing with SDL:

  • start a server listening to clients
  • make the server read the received messages as char*
  • send a broadcast message
  • the server can already read, but how to send a message to the peer that
    send the broadcast message saying “looking for a server”
  • make the client read the response from server
  • make the client connect to the server that answered to his message
  • make the client read some message that arrives from server

The UDP packaging order control and other control code I think I can do by
myself, but the issues above are driving me a little crazy…
I have tried the following code to do the broadcast (the code works if I
specify the server IP, but it’s suposed not to be known):

sprintf(server, "255.255.255.255");
SDLNet_ResolveHost(&serverIP, server, GAME_PORT);

printf("%d %d", serverIP.host, serverIP.port);

if(serverIP.host == INADDR_NONE)
{
    printf("Can't resolve hostname\n");
}
else
{
    tcpsock = SDLNet_TCP_Open(&serverIP);

    if(tcpsock == NULL)
        printf("Fail to connect on %s\n", server);
    else
        printf("Connected successfully on %s\n", server);
}

The serverIP.host returns -1 and port 38283. GAME_PORT is set to 35733.

Thanks in advance!

2011/10/23 Christoph Harder > I can suggest reading this article: http://gafferongames.com/**

networking-for-game-**programmers/udp-vs-tcp/http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
The article mentions that using both TCP & UDP can be a bad decision,
because TCP connections can lead to packet loss in UDP.
There is also another Source cited, but it is quite old. So maybe if you
need the performance of UDP you should benchmark if using TCP at the same
moment works for you.

On 23.10.2011 06:33, Forest Hale wrote:

Some games use both a UDP socket (for rapidly updating data) and a TCP
socket (for important communication), and send different kinds of data on
each connection, but this means blocking I/O hassles on the TCP sockets, and
can still experience the rubberbanding lag behavior on the TCP-carried data.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Yuri David Santos
Aleva - Solu??es em Software
www.aleva.com.br

This example has everything I want to know, but it uses TCP and you have to
specify the server IP address.

http://www.mattconcepts.com/SDL_Net%20game%20example.zip

2011/10/23 Yuri David Santos > Hi,

First, thank you all! I understood the differences between UDP and TCP. So,
can I use a UDP non-blocking socket to my game in the same thread/loop that
I process the game? I’m trying to develop a real time strategy game… So
the performance is important. But I want to wrap the network stuff in a
library, and it will be a little more complicated if I use multi-threading.
Moreover, I want to use the same program to behave like server sometimes
(when the player create the game) and like client sometimes (when the player
join a game already created), instead of creating two programs, a server and
a client.
Anyone knows a tutorial that can show how to write (with minimum code) a
program like:

int main(…)
{
initialize_game();

while(!quit)
{
    switch(GAMESTATE)
    {
        case IM_THE_GAME_HOST:
            if(!server_started()) start_server();

            handle_client_messages();
            game_stuff_server();

            break;

        case IM_A_GAME_CLIENT:
            while(!connected()) find_servers();

            handle_network_messages();
            game_stuff_client();

            break;
    }
}

}

I have read some examples of network games, but I’m a little lost with too
much functions… The examples I got have about a thousand lines, and some
game logic within it… I only want to know the basics of doing with SDL:

  • start a server listening to clients
  • make the server read the received messages as char*
  • send a broadcast message
  • the server can already read, but how to send a message to the peer that
    send the broadcast message saying “looking for a server”
  • make the client read the response from server
  • make the client connect to the server that answered to his message
  • make the client read some message that arrives from server

The UDP packaging order control and other control code I think I can do by
myself, but the issues above are driving me a little crazy…
I have tried the following code to do the broadcast (the code works if I
specify the server IP, but it’s suposed not to be known):

sprintf(server, "255.255.255.255");
SDLNet_ResolveHost(&serverIP, server, GAME_PORT);

printf("%d %d", serverIP.host, serverIP.port);

if(serverIP.host == INADDR_NONE)
{
    printf("Can't resolve hostname\n");
}
else
{
    tcpsock = SDLNet_TCP_Open(&serverIP);

    if(tcpsock == NULL)
        printf("Fail to connect on %s\n", server);
    else
        printf("Connected successfully on %s\n", server);
}

The serverIP.host returns -1 and port 38283. GAME_PORT is set to 35733.

Thanks in advance!

2011/10/23 Christoph Harder

I can suggest reading this article: http://gafferongames.com/**
networking-for-game-**programmers/udp-vs-tcp/http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
The article mentions that using both TCP & UDP can be a bad decision,
because TCP connections can lead to packet loss in UDP.
There is also another Source cited, but it is quite old. So maybe if you
need the performance of UDP you should benchmark if using TCP at the same
moment works for you.

On 23.10.2011 06:33, Forest Hale wrote:

Some games use both a UDP socket (for rapidly updating data) and a TCP
socket (for important communication), and send different kinds of data on
each connection, but this means blocking I/O hassles on the TCP sockets, and
can still experience the rubberbanding lag behavior on the TCP-carried data.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Yuri David Santos
Aleva - Solu??es em Software
www.aleva.com.br


Yuri David Santos
Aleva - Solu??es em Software
www.aleva.com.br

Oh sorry! I totally forgot about this article, I read it before but forgot that critical detail, TCP has a very high tendency to kill UDP yes :)On 10/23/2011 04:06 AM, Christoph Harder wrote:

I can suggest reading this article: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
The article mentions that using both TCP & UDP can be a bad decision, because TCP connections can lead to packet loss in UDP.
There is also another Source cited, but it is quite old. So maybe if you need the performance of UDP you should benchmark if using TCP at the same moment works for you.

On 23.10.2011 06:33, Forest Hale wrote:

Some games use both a UDP socket (for rapidly updating data) and a TCP socket (for important communication), and send different kinds of data on each connection, but this means blocking I/O hassles
on the TCP sockets, and can still experience the rubberbanding lag behavior on the TCP-carried data.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

Nothing to be sorry about, I didn’t actually check it myself. Maybe it works in some situations?
For example using TCP for lobby creation, server listings, matchmaking (every thing that is not done while the actual session is running) or in-game chat could work (many people use some instant messenger while playing, do they use TCP or UDP?).On 24.10.2011 11:44, Forest Hale wrote:

Oh sorry! I totally forgot about this article, I read it before but forgot that critical detail, TCP has a very high tendency to kill UDP yes :slight_smile:

On 10/23/2011 04:06 AM, Christoph Harder wrote:

I can suggest reading this article: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
The article mentions that using both TCP & UDP can be a bad decision, because TCP connections can lead to packet loss in UDP.
There is also another Source cited, but it is quite old. So maybe if you need the performance of UDP you should benchmark if using TCP at the same moment works for you.

On 23.10.2011 06:33, Forest Hale wrote:

Some games use both a UDP socket (for rapidly updating data) and a TCP socket (for important communication), and send different kinds of data on each connection, but this means blocking I/O hassles
on the TCP sockets, and can still experience the rubberbanding lag behavior on the TCP-carried data.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi,

well with UDP you have the problem to have to deal with all the comunication
problems yourself. Plus some routers have UDP forwarding disabled, if I am
not mistaken.–
Paulo

On Mon, Oct 24, 2011 at 4:14 PM, Christoph Harder wrote:

Nothing to be sorry about, I didn’t actually check it myself. Maybe it
works in some situations?
For example using TCP for lobby creation, server listings, matchmaking
(every thing that is not done while the actual session is running) or
in-game chat could work (many people use some instant messenger while
playing, do they use TCP or UDP?).

On 24.10.2011 11:44, Forest Hale wrote:

Oh sorry! I totally forgot about this article, I read it before but forgot
that critical detail, TCP has a very high tendency to kill UDP yes :slight_smile:

On 10/23/2011 04:06 AM, Christoph Harder wrote:

I can suggest reading this article: http://gafferongames.com/**
networking-for-game-**programmers/udp-vs-tcp/http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
The article mentions that using both TCP & UDP can be a bad decision,
because TCP connections can lead to packet loss in UDP.
There is also another Source cited, but it is quite old. So maybe if you
need the performance of UDP you should benchmark if using TCP at the same
moment works for you.

On 23.10.2011 06:33, Forest Hale wrote:

Some games use both a UDP socket (for rapidly updating data) and a TCP
socket (for important communication), and send different kinds of data on
each connection, but this means blocking I/O hassles
on the TCP sockets, and can still experience the rubberbanding lag
behavior on the TCP-carried data.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi,

well with UDP you have the problem to have to deal with all the comunication
problems yourself.

There are high level libraries that take the “pain” of UDP away - the
"pain" here is the reliablilty and ordering guarantees. The nice thing
about a protocol built on top of UDP is that you can implement
ordering and reliability only for messages where it makes sense,
without imposing latency for non critical messages.

Plus some routers have UDP forwarding disabled, if I am
not mistaken.

Almost no routers have UDP completely disabled, UDP is used for
critical internet services, in particular DNS. Some professionally
administered networks (e.g. in a company, a university, shared
accomodation, etc) might disable uncommon UDP ports for security or
liability reasons. Home routers would generally allow all outgoing
connections.

You might have been thinking of UPnP? This is frequently disabled on
consumer routers for security reasons.

– Brian

The last time I was doing socket level programming was back in 2000, so
my memory is a bit fuzzy in technical parts.On Mon, Oct 24, 2011 at 5:10 PM, Brian Barrett <brian.ripoff at gmail.com>wrote:

Hi,

well with UDP you have the problem to have to deal with all the
comunication
problems yourself.

There are high level libraries that take the “pain” of UDP away - the
"pain" here is the reliablilty and ordering guarantees. The nice thing
about a protocol built on top of UDP is that you can implement
ordering and reliability only for messages where it makes sense,
without imposing latency for non critical messages.

Plus some routers have UDP forwarding disabled, if I am
not mistaken.

Almost no routers have UDP completely disabled, UDP is used for
critical internet services, in particular DNS. Some professionally
administered networks (e.g. in a company, a university, shared
accomodation, etc) might disable uncommon UDP ports for security or
liability reasons. Home routers would generally allow all outgoing
connections.

You might have been thinking of UPnP? This is frequently disabled on
consumer routers for security reasons.

– Brian


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

For a library that does reliable UDP handling, there is
enethttp://enet.bespin.org/index.html,
which is pretty respectable. I’ve used it a few times (for some tests), and
it performs well, and has a similar philosophy to how SDL handles events,
which may or may not fit into your style - if your client can also act like
a server, it may be ideal to run an enet server in a separate thread.

Hope that helps,
-AlexOn Mon, Oct 24, 2011 at 12:31 PM, Paulo Pinto <paulo.jpinto at gmail.com>wrote:

The last time I was doing socket level programming was back in 2000, so
my memory is a bit fuzzy in technical parts.

On Mon, Oct 24, 2011 at 5:10 PM, Brian Barrett <brian.ripoff at gmail.com>wrote:

Hi,

well with UDP you have the problem to have to deal with all the
comunication
problems yourself.

There are high level libraries that take the “pain” of UDP away - the
"pain" here is the reliablilty and ordering guarantees. The nice thing
about a protocol built on top of UDP is that you can implement
ordering and reliability only for messages where it makes sense,
without imposing latency for non critical messages.

Plus some routers have UDP forwarding disabled, if I am
not mistaken.

Almost no routers have UDP completely disabled, UDP is used for
critical internet services, in particular DNS. Some professionally
administered networks (e.g. in a company, a university, shared
accomodation, etc) might disable uncommon UDP ports for security or
liability reasons. Home routers would generally allow all outgoing
connections.

You might have been thinking of UPnP? This is frequently disabled on
consumer routers for security reasons.

– Brian


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org