[Framework] Event-based Networking

Hi there,

In advance: I already postet this at the “Game Development”-Subforum of this board. But know I noticed that subforum is used for general game discussion and not SDL-based discussion (the title “SDL Development” seemed confusing to me ^^). To get more feedback I would like to post the following stuff here. If the moderators dislike this double-posting, pleace delete the old one :?

I am working with SDL using C++. Because I did not found something suitable yet, I startet solving the problem on my own: https://github.com/cgloeckner/networking

It is a framework for C++ using SDL and SDL_net; its aim is to offer sending “events” over the network and handling them after receive. The events are enqueued in a thread-safe fifo queue before sending. Any received events are also enqueued in an also thread-safe fifo queue at the receiver’s side. They will stay there until they were handled. Each event type is a derivate of the struct event. It contains an event-id to identify it at the receiver’s side referring to it’s original type. Then you can type-cast it to enable accessing the actual data. Both sides are using the same set of events.

Limitations

This events are not allowed to carry pointers or std-containers. Only primitive data types are allowed. This is because the framework does not serialize any data before sending. So pointers or high-level containers (using pointers) cannot be sent or received, unless serializing them first.

Licence and structure

I released the project under CC BY-NC 3.0. You can find the source code at the linked GitHub-Repository: the framework is placed inside the src-directory. Also you can find an example inside the example-directory.

Additional notes

The project is already using features of C++11. Actually, I like to make it independent from C++11, because of the missing support of many compilers. That is why I implemeneted all threading stuff using SDL_thread.

I am curious about your feedback!

With kind regards
Glocke

Out of curiosity, have you seen this?
http://gameprogrammer.com/fastevents/fastevents1.htmlOn Sat, Mar 16, 2013 at 3:32 AM, Glocke wrote:

**
Hi there,

In advance: I already postet this at the “Game Development”-Subforum of
this board. But know I noticed that subforum is used for general game
discussion and not SDL-based discussion (the title “SDL Development” seemed
confusing to me ^^). To get more feedback I would like to post the
following stuff here. If the moderators dislike this double-posting, pleace
delete the old one [image: Confused]

I am working with SDL using C++. Because I did not found something
suitable yet, I startet solving the problem on my own:
https://github.com/cgloeckner/networking

It is a framework for C++ using SDL and SDL_net; its aim is to offer
sending “events” over the network and handling them after receive. The
events are enqueued in a thread-safe fifo queue before sending. Any
received events are also enqueued in an also thread-safe fifo queue at the
receiver’s side. They will stay there until they were handled. Each event
type is a derivate of the struct event. It contains an event-id to identify
it at the receiver’s side referring to it’s original type. Then you can
type-cast it to enable accessing the actual data. Both sides are using the
same set of events.

Limitations

This events are not allowed to carry pointers or std-containers. Only
primitive data types are allowed. This is because the framework does not
serialize any data before sending. So pointers or high-level containers
(using pointers) cannot be sent or received, unless serializing them first.

Licence and structure

I released the project under CC BY-NC 3.0. You can find the source code at
the linked GitHub-Repository: the framework is placed inside the
src-directory. Also you can find an example inside the example-directory.

Additional notes

The project is already using features of C++11. Actually, I like to make
it independent from C++11, because of the missing support of many
compilers. That is why I implemeneted all threading stuff using SDL_thread.

I am curious about your feedback!

With kind regards
Glocke


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

And this, right?
http://gameprogrammer.com/net2/net2-0.html

Jonny DOn Sat, Mar 16, 2013 at 2:05 PM, Sam Lantinga wrote:

Out of curiosity, have you seen this?
http://gameprogrammer.com/fastevents/fastevents1.html

On Sat, Mar 16, 2013 at 3:32 AM, Glocke wrote:

**
Hi there,

In advance: I already postet this at the “Game Development”-Subforum of
this board. But know I noticed that subforum is used for general game
discussion and not SDL-based discussion (the title “SDL Development” seemed
confusing to me ^^). To get more feedback I would like to post the
following stuff here. If the moderators dislike this double-posting, pleace
delete the old one [image: Confused]

I am working with SDL using C++. Because I did not found something
suitable yet, I startet solving the problem on my own:
https://github.com/cgloeckner/networking

It is a framework for C++ using SDL and SDL_net; its aim is to offer
sending “events” over the network and handling them after receive. The
events are enqueued in a thread-safe fifo queue before sending. Any
received events are also enqueued in an also thread-safe fifo queue at the
receiver’s side. They will stay there until they were handled. Each event
type is a derivate of the struct event. It contains an event-id to identify
it at the receiver’s side referring to it’s original type. Then you can
type-cast it to enable accessing the actual data. Both sides are using the
same set of events.

Limitations

This events are not allowed to carry pointers or std-containers. Only
primitive data types are allowed. This is because the framework does not
serialize any data before sending. So pointers or high-level containers
(using pointers) cannot be sent or received, unless serializing them first.

Licence and structure

I released the project under CC BY-NC 3.0. You can find the source code
at the linked GitHub-Repository: the framework is placed inside the
src-directory. Also you can find an example inside the example-directory.

Additional notes

The project is already using features of C++11. Actually, I like to make
it independent from C++11, because of the missing support of many
compilers. That is why I implemeneted all threading stuff using SDL_thread.

I am curious about your feedback!

With kind regards
Glocke


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

Just a remark: Creative Common licenses are explicitly suggested to
not be used for code, they’re meant for non-functional stuff. Try to
find an equivalent license designed specifically for software.

2013/3/16, Jonathan Dearborn :> And this, right?

http://gameprogrammer.com/net2/net2-0.html

Jonny D

On Sat, Mar 16, 2013 at 2:05 PM, Sam Lantinga wrote:

Out of curiosity, have you seen this?
http://gameprogrammer.com/fastevents/fastevents1.html

On Sat, Mar 16, 2013 at 3:32 AM, Glocke wrote:

**
Hi there,

In advance: I already postet this at the “Game Development”-Subforum of
this board. But know I noticed that subforum is used for general game
discussion and not SDL-based discussion (the title "SDL Development"
seemed
confusing to me ^^). To get more feedback I would like to post the
following stuff here. If the moderators dislike this double-posting,
pleace
delete the old one [image: Confused]

I am working with SDL using C++. Because I did not found something
suitable yet, I startet solving the problem on my own:
https://github.com/cgloeckner/networking

It is a framework for C++ using SDL and SDL_net; its aim is to offer
sending “events” over the network and handling them after receive. The
events are enqueued in a thread-safe fifo queue before sending. Any
received events are also enqueued in an also thread-safe fifo queue at
the
receiver’s side. They will stay there until they were handled. Each
event
type is a derivate of the struct event. It contains an event-id to
identify
it at the receiver’s side referring to it’s original type. Then you can
type-cast it to enable accessing the actual data. Both sides are using
the
same set of events.

Limitations

This events are not allowed to carry pointers or std-containers. Only
primitive data types are allowed. This is because the framework does not
serialize any data before sending. So pointers or high-level containers
(using pointers) cannot be sent or received, unless serializing them
first.

Licence and structure

I released the project under CC BY-NC 3.0. You can find the source code
at the linked GitHub-Repository: the framework is placed inside the
src-directory. Also you can find an example inside the
example-directory.

Additional notes

The project is already using features of C++11. Actually, I like to make
it independent from C++11, because of the missing support of many
compilers. That is why I implemeneted all threading stuff using
SDL_thread.

I am curious about your feedback!

With kind regards
Glocke


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

Sik wrote:

Just a remark: Creative Common licenses are explicitly suggested to
not be used for code, they’re meant for non-functional stuff. Try to
find an equivalent license designed specifically for software.

Do you have a suggestion referring a “better” licence? :slight_smile:

Sam Lantinga wrote:

Out of curiosity, have you seen this?http://gameprogrammer.com/fastevents/fastevents1.html (http://gameprogrammer.com/fastevents/fastevents1.html)

Jonny D wrote:

And this, right?http://gameprogrammer.com/net2/net2-0.html (http://gameprogrammer.com/net2/net2-0.html)

No, I didn’t knew anything about Net2 nor FastEvents. But on the first sight it doesn’t look completly as my solution. What’s your opinion on my solution?

Kind regards, Glocke

SDL 2.0 uses the zlib license:
Simple DirectMedia Layer
Copyright © 1997-2013 Sam Lantinga <@slouken>

This software is provided ‘as-is’, without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:

  1. The origin of this software must not be misrepresented; you must not
    claim that you wrote the original software. If you use this software
    in a product, an acknowledgment in the product documentation would be
    appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not be
    misrepresented as being the original software.
  3. This notice may not be removed or altered from any source distribution.On Sat, Mar 16, 2013 at 3:46 PM, Glocke wrote:

**

Sik wrote:

Just a remark: Creative Common licenses are explicitly suggested to
not be used for code, they’re meant for non-functional stuff. Try to
find an equivalent license designed specifically for software.

Do you have a suggestion referring a “better” licence? [image: Smile]

Sam Lantinga wrote:

Out of curiosity, have you seen this?
http://gameprogrammer.com/fastevents/fastevents1.html

Jonny D wrote:

And this, right?http://gameprogrammer.com/net2/net2-0.html

No, I didn’t knew anything about Net2 nor FastEvents. But on the first
sight it doesn’t look completly as my solution. What’s your opinion on my
solution?

Kind regards, Glocke


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

The CC license he used forbids commercial usage (NC) and demands
crediting if used (BY), though, something the zlib license doesn’t do
(zlib’s is extremely permissive). Software that doesn’t support
commercial usage generally comes with its own custom license (although
most of the time they say more or less the same thing).

2013/3/16, Sam Lantinga :> SDL 2.0 uses the zlib license:

Simple DirectMedia Layer
Copyright © 1997-2013 Sam Lantinga

This software is provided ‘as-is’, without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:

  1. The origin of this software must not be misrepresented; you must not
    claim that you wrote the original software. If you use this software
    in a product, an acknowledgment in the product documentation would be
    appreciated but is not required.
  2. Altered source versions must be plainly marked as such, and must not
    be
    misrepresented as being the original software.
  3. This notice may not be removed or altered from any source
    distribution.

On Sat, Mar 16, 2013 at 3:46 PM, Glocke wrote:

**

Sik wrote:

Just a remark: Creative Common licenses are explicitly suggested to
not be used for code, they’re meant for non-functional stuff. Try to
find an equivalent license designed specifically for software.

Do you have a suggestion referring a “better” licence? [image: Smile]

Sam Lantinga wrote:

Out of curiosity, have you seen this?
http://gameprogrammer.com/fastevents/fastevents1.html

Jonny D wrote:

And this, right?http://gameprogrammer.com/net2/net2-0.html

No, I didn’t knew anything about Net2 nor FastEvents. But on the first
sight it doesn’t look completly as my solution. What’s your opinion on my
solution?

Kind regards, Glocke


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

With the exception of the few events that hold pointers, you could just perform a direct memory copy of the event (using memcpy to place it into a C-style buffer, or casting to char* and appending it to a vector style buffer, or casting to char and using it as the buffer argument for send and recv).
For any that do hold pointers, you’ll absolutely need to use a buffer, and create your own similar struct that replaces the pointer with the offset of the pointer’s contents in the stream (this is essentially how many archive file formats work).

I see you are using SDL_net for the server as well as the client. SDL_net may be very good for game clients, but it is not a wise choice for a game server (especially if it is meant to be massively multiplayer). I personally recommend using boost.asio for game servers, it has served me quite well in the past.------------------------
Nate Fries

Nathaniel J Fries wrote:

I see you are using SDL_net for the server as well as the client. SDL_net may be very good for game clients, but it is not a wise choice for a game server (especially if it is meant to be massively multiplayer). I personally recommend using boost.asio for game servers, it has served me quite well in the past.

What’s the problem about using SDL_net for servers?

Glocke wrote:

Nathaniel J Fries wrote:

I see you are using SDL_net for the server as well as the client. SDL_net may be very good for game clients, but it is not a wise choice for a game server (especially if it is meant to be massively multiplayer). I personally recommend using boost.asio for game servers, it has served me quite well in the past.

What’s the problem about using SDL_net for servers?

Depends on what the server is going to be used for.
If it’s a simple MUD server intended for only a handful of players, SDL_net would work just fine.
If there won’t be much, if any, common resources between clients; SDL_net would work just fine.
If there’s going to be dozens of clients constantly accessing common resources, you will quickly find a bottleneck at mutually exclusive code, generally at ~50 clients (and it will become unbearable by the time you reach 100).

When developing software for others (such as a library), you should assume the most burdensome common intention: in this specific case, MMORPG.

Being fairly clever, you might be able to dodge the mutual exclusion bottleneck, but you’ll have essentially implemented the same thing as boost.asio’s generic implementation anyway, while wasting many man-hours’ work, research, and debugging in the process. And it still won’t be nearly as effective as boost.asio’s specialized implementations…------------------------
Nate Fries

Nathaniel J Fries wrote:

[…] you will quickly find a bottleneck at mutually exclusive code, generally at ~50 clients (and it will become unbearable by the time you reach 100).

Ah okay, that’s the point :slight_smile: I think I’ll put this to my todo-list. MMORPG is a very specific genre but - as you said - a possible case of using networking frameworks ^^ So you’re right :slight_smile:

But to go more in detail: Can problem about accessing mutual exclusive code (I hope I’m right: locking common resources with a mutex? :smiley: ) be diminished by using std::mutex or so?

Does anybody else likes to comment on my framework? :slight_smile:

Message-ID: <1363429921.m2f.36105 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

Hi there,

In advance: I already postet this at the “Game Development”-Subforum of this
board. But know I noticed that subforum is used for general game discussion
and not SDL-based discussion (the title “SDL Development” seemed confusing
to me ^^). To get more feedback I would like to post the following stuff
here. If the moderators dislike this double-posting, pleace delete the old
one :?

I am working with SDL using C++. Because I did not found something suitable
yet, I startet solving the problem on my own:
https://github.com/cgloeckner/networking

It is a framework for C++ using SDL and SDL_net; its aim is to offer sending
"events" over the network and handling them after receive. The events are
enqueued in a thread-safe fifo queue before sending. Any received events are
also enqueued in an also thread-safe fifo queue at the receiver’s side. They
will stay there until they were handled. Each event type is a derivate of
the struct event. It contains an event-id to identify it at the receiver’s
side referring to it’s original type. Then you can type-cast it to enable
accessing the actual data. Both sides are using the same set of events.

Limitations

This events are not allowed to carry pointers or std-containers. Only
primitive data types are allowed. This is because the framework does not
serialize any data before sending. So pointers or high-level containers
(using pointers) cannot be sent or received, unless serializing them first.

Licence and structure

I released the project under CC BY-NC 3.0. You can find the source code at
the linked GitHub-Repository: the framework is placed inside the
src-directory. Also you can find an example inside the example-directory.

Additional notes

The project is already using features of C++11. Actually, I like to make it
independent from C++11, because of the missing support of many compilers.
That is why I implemeneted all threading stuff using SDL_thread.

I am curious about your feedback!

With kind regards
Glocke

I’m actually only going to touch on the threading facilities: suffice
it to say, I prefer my version:
http://sdlcp.svn.sourceforge.net/viewvc/sdlcp/SDLCP/trunk/thread.hpp?revision=9&view=markup
http://sdlcp.svn.sourceforge.net/viewvc/sdlcp/SDLCP/trunk/thread.cpp?revision=9&view=markup
I never actually compiled them (in fact, very shortly afterwards I
switched more-or-less entirely to C, for the sake of some compiler
work that I still haven’t finished), but my version of “thread” should
require little, if any, effort to make it work. In fact, I think it
only needs a few more constructor versions, and some preprocessor
support so that you can add in C++ variadic templates.

Also, it implements close to what the C++11 spec looked like when I
wrote it. Among other things you can get directly at the underlying
SDL thread id, and sort the “native” id.

I have no idea why I added stream support.

At any rate, I’d suggest revising your thread type to look more like
mine. It makes it an easy alternative to the standard library if a
particular platform supports SDL but not C++11 (which seems likely for
a while, given the size), and has more features (guaranteed
sortability!).

Incidentally, where are you getting SDL_KillThread from? The only sign
of it that I see is for SDL 1.2 (while the current focus is shifting
to SDL 2.0, where I couldn’t find the function in the out-of-date
wiki, OR the mercurial repo), and from what I understand not every
platform that has threading actually has an API for that behavior
(some on the unixes are on that list, as I best recall).> Date: Sat, 16 Mar 2013 03:32:01 -0700

From: “Glocke”
To: sdl at lists.libsdl.org
Subject: [SDL] [Framework] Event-based Networking

Jared Maddox wrote:

Incidentally, where are you getting SDL_KillThread from? The only sign
of it that I see is for SDL 1.2

I am using SDL 1.2 ^^

terminate the thread cleanly and leaves it hanging around in the process table until the parent exits).

So as a matter of design NEVER kill threads! You need to tell them to exit by other means (and remember mutex is not the only synchronization primitive in your toolbox - semaphores and condvars have
significant utility).On 03/18/2013 05:30 AM, Glocke wrote:

Jared Maddox wrote:
Incidentally, where are you getting SDL_KillThread from? The only sign
of it that I see is for SDL 1.2

I am using SDL 1.2 ^^

From experience porting apps from Windows to Linux and OSX, the platforms that have KillThread functionality have giant hazard warnings in the API docs, because it leaks resources (it does not

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

Forest Hale wrote:

From experience porting apps from Windows to Linux and OSX, the platforms that have KillThread functionality have giant hazard warnings in the API docs, because it leaks resources (it does not
terminate the thread cleanly and leaves it hanging around in the process table until the parent exits).

So as a matter of design NEVER kill threads! You need to tell them to exit by other means (and remember mutex is not the only synchronization primitive in your toolbox - semaphores and condvars have
significant utility).

That’s right! I read this at the documentation about SDL_CreateThread. The killing-part is just a left-over piece of code. I will replace it in the future.

Message-ID: <1363609807.m2f.36172 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

Jared Maddox wrote:

Incidentally, where are you getting SDL_KillThread from? The only sign
of it that I see is for SDL 1.2

I am using SDL 1.2 ^^

Message-ID: <51473E94.5010409 at ghdigital.com>
Content-Type: text/plain; charset=ISO-8859-1

Jared Maddox wrote:

Incidentally, where are you getting SDL_KillThread from? The only sign
of it that I see is for SDL 1.2

I am using SDL 1.2 ^^

From experience porting apps from Windows to Linux and OSX, the platforms
that have KillThread functionality have giant hazard warnings in the API
docs, because it leaks resources (it does not
terminate the thread cleanly and leaves it hanging around in the process
table until the parent exits).

So as a matter of design NEVER kill threads! You need to tell them to exit
by other means (and remember mutex is not the only synchronization primitive
in your toolbox - semaphores and condvars have
significant utility).


LordHavoc

In conclusion: Glocke, you should remove the kill function from your
code, and generify it sufficiently that it works natively with both
SDL 1.2 and SDL 2.0. Further, I suggest redesigning the thread api to
resemble the one provided by C++11, so that your code can be quickly
and easily used as a replacement for the C++11 library on platforms
that support SDL, but don’t have C++11 thread support implemented.

I especially recommend the SDL 2.0 portion. SDL 1.2 is now antiquated
by virtue of it’s API, and there’s no changing that. If you want your
library to be used, then you need to target SDL 2.0> Date: Mon, 18 Mar 2013 05:30:07 -0700

From: “Glocke”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] [Framework] Event-based Networking
Date: Mon, 18 Mar 2013 09:19:32 -0700
From: Forest Hale
To: sdl at lists.libsdl.org
Subject: Re: [SDL] [Framework] Event-based Networking
On 03/18/2013 05:30 AM, Glocke wrote:

Glocke wrote:

Nathaniel J Fries wrote:

[…] you will quickly find a bottleneck at mutually exclusive code, generally at ~50 clients (and it will become unbearable by the time you reach 100).

Ah okay, that’s the point :slight_smile: I think I’ll put this to my todo-list. MMORPG is a very specific genre but - as you said - a possible case of using networking frameworks ^^ So you’re right :slight_smile:

But to go more in detail: Can problem about accessing mutual exclusive code (I hope I’m right: locking common resources with a mutex? :smiley: ) be diminished by using std::mutex or so?

Does anybody else likes to comment on my framework? :slight_smile:

Mutexes are the source of the bottleneck (using binary semaphores, critical sections, condition variables, or spinlocks will have the same effective result, and the same effective problem). Mutex is short for “mutual exclusion”, so when I said “mutually exclusive code”, I literally meant “code that uses mutexes”.
If you don’t use mutexes, you wouldn’t have a bottleneck, you’d have something way worse – code that compiles just fine but doesn’t work at all!

Anyway, the cleverness I talked of involves using non-blocking I/O on sockets (via SDLNet_SocketReady() IIRC) and SDLNet_CheckSockets() to drive a single network thread. You could optimize this some with a thread-per-processor and doing some load balancing, but ultimately it would still fall well short of what is provided by I/O Completion Ports, epoll, kqueue, or whatever other operating systems provide, and which boost.asio cleverly wraps.------------------------
Nate Fries

Nathaniel J Fries wrote:

Anyway, the cleverness I talked of involves using non-blocking I/O on sockets (via SDLNet_SocketReady() IIRC) and SDLNet_CheckSockets() to drive a single network thread. You could optimize this some with a thread-per-processor and doing some load balancing, but ultimately it would still fall well short of what is provided by I/O Completion Ports, epoll, kqueue, or whatever other operating systems provide, and which boost.asio cleverly wraps.

Actual I am using non-blocking TCP sockets by using SocketReady and CheckSockets. But I tried to reduce massivly thread-usage in the first place to enable easier debugging. But you’re right: using some more threads would enable improved performance on multi-processor computers. But what’s a suitable number of threads (server-sided): one for accepting clients, and one per client? Or is it too much? From the point of multi-processor computer it might be simple: one thread per client. But does this have a negative effect on single-processor devices? I don’t know :?

Jared Maddox wrote:

In conclusion: Glocke, you should remove the kill function from your
code, and generify it sufficiently that it works natively with both
SDL 1.2 and SDL 2.0. Further, I suggest redesigning the thread api to
resemble the one provided by C++11, so that your code can be quickly
and easily used as a replacement for the C++11 library on platforms
that support SDL, but don’t have C++11 thread support implemented.

Okay, more C++11 ^^

Jared Maddox wrote:

I especially recommend the SDL 2.0 portion. SDL 1.2 is now antiquated
by virtue of it’s API, and there’s no changing that. If you want your
library to be used, then you need to target SDL 2.0

I focused on SDL 1.2 after some experiments with SDL 2.0. Unfortunally I had huge problems with linking (absolutly my fault), so I decided to stay at SDL 1.2 at the first place and adapt my code in future to by SDL 2.0 ready.

/EDIT:

Please reply to your post instead, so the mailing list will see your message.

There are some questions in the context of SDL_net:

 Do I have to consider Endianness?

 Should I use fix-sized-types for my events (e.g. http://en.cppreference.com/w/cpp/types/integer, might be important for using 32-bit and 64-bit systems in one communication) ?

 Or should I use serialization to avoid both possible issues?

[/url]

/EDIT2:

Jared Maddox wrote:

I suggest redesigning the thread api to
resemble the one provided by C++11, so that your code can be quickly
and easily used as a replacement for the C++11 library on platforms
that support SDL, but don’t have C++11 thread support implemented.

Well, I would prefer wrapping my Threading around C++11-Threading. At the moment my framework requires a lot C++11-stuff. So using C++11-Threading seems meanigful to me.