• Advertisement
Sign in to follow this  

C++ Cross platform Network programming

This topic is 3345 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, if I want to write cross platform networking code in C++ what library should I use? Cheers

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Cacks
Hi,

if I want to write cross platform networking code in C++ what library should I use?

Cheers
Plain BSD sockets. On Windows you'll still need to call WSAStartup and WSACleanup, but that's just two function calls.

And the include files are different (sys/socket.h vs winsock2.h)

Share this post


Link to post
Share on other sites
So I can use the same code, just change the headers & add in the funstion calls?

Share this post


Link to post
Share on other sites
Quote:
Original post by Cacks
So I can use the same code, just change the headers & add in the funstion calls?
Yup, exactly. If possible, I'd test on a Linux machine, since Windows is a bit more forgiving with some of the function parameters (E.g. the first parameter to select() is unused on windows), and if you're using a fd_set, make sure you use the macros instead of setting struct values directly (Since fd_set is different on Linux).

Share this post


Link to post
Share on other sites
What about the different underlaying formats of primitives between the different platforms?

Would have to write code to handle this?

If so would it be difficult?

I would like to have it that Windows players could play against Mac players with a direct connection between them,

cheers

Share this post


Link to post
Share on other sites
Berkeley sockets and Winsock both provide the htons() and htonl() functions/macros to go between "host" byte order and "network" byte order, and back again. On the PowerPC Macs, those are no-ops. On Windows and x86 Macs, those do swap the byte order.
You can also use a serialization library -- many serialization libraries have a feature where they can serialize on one platform, but de-serialize on another.

Share this post


Link to post
Share on other sites
Quote:
Original post by Evil Steve
Plain BSD sockets. On Windows you'll still need to call WSAStartup and WSACleanup, but that's just two function calls.
[...]
So I can use the same code, just change the headers & add in the funstion calls?
[...]
Yup, exactly.
Almost. You need to make a typedef for the socket and a typedef for a "raw pointer", since they're different on Windows and Linux. Otherwise your compiler will choke on some functions.
You'll need to define the raw pointer type as char* for Windows and void* for Linux, and the socket type as SOCKET for Windows and int for Linux.

Share this post


Link to post
Share on other sites
Quote:
Original post by samoth
You'll need to define the raw pointer type as char* for Windows and void* for Linux, and the socket type as SOCKET for Windows and int for Linux.

There are other, trickier differemces. shutdown() works a little differently, for example, and O_NONBLOCK has vaguely different semantics, and so and so forth. You;re likely never to run into the corner cases doing basic simple stuff.

The most important difference between Windows socket programming and POSIX socket programming is that on a POSIX system, a socket is just a file handle and you can use select() on any file handle. On Windows, sockets live in their own namespace and select() will only work on sockets. Other than that and the WSAStartup requirement, you're good to go.

Share this post


Link to post
Share on other sites
Quote:
Original post by samoth
Quote:
Original post by Evil Steve
Plain BSD sockets. On Windows you'll still need to call WSAStartup and WSACleanup, but that's just two function calls.
[...]
So I can use the same code, just change the headers & add in the funstion calls?
[...]
Yup, exactly.
Almost. You need to make a typedef for the socket and a typedef for a "raw pointer", since they're different on Windows and Linux. Otherwise your compiler will choke on some functions.
You'll need to define the raw pointer type as char* for Windows and void* for Linux, and the socket type as SOCKET for Windows and int for Linux.
Ah, I forgot about those. Does SOCKET exist at all on Linux?

Share this post


Link to post
Share on other sites
Quote:
Ah, I forgot about those. Does SOCKET exist at all on Linux?

No it is just a file descriptor.
Quote:
On Windows, SOCKET is just an int typedef. AFAIK.

No it is a UINT_PTR which depending on the platform (64 or 32) has different sizes.
I seem to just be saying the same things on different places on the net :(

Share this post


Link to post
Share on other sites
In my experience of working across next-gen (current-gen?) console platforms, you can't rely on your socket api being the same across platforms. To a certain extent this is also true of PC platforms. More so in particular when you consider matchmaking functionality, which may be completely different across different platforms. If you want my advice, work with the native socket API of your chosen platform (which on PC platforms does tend to be a derivative of Berkeley sockets), and don't be afraid to separate your code so it will compile cleanly on each target platform, and just give it a common interface so some code can be shared, that's just cross-platform coding sense.

Also, I just wanted to add that the htons and htonl functions are C-style functions which convert the byte ordering of packet data to little endian. Obviously, on PPC platforms such as the old-style Mac (Pre Core2) which are already little endian, nothing needs to be done. On big endian platforms such as Intel x86 (windows, some linux variants), the bytes need to be reordered in reverse so that data transmitted over the network can be properly processed on different platforms.

Share this post


Link to post
Share on other sites
Quote:
Original post by TheGilb
Obviously, on PPC platforms such as the old-style Mac (Pre Core2) which are already little endian, nothing needs to be done. On big endian platforms such as Intel x86 (windows, some linux variants), the bytes need to be reordered in reverse so that data transmitted over the network can be properly processed on different platforms.


Just to clear up PPC is big endian and x86 is little endian.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement