Im currently making a network API for my engine and I have some trouble with the design, Id like some opinions before I shoot my foot off. What I got so far is a base class for the API (CNetwork) that holds some general settings, enumeration of adapters etc. From CNetwork you start a listener (CListener), there are 2 listeners as of now (CUDPListener, CTCPListener). The listener has a list of incoming connections (CTCPConnection, CUDPConnection) that it has accepted. Every listener is running in its own thread. When it is full (ie 100 clients) it closes the listening socket and tells CNetwork to start a new thread for a new CListener. It may also relay connections to another server if the limit of number of threads is reached. Everything works well, however, what I need help is with is this; If you used an API like this, how would you want the connections delivered to you? Internally, I got good track of them. Lets say I make a gameserver, the server has a "player" object for each client, where he holds all the stats about the client. In this object he wants a reference to the connection in the network API. He dont know anything about where I store them etc. do I, A) Set a flag somewhere that I got a new connection and let him fetch a pointer to the connection directly. B) Let the user have access to the list of active connections and let him keep track of them himself. C) Give him an ID, that he passes into the CNetwork class. ie. ( SendPacket(ClientID, Packet); D) Something else.. I have spoken.

I would suggest using method A or C. Dplay uses the ID method and it seems to work pretty well. Its easy to keep track of ID''s within your own array and let the API do all the work behind the scenes for you. Also ,there would be less chance for user screw-ups if it was all encapsulated.

The A method also has its advantages. It''d give more control theoretically and it''d also be faster since its a more direct approach. No need for messing with functions through the API to manipulate the clients like the method C way you described. Though there would be a better chance for user screw-ups if you left the connections open directly for user manipulation.

Just my .02...

One way you could go is to have kind of a combo of A & C...where your API has some functions like:

GetClientID()
GetClientAddress()

This way, for simpler games you could go the ID route, but if you wanted more advanced features, like the server being able to ban an address, or something like that, you could get access to more info.

Just an idea

-John

For notification of events occurring inside an API (or library) callbacks can work quite well. This is how I handle letting the app know of new connections and dropped connections (connections dropped due to horrendous packet loss) in ONP (http://ogwnn-np.sourceforge.net).