🔒 Locked
learning c++ network programming
Advertisement
Original Post
Alright Im interested in learning how to do network programming in C++ that is portable across different OS's. Im not new to C++ but ive never done any network programming. I understand networking concepts in general so I started researching on books and libraries that C++ uses to accomplish portable networking services in programs. 1. Is ACE still in use and a good thing to use for portability if I was incorporating networking into my application? I was looking into getting "C++ Network Programming, Volume I: Mastering Complexity with ACE and Patterns" but I wasnt sure if ACE was still commonly used. 2. Is ACE the best thing to learn as a beginner in network programming? 3. What other options are there for portable network programming in C++ (does the stl provide anything) ? ***Any comments would be greatly appreciated, and I would aslo like to learn network programming so that I can make it as portable as possible as I dont want to get into OS specific implementations....
I've never used or heard of ACE. The STL does not provide any network functions or classes. Your best bet is to use Winsock, but stay away from the WSA*() functions (Except WSAStartup() and WSACleanup() of course). I managed to create a socket class that worked perfectly well in Windows as well as Linux (RedHat 8 and 9). I'm happy to share my code if you want, but it's not so pretty ;)
Well thats why I was asking... the bbook I was going to get is like 4 years old but it covers what I wanted to learn.
ACE (according to the book description) was an old attemp at making portable object oriented networking services for applications without having to deal with OS depenedent implementations.
If you wouldnt mind I would like to take a look at the code for winsock that you were talking about.
ACE (according to the book description) was an old attemp at making portable object oriented networking services for applications without having to deal with OS depenedent implementations.
If you wouldnt mind I would like to take a look at the code for winsock that you were talking about.
We just had ACE come up in the networking forum.
My opinion is that ACE is not very well suited to game programming at all, because it's an ORB-style framework, and it's "real time" support is based on resource reservation, not latency guarantees.
The best, and easiest, way to learn network programming is to learn Berkeley sockets (which is part of WinSock on Windows). These are a few C functions, but the interface is so small, you really don't need classes to deal with them -- there are no standard classes for this that I've seen. There are lots of non-standard helpers/wrappers -- check the Networking forum FAQ for a list of libraries to look at.
These are the functions you should learn:
socket, listen, accept, gethostbyname, connect, select, readfrom, sendto, close/closesocket
These are the structures you need to know:
sockaddr_in
hostent
That's it! Once you know these, you can write a networked game to rival the best of them! You may want to add ioctl/ioctlsocket for advanced configuration, but you usually don't have to.
This API is portable to any OS you're likely to use today (Linux, BSD, all flavors of Windows, MacOS X, Solaris, AIX, ...)
My opinion is that ACE is not very well suited to game programming at all, because it's an ORB-style framework, and it's "real time" support is based on resource reservation, not latency guarantees.
The best, and easiest, way to learn network programming is to learn Berkeley sockets (which is part of WinSock on Windows). These are a few C functions, but the interface is so small, you really don't need classes to deal with them -- there are no standard classes for this that I've seen. There are lots of non-standard helpers/wrappers -- check the Networking forum FAQ for a list of libraries to look at.
These are the functions you should learn:
socket, listen, accept, gethostbyname, connect, select, readfrom, sendto, close/closesocket
These are the structures you need to know:
sockaddr_in
hostent
That's it! Once you know these, you can write a networked game to rival the best of them! You may want to add ioctl/ioctlsocket for advanced configuration, but you usually don't have to.
This API is portable to any OS you're likely to use today (Linux, BSD, all flavors of Windows, MacOS X, Solaris, AIX, ...)
I have some simple network code I could post if you'd like as well. Both use the Berkeley sockets API. Two different versions...
1. Just simple helper functions for starting a passive socket, connecting to an address, sending and receiving ints, some number of bytes, or std strings. Just for Windows but easily ported for linux... just need to include the appropriate headers and get rid of the WSAStartup/WSACleanup function calls
2. Server and a Client class that inherit from a base class. Compiles under windows and linux. This is what I used in my last small project.
Neither are great but they suited my needs for their respective projects.
Header for #1:
Header for #2:
1. Just simple helper functions for starting a passive socket, connecting to an address, sending and receiving ints, some number of bytes, or std strings. Just for Windows but easily ported for linux... just need to include the appropriate headers and get rid of the WSAStartup/WSACleanup function calls
2. Server and a Client class that inherit from a base class. Compiles under windows and linux. This is what I used in my last small project.
Neither are great but they suited my needs for their respective projects.
Header for #1:
#ifndef NETWORKHELPER_H#define NETWORKHELPER_H#include <winsock2.h>#include <string>// Winsock startup and shutdown functionsbool StartWinSock(); // Sets up WinSockbool StopWinSock(); // Shutdown WinSockbool SetupServerForListening(SOCKET& socket_fd, struct sockaddr_in* sockAddr); // sets up a socket for the server to listen for connectionsbool ConnectTo(SOCKET& socket_fd, struct sockaddr_in* sockAddr); // sets up a connection and returns the socket // Setup the sockaddr_in struct using appropriate argumentsbool SetupSockAddrInStruct(const unsigned short port, const char* const address, struct sockaddr_in& sockAddr);// Sending Functionsbool SendInt(const int toSend, SOCKET to); // Send an int (handles host to net order)bool SendBytes(const char* const toSend, int num, SOCKET to); // Send num bytes from an array bool SendString(const std::string toSend, SOCKET to); // Send a string over a socket// Receiving Functionsbool RecvInt(int& toRecv, SOCKET from); // Receive an int (handles net to host order)int RecvBytes(char* const toRecv, int num, SOCKET from); // Receives num of bytes and stores in char arraybool RecvString(std::string& toRecv, SOCKET from); // Receives a string over a socket#endifHeader for #2:
#ifndef SAS_NETWORK_H#define SAS_NETWORK_H#ifdef WIN32 #include <winsock2.h>#else typedef int SOCKET;#endifnamespace sas{ // network base class class sasNetwork { public: sasNetwork(); virtual ~sasNetwork(); // Setup and shutdown functions... abstract so derived must implement these virtual bool Setup(unsigned short port, const char* const connectTo = NULL) = 0; virtual short CheckSocket() = 0; // uses the select function to poll the socket(s) to see if ready virtual bool Shutdown() = 0; // base class will take care of these short NetSndLong(long number); // send an int short NetRcvLong(long& number); // receive an int short NetSndShort(short number); short NetRcvShort(short& number); short NetSndNumBytes(const char* bytes, long num); short NetRcvNumBytes(char* const bytes, long num); static bool GetLocalIP(); protected: bool SetupSockAddrInStruct(unsigned short port, const char* address, struct sockaddr_in& sockAddr); fd_set m_AllFD; fd_set m_ReadFD; int m_MaxFD; bool m_Connected; // is there an active connection SOCKET m_CommSock; // main socket file descriptor... server // will have a listen socket as well }; // Server class class sasServer : public sasNetwork { public: sasServer(); // constructor ~sasServer(); // deconstructor bool Setup(unsigned short port, const char* const connectTo = NULL); // set up server to listen on a certain port // the connectTo should always be null short CheckSocket(); bool Shutdown(); // shutdown server protected: bool AcceptClient(); SOCKET m_ListenSocket; // server listening for connections on this socket }; // Client class class sasClient : public sasNetwork { public: sasClient(); // constructor ~sasClient(); // deconstructor bool Setup(unsigned short port, const char* const serverName); // connect to a server short CheckSocket(); bool Shutdown(); // shutdown the client };}#endif
Sockets are tricky when going between win32 and *nix, windows api does things a bit differently when dealing with descriptor sets (using arrays of descriptors instead of bitsets, luckily the macros FD_SET, etc are somewhat predictable).
You should make a decision of: am I going to use the sockets in games with direct X, if so learn the event driven socket system of windows, it's a bit more efficient than polling the socket or using selects (on windows at least which has a quick spooling CPU cycle whereas many *nix platform spool CPU usage slower and more pre-emptively).
If you plan on writing portable code between *nix and windows, you should learn the basic commands mentioned above (select, connect, listen ,etc) and see how they differ between the two platforms and maybe write a thin wrapper that suits your purpose without bothering to implement things you don't need.
ACE is a good and working library but it's a bit bulky for game development where every CPU cycle matters, for non game applications ACE is a very good library that is ported to a lot of platforms.
You should make a decision of: am I going to use the sockets in games with direct X, if so learn the event driven socket system of windows, it's a bit more efficient than polling the socket or using selects (on windows at least which has a quick spooling CPU cycle whereas many *nix platform spool CPU usage slower and more pre-emptively).
If you plan on writing portable code between *nix and windows, you should learn the basic commands mentioned above (select, connect, listen ,etc) and see how they differ between the two platforms and maybe write a thin wrapper that suits your purpose without bothering to implement things you don't need.
ACE is a good and working library but it's a bit bulky for game development where every CPU cycle matters, for non game applications ACE is a very good library that is ported to a lot of platforms.
For a cross-platform networking lib, check out Apple's OpenPlay.
Quote:
OpenPlay is a cross-platform network abstraction layer designed to simplify the task of creating programs which communicate across multiple computers.
While originally designed for multiplayer games, it is useful for any developer who wants an easy, platform-independent way to send messages to programs running on other machines. It completely abstracts both OpenTransport and Winsock, and its plug-in architecture makes it easy for you to support new transport protocols.
We used ACE at Cavedog for a lot of the network stuff on Total Annihilation, including the backend Boneyards stuff.
I found that the (somewhat old) Addison Wesley book "Windows Sockets Network Programming" was good for learning how to do TCP/UDP networking at the socket level. Then I used the ideas of Message Marshals and Message Handlers (as producers and consumers) from ACE as a layer on top of that to interface between the actual game and the network library. It all worked out pretty well for a racing game that I did the multiplayer for.
Sockets are pretty much sockets everywhere, so the WinSock book isn't a bad reference if you just want to learn about the low level stuff, and you're doing your primary coding with Visual Studio.
I found that the (somewhat old) Addison Wesley book "Windows Sockets Network Programming" was good for learning how to do TCP/UDP networking at the socket level. Then I used the ideas of Message Marshals and Message Handlers (as producers and consumers) from ACE as a layer on top of that to interface between the actual game and the network library. It all worked out pretty well for a racing game that I did the multiplayer for.
Sockets are pretty much sockets everywhere, so the WinSock book isn't a bad reference if you just want to learn about the low level stuff, and you're doing your primary coding with Visual Studio.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement