Hi cpu usage

SDL Development
21

Use select (http://linux.die.net/man/3/select) to wait for incoming
packets in your threads, it will put the thread to sleep until a packet
arrives. You can also specify a timeout value in select.

Cheers,

AndreOn 13/03/2011 16:10, deepak aggarwal wrote:

Hi am working on common libraries for setting up server and managing
it. I need this type of technique so that i can accept multiple
request from client and open socket for them on different threads i.e
a concurrent server thats why i have to use this type of technique.
One solution i find is to sleep this thread for some millisecond but
this method is suboptimal. Hope i shall find another way to solve this
problem.

22

Hi Andre
Thanks for your reply. This is tje exact thing which i am looking for. One
thing i want to ask if they support sdl TCP socket. As in there description
it is written that they might support sockets.On 14-Mar-2011 12:51 AM, “Andre Leiradella” wrote:

On 13/03/2011 16:10, deepak aggarwal wrote:

Hi am working on common libraries for setting up server and managing
it. I need this type of technique so that i can accept multiple
request from client and open socket for them on different threads i.e
a concurrent server thats why i have to use this type of technique.
One solution i find is to sleep this thread for some millisecond but
this method is suboptimal. Hope i shall find another way to solve this
problem.

Use select (http://linux.die.net/man/3/select) to wait for incoming
packets in your threads, it will put the thread to sleep until a packet
arrives. You can also specify a timeout value in select.

Cheers,

Andre

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

23

Note that TCP/IP is basically a useless protocol, its very badly
designed.

This is the funniest thing I’ve read today.

I am glad to be of service … but what exactly do you find funny?
I mean, it is humorous sockets and TCP/IP are widely used for things
they’re entirely unsuitable for.

Bidirectional sockets=crap. See shutdown rubbish, a vain attempt
to fix misdesign. Connection protocol: great for Flash I suppose.
Useless for web, database, or other message based interactions
which require framing which TCP/IP doesn’t provide.

I’ve used quite a few networks over the past 35 years… to be honest
most of them are crap :slight_smile: I even designed a few myself (the one in
use is serious crud let me tell you … the other one never got off
the ground due to electrical design problem). Actually my dwelling
runs 3 networks which are safety critical (NMEA 0183, NMEA 2000
and some ethernet based protocol for radar, probably using
the bottom level of TCP stack).

As usual the problem is the intrinsic conservatism of industry,
especially software. Good reason of course, but old things tend
to stick around a lot longer than they should :)On 13/03/2011, at 10:09 PM, Tim Angus wrote:

On Sun, 13 Mar 2011 20:04:36 +1100 john wrote:

–
john skaller
@john_skaller

24

Note that TCP/IP is basically a useless protocol, its very badly designed.

wut?
care to elaborate?

See other message: connection based protocol is useful for streaming data.
Bidirectional connections are suspect, the design doesn’t work properly
(pairs of one directional connections would have been better).
Most internet usage requires framed data (messages) not streams.On 13/03/2011, at 10:39 PM, Vittorio G. wrote:

On Sun, Mar 13, 2011 at 10:04 AM, john skaller <@john_skaller> wrote:

–
john skaller
@john_skaller

25

Still, it’s served me and my former employer and countless others well for
ages -

Served well == you made money out of it.
Related to commercial penetration. Unrelated to quality.On 13/03/2011, at 11:19 PM, David Olofson wrote:

–
john skaller
@john_skaller

26

See the first message of this thread. Then you are able to understand what is my problem

The basic issue is the usual one: how can you read data when you don’t know
if is there?

If you do a blocking read it locks up the thread.

If you do an non-blocking read you end up with an infinite CPU hogging loop.

You can use select/poll/epoll etc to find out if there is any data available
on any socket you’re interested in, but this isn’t standardised (sockets = useless
protocol … :slight_smile:

You can use a delay = latency issue.

So the problem is as I said: we have a next to useless protocol and we’re
struggling to find out how to use it.

If there’s only one connection per thread … blocking I/O is probably OK,
blocking I/O with a timeout is a bit safer because it lets the application
judge when something is wrong and exit gracefully, which is otherwise
hard to do = thread cancellation is junk (another really bad design).
The downside is that if you have a reasonable number of connections
to manage you pay in thread related resources including latency from
context switching etc.

So basically people laugh when I say TCP/IP/sockets are bad design
but there you go: it is very hard to make this stuff work correctly and
efficiently.

My answer again: if you want “plug and play message passing” use
ZeroMQ. It is very easy to use, cross-platform, and it implements
a message passing protocol on top of TCP/IP and takes care of
all the housekeeping for you. Disclaimer: I haven’t use it myself (yet).

There’s no reason SDL should do everything you can possibly want to do
in a game … that would be absurd. It’s a base framework.On 14/03/2011, at 5:23 AM, deepak aggarwal wrote:

–
john skaller
@john_skaller

27

Hi am working on common libraries for setting up server and managing it. I need this type of technique so that i can accept multiple request from client and open socket for them on different threads i.e a concurrent server thats why i have to use this type of technique.

This is inefficient. You should have at most 2 worker threads per CPU in a pool and serialise access to the thread pool.
Serial processing is much faster. The only downside is loss of fairness (even distribution of work among clients).
Fairness might not be an issue in a game (depending on the design).

One solution i find is to sleep this thread for some millisecond but this method is suboptimal. Hope i shall find another way to solve this problem.

Use select (http://linux.die.net/man/3/select) to wait for incoming packets in your threads, it will put the thread to sleep until a packet arrives. You can also specify a timeout value in select.

But unfortunately select is very hard to use and not scalable.
Fine for a couple of sockets. Not so good with a lot of them ;(
That’s why poll()/epoll() etc were invented.On 14/03/2011, at 6:21 AM, Andre Leiradella wrote:

On 13/03/2011 16:10, deepak aggarwal wrote:

–
john skaller
@john_skaller

28

Hi Andre
Thanks for your reply. This is tje exact thing which i am looking for. One thing i want to ask if they support sdl TCP socket. As in there description it is written that they might support sockets.

Does select work on SDL representation of sockets on Windows?On 14/03/2011, at 6:48 AM, deepak aggarwal wrote:

–
john skaller
@john_skaller

29

[]

I’m looking at SDL_net now … are you writing C or willing to use C++?

Does anyone know the status of SDL_net? Docs say depends on SDL_1.2.7,
will anything happen to make it work with 1.3.x? [I note Sam the Man has been updating it … so I guess its active … :]On 13/03/2011, at 6:54 AM, deepak aggarwal wrote:

–
john skaller
@john_skaller

30

John

Hi write now i am writing code in c as all the code present in tuxmath is
present in c. In future i am thinking to migrate to c++.
If you want to poke my code thej i can send it to you.

[]

I’m looking at SDL_net now … are you writing C or willing to use C++?

Does anyone know the status of SDL_net? Docs say depends on SDL_1.2.7,
will anything happen to make it work with 1.3.x? [I note Sam the Man has beenOn 14-Mar-2011 12:11 PM, “john skaller” <skaller at users.sourceforge.net> wrote: On 13/03/2011, at 6:54 AM, deepak aggarwal wrote: updating it … so I guess its active … :]

–
john skaller
skaller at users.sourceforge.net

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

31

John

Hi write now i am writing code in c as all the code present in tuxmath is present in c.

Ok. I have a C++ library which is “more or less” independent of Felix which provides
notification services (i.e. tells you when a socket is ready for I/O).

However there are several other libraries around, written in C, and which are
probably better.

One of these is libevent2:

This library covers a lot more than sockets, it provides for all kinds of events including
files being changed, keyboard, etc etc. Last I read, libevent2 uses non-optimal OS functions
to avoid bugs with non-socket events (uses select on Mac or something because kqueue
is bugged for file descriptors … but AFAIK it works fine for sockets). The main downside of
this library (if I recall correctly) is that it is NOT a library. Grrrr… It’s a framework, i.e. all your
code has to be callback driven. Still, that’s not a problem if you run it inside a service thread,
since that has to loop anyhow. It is worth looking at the performance graphs: SDL_net uses
select, see how bad that is.

Another library modelled on libevent is

http://software.schmorp.de/pkg/libev.html
https://github.com/brimworks/libev

These libraries don’t do I/O. They just tell you when sockets are ready.
[Actual socket I/O is trivial].

Again, if you’re doing message handling, look at ZeroMQ. Typically games
do message handling. ZeroMQ handles both point to point and broadcast.
Do not underestimate how HARD it is to send a message on top of the
C socket interface. Better to use code written by someone dedicated to solving
that one problem than inventing the wheel.

Finally … IMHO from a brief look, SDL_net should be fine for a client application
and is probably OK for a server supporting, say, 8 players… just don’t try to
write an improved version of Battle.net with it … :slight_smile: As mentioned, you can use
SDLNet_CheckSockets, which uses select, to get rid of your CPU hogging
problem.On 14/03/2011, at 6:18 PM, deepak aggarwal wrote:

–
john skaller
@john_skaller

32

If you want to use sockets directly, I recommend the following (not too expensive:-) book:

“TCP/IP sockets in C, practical guide for programmers”, by Michael J. Donahoo and Kenneth L. Calvert (Morgan Kaufmann).

It covers TCP/UDP client/server architecture with a lot of C sample code. I’m a “sockets newbie”, and found this book very useful…

Regards,

Rapha?lOn Mar 14, 2011, at 10:01 AM, john skaller wrote:

On 14/03/2011, at 6:18 PM, deepak aggarwal wrote:

John

Hi write now i am writing code in c as all the code present in tuxmath is present in c.

Ok. I have a C++ library which is “more or less” independent of Felix which provides
notification services (i.e. tells you when a socket is ready for I/O).

However there are several other libraries around, written in C, and which are
probably better.

One of these is libevent2:

http://google-opensource.blogspot.com/2010/01/libevent-20x-like-libevent-14x-only.html

This library covers a lot more than sockets, it provides for all kinds of events including
files being changed, keyboard, etc etc. Last I read, libevent2 uses non-optimal OS functions
to avoid bugs with non-socket events (uses select on Mac or something because kqueue
is bugged for file descriptors … but AFAIK it works fine for sockets). The main downside of
this library (if I recall correctly) is that it is NOT a library. Grrrr… It’s a framework, i.e. all your
code has to be callback driven. Still, that’s not a problem if you run it inside a service thread,
since that has to loop anyhow. It is worth looking at the performance graphs: SDL_net uses
select, see how bad that is.

Another library modelled on libevent is

http://software.schmorp.de/pkg/libev.html
https://github.com/brimworks/libev

These libraries don’t do I/O. They just tell you when sockets are ready.
[Actual socket I/O is trivial].

Again, if you’re doing message handling, look at ZeroMQ. Typically games
do message handling. ZeroMQ handles both point to point and broadcast.
Do not underestimate how HARD it is to send a message on top of the
C socket interface. Better to use code written by someone dedicated to solving
that one problem than inventing the wheel.

Finally … IMHO from a brief look, SDL_net should be fine for a client application
and is probably OK for a server supporting, say, 8 players… just don’t try to
write an improved version of Battle.net with it … :slight_smile: As mentioned, you can use
SDLNet_CheckSockets, which uses select, to get rid of your CPU hogging
problem.

–
john skaller
skaller at users.sourceforge.net

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

33

The fact that you dismiss the protocol you used to send this email as
"useless".On 14/03/2011 03:39, john skaller wrote:

I am glad to be of service … but what exactly do you find funny?

34

Very true!

However, I tend to err in the idealistic/esthetic direction, which is
something I have to fight to actually get anything done. I still have this
idea that doing things properly is the right thing for the long term, but
sometimes, looking at the world around me, I wonder if I’m just plain wrong…

Either way, my point was that it does get the job done. That doesn’t
necessarily mean it’s good - but it certainly beats something that plain
doesn’t work! :-)On Monday 14 March 2011, at 04.51.36, john skaller wrote:

On 13/03/2011, at 11:19 PM, David Olofson wrote:

Still, it’s served me and my former employer and countless others well
for ages -

Served well == you made money out of it.
Related to commercial penetration. Unrelated to quality.

–
//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

35

I am glad to be of service … but what exactly do you find funny?

The fact that you dismiss the protocol you used to send this email as “useless”.

Lol … fair enough!On 14/03/2011, at 9:19 PM, Tim Angus wrote:

On 14/03/2011 03:39, john skaller wrote:

–
john skaller
@john_skaller