For those of you who are interested, I'm finishing off a rewrite of the IOCP code, such that is handles connect()/accept() behaviour.
Which is to say, you init the IOCP state, and all your socket behaviour is then routed through the callback function, which is simply called when an accept, connect or read occurs. You can add listen, to-be-connected or connected sockets to the IOCP. When a listen socket is added, all the user sees after that is that the accept callback is called when an incoming connection occurs and then the recv callback is called whenever a read occurs. The user does *no* other work - for example, he can just return from these functions should he wish. When a to-be-connected socket is added, the user passes in the socket and the remote address, and then the connect callback is called when the connect is successful and then after that the read callback every time a read successfully occurs. Similarly, with a connected sockets, all that happens is the read callback is called whenever a read occurs. So it's basically five functions; iocp_new() iocp_delete() iocp_add_listen_socket() iocp_connect_and_add_socket() iocp_add_connected_socket() And then all the user sees are the callbacks being called. There's one for accept, one for connect, one for recv and one for error. Typical use I think is to add the listen socket, then in the accept allocate your own internal state for that connection (you can in the accept function specify a user state pointer for the accept socket), in the recv callback deal with the data. _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
