hey
does anyone know of a simple way i can assign a dword to a new socket everytime one is created using "accept" (with multiple sockets) so that i can refer to it later
like with the listbox control, where you can assign a dword to each individual entry
and then find out that dword later on.
i need this so that i can point every created socket to an individual structure with the connection info on it
if anyone can help or has any better (simple) ways of doing this?
thanks
Posted on 2004-03-20 02:01:57 by someone
Not that I know of. A typical way is to use an array with socket,pointer-to-structure pairs. You have to scan this table to find the structure associated with a socket. This solution feels sorta ugly, but in reality it works out okay - unless you expect to have like a zillion sockets :)

Another way would be using a threaded model, the pointer to the socket data can then be kept as local stack data in each thread. This also works fairly well, threading+WSAEventSelect scales okay, but for a huge amount of concurrent client connections, creating a thread per socket can be a bit wasteful.

Finally, for high-performance server code, you could use I/O Completion Ports... these require somewhat more fancy code, but should give you the very best performance at all. I haven't ever really messed with them (if I only had the spare time to mess with everything that I want to :P).
One of the interesting things with IOCP's is the following argument when you register a handle (file, socket, ...) in an I/O completion port:

CompletionKey
Per-file completion key that is included in every I/O completion packet for the specified file.
Posted on 2004-03-20 04:50:22 by f0dder
ok thanks fodder
Posted on 2004-03-20 22:07:33 by someone
Take a look at the CClient and CServer oop classes I posted in the networking forum - the CServer class does exactly as f0dder describes in respect to struct/hsocket association, and furthermore, the structs created are actually instances of the class (ie class objects). Adapting the code I presented to use a threaded approach would be as simple as implementing one thread per class instance.
Posted on 2004-03-21 01:31:27 by Homer
ok, i'll have a look, thanks
Posted on 2004-03-22 04:17:17 by someone