
I recently have answered several questions about how to structure a networking library such that it can be easy to use for users of the library and/or when expanding the game you're writing. Here are some thoughts on that. (Code examples in C++)
Networking generally ends up needing to do three things:
1) Mirror state updates from one object to another.
2) Request remote services ("RPC").

A simple command-line program that exercises parts of the Etwork API and asserts if something fails. Think of it as an API acceptance test.

#if !defined( etwork_sockimpl_h ) #define etwork_sockimpl_h #include "etwork/etwork.h" #include "etwork/locker.h" #include "etwork/buffer.h" #include "etwork/timer.h" #include "etwork/errors.h" #include "etwork/notify.h" #if defined( WIN32 ) #include <windows.h> #endif #include <stdio.h> // for _snprintf #include <math.h> #include <string> #include <map>

#include "sockimpl.h" using namespace etwork; using namespace etwork::impl; SocketManager::SocketManager() { listening_ = INVALID_SOCKET; maxNumSocks_ = FD_SETSIZE; numSocks_ = 0; maxSock_ = 0; allSet_ = (fd_set *)::operator new( sizeof(fd_set) ); FD_ZERO( allSet_ ); readSet_ = (fd_set *)::operator new( sizeof(fd_set) ); FD_ZERO( readSet_ );

If you've ever wanted to read web pages into your C or C++ program, then this code is for you. It's the smallest possible code that will let you read arbitrary web URLs into your own program. It does NOT have any kind of interesting features, and is not coded to be fully standards compliant, but:

When you send packets over TCP, you have to precede them with a byte count, because TCP just delivers a stream of bytes, with no particular block size. If you don't delimit your packets somehow, they will run into each other, and you won't be able to tell where one ends and the next one starts.

his book will get you started using etwork without too much pain.
Necessary pre-requisites include:
