Sign in to follow this  
Kris_A

Socket Descriptor Range

Recommended Posts

Kris_A    182
Hi, This might seem like an odd question, but is it possible to get the minimum and maximum descriptor number a socket can contain? I'm trying to make a lookup array, where each element in the array points to a struct associated with that particular socket (I'm using asynchronous event-driven sockets). Thanks, Kris

Share this post


Link to post
Share on other sites
mattd    1078
From http://tangentsoft.net/wskfaq/articles/lame-list.html (section 4):

Quote:

The only invalid socket handle value is defined by the winsock.h file as INVALID_SOCKET. Any other value the SOCKET type can handle is fair game, and an application must handle it. In any case, socket handles are supposed to be opaque, so applications shouldn't depend on specific values for any reason.

Share this post


Link to post
Share on other sites
Kris_A    182
Damn, that's a shame.

I'm not that familiar with hash tables - would using them be significantly faster than just looping through the list of users until a matching socket is found?

Share this post


Link to post
Share on other sites
Megahertz    286
Quote:
I'm not that familiar with hash tables - would using them be significantly faster than just looping through the list of users until a matching socket is found?


Yes. As long as you have a decent number of items to search through.

-=[ Megahertz ]=-

Share this post


Link to post
Share on other sites
Tim Cowley    340
Presumably you're using a WaitOnMultipleObjects call to watch your sockets. Why not store a parallel array of info structs for each socket? Granted, it's not exactly pretty, but it gets the job done...fast [grin]

EDIT: By the way, I _think_ SOCKETs themselves are actually relative pointers; try making a bunch of them and outputting their literal values. All separated by 4 bytes on my 32-bit system.

Share this post


Link to post
Share on other sites
Kris_A    182
Quote:
Original post by Tim Cowley
Presumably you're using a WaitOnMultipleObjects call to watch your sockets. Why not store a parallel array of info structs for each socket? Granted, it's not exactly pretty, but it gets the job done...fast [grin]


Good idea [smile], but I'm not using that, I've got a window set up to recieve FD_ events (Set up with WSAAsyncSelect), which, of course, has no idea which object instance a socket belongs to.

I've made myself a simple hash array class which seems to be working fine so far. I'm in trouble, though, if a socket descriptor decides to be a negative value (which, according to the 'lameness list' is perfectly legal as long as it isn't -1) or extremely large. Maybe I'll be safer just doing a brute force search on each user...

Share this post


Link to post
Share on other sites
Tim Cowley    340
Quote:
Original post by Kris_A
Quote:
Original post by Tim Cowley
Presumably you're using a WaitOnMultipleObjects call to watch your sockets. Why not store a parallel array of info structs for each socket? Granted, it's not exactly pretty, but it gets the job done...fast [grin]


Good idea [smile], but I'm not using that, I've got a window set up to recieve FD_ events (Set up with WSAAsyncSelect), which, of course, has no idea which object instance a socket belongs to.

I've made myself a simple hash array class which seems to be working fine so far. I'm in trouble, though, if a socket descriptor decides to be a negative value (which, according to the 'lameness list' is perfectly legal as long as it isn't -1) or extremely large. Maybe I'll be safer just doing a brute force search on each user...

Well, you can pull off a similar trick with asyncselect. Just have a WM_SOCKET(x) (WM_USER/APP + x) macro, and give each socket a different message. Definitely a plus for performance; whether or not the extra complication is worth it to you is another matter.

My current implementation separates the socket "watching" from the rest of the library, allowing me to move to thread-based watching later on with little effort. I have a list of SocketWatchers, each representing a window (asyncselect) or a thread (eventselect), and containing a static array of my own socket class (indexed by each socket's unique message).

Again, ugly, but it works. I still think there should be a SetWindowLong equivalent for winsock though. The nearest you can get to that is by cheating horribly and "borrowing" the reserved group value via setsockopt, and - assuming you're storing a pointer there - you're still bound to 32-bit systems :p

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this