Network API overviewAbstract:This document explains how to write network games with ClanLib's network model. Using examples it shows how to things manually in a low level manner. And then shows how much of the administrative parts of the code can be avoided using the layer2 netchannels ClanLib provides. Note: This overview has NOT been updated in this release. Beware that some issues might not be correct compared to the ClanLib version you have installed. ClanLib Networking, the lowlevel part:Let us start at the basics. Any network game needs to setup the physical connection between server and clients. In ClanLib, this is done by either creating a network game (CL_Network::create_game()) or connecting to one (CL_Network::find_game_at() / CL_Network::find_games_broadcast()). Example that creates a network game: CL_NetGame *netgame = CL_Network::create_game("MyGame", 5555); And a join game example: CL_NetGame *netgame; CL_Network::find_game_at("MyGame", "my.server.net", 5555); try { netgame = CL_Network::receive_game_found(5000); } catch (CL_Error err) { cout << "Join failed: " << err.message << endl; } All communication between the computers in the game go thru the CL_NetGame class. It currently provide three services:
NetChannels:A netchannel is analog to a network port. All IP communication is divided into different types, each assigned its own port. HTTP is handled on port 80, FTP on 21, telnet is 23 and so on. The same goes with network communication in ClanLib - here it is just called netchannel instead (to avoid confusion with IP ports). The main difference between a netchannel and a IP port is that all netchannels are packed into the same IP port. This is done to allow ClanLib games to be played easily through proxies and firewalls. It has also the advantage that ClanLib only uses one IP port, minimizing the chance to conflict with other applications. Network events:Events in the network code are computers joining, leaving, closure of the game and access changes. At the moment, the events are poll based. That means that you will have to call functions in CL_NetGame to retrieve the events. A clear advantages of this is that the program gets a clear linear flow - and people like me love that. :-) Recently, ClanLib got added an event system which, in time, will of course also include the network events. So in the future, you will have the choice of using whatever method that you like the best. Because we do not use signals/callbacks the game is required to check for events itself. CL_NetGame::receive_computer_join() for instance return the first joined computer, next time it called the next is returned, and when joined computers has been reported it returns NULL. It will keep returning NULL until a new computer joins the game. Access restrictions:ClanLib supports access restrictions on its netchannels. By default, the server doesn't allow clients to speak on any of the channels. The server must explicit allow each and every client access where it is supposed have it. This is done for security. Furthermore a client can have read access, write access or both, so it is very easy to keep a good eye on the clients - this is good, especially in Internet games. |