I''m working on a networking library that uses Winsock (but not the Asynchronous WSA calls). I''m stuck on a design decision to determine how an application will receive notification of events happening on connections. My choices are callbacks or events. Callbacks: the application will register a callback with the network engine, specifying the address of a function that will be executed when the specified event takes place. For example, a server might call:

hbNetEngine::getInstance()->setCallback(this,listen,		
(networkCallback)&testServer::onClientAccept,				NETWORK_ACCEPT_CALLBACK); 

to register a callback for when a connection to a client is accepted/established. Then when the connection is established, the following might get executed:

hbNetEngine::getInstance()->executeCallback(this, NETWORK_ACCEPT_CALLBACK); 

Alternatively, I could use events. Say a connection is accepted with a client, the library would then create a network event and push it onto the event queue. Then inside the application event loop, it extracts each event from the queue and performs the appropriate action. The event loop is similar to the Windows message loop but it''s my own version. I prefer the idea of callbacks, but I''m worried about interrupting program flow when executing callbacks. Any ideas/suggestions? Thanks

How does your Winsock library compare to Windows internal non-blocking I/O such as OVERLAPPED I/O and IOCP?

I prefer a callback function because you have the object of sending back information about the socket such as its handle and data the callback function will process.

Kuphryn

I''m not familiar with what OVERLAPPED I/O and IOCP are in relation to Winsock/Windows, but my library includes non-blocking asynchronous connections. For example, if a client attempts to connect to a server that isn''t running, the initial connect() calls returns successfully. My code then detects a connection failure using the exception socket set in select(). Likewise the read and write socket sets are used with select() to determine when connections are dropped or established accordingly.

I'm 'trying' to implement something a little similar to you.

I am steering clear of any windows specific methods as my server just may be Unix.

On the Server side I'm thinking of having a blocked port running on a separate thread. When it recieves data (UDP) it then hands it off to an interpreter process so that it can get back to waiting on incoming packets. This other process then the interprets the packet and then sticks it in the appropriate queue to be processed by one of many worker threads that process queues.

Each queue is used to queue different data packets. i.e. entering/leaving a sector, chat, player environment interaction, etc...

Stay with me here....

Most queue processes will use a callback method to handle data packets. e.g.

1) Player 1 is in Sector X and sends a local chat message.
2) The Server recieves a chat data packet and it is placed in the chat queue.
3) The queue process then pulls the packet off the queue and enumerates all the players that are in Sector X, by calling the 'insert chat message' method.

Other queues will be event driven...

1) Player 1 in Sector X fires a round at Player 2.
2) Server places packet in the Environment queue.
3) Environment queue references the Sector X environment object and invokes the EnvironmentEvent method.


Something like that, I have reams of pencilled event diagrams and such, does it work? Of course it works, Does it work in real life? No clue.

[edited by - DeltaVee on November 12, 2002 3:00:41 PM]