libbind / FD_SETSIZE question (on Windows)

[Stefan Puiu]

Hello Danny and thanks for replying,

you pretty much confirmed our fears. I guess the only available 
workaround is to fix the libbind code (the INVALID_SOCKET and highestFD 
issues being on top of the list - I guess that would be enough in order 
to get rid of the ENOTSOCK errno). Who can I send libbind patches to :)?

Danny Mayer wrote:

> At 10:29 AM 12/15/2004, Stefan Puiu wrote:
>
> This is a much more complicated subject than you may realise. The 
> problems
> that you are seeing here in the library on Windows is one of the reasons
> that the socket code was completely rewritten for Windows in the BIND 9
> native code. The other was related to performance.
>
> The problem is related to the fact that the Windows socket() function 
> returns
> a 32-bit unsigned integer which can and does take any value in that range
> of numbers. FD_SETSIZE is really only valid for the FDSET for the 
> select()
> function and does not relate to the value of the socket fd, it's just the
> maximum number of possible sockets that the select() can handle. (I'm
> simplifying somewhat here). On Unix systems, fd's are basically created
> sequentially. Not so on Windows which could hand toy virtually any number
> whatsoever that isn't currently being used and regularly returns a large
> number. Even if it doesn't I nornally seeing it start with 1000 and go 
> up from
> there. It's not practical to create a 4-gigabyte size array just to 
> allowing
> indexing into it by fd and it's a VERY sparse array anyway. On Unix
> FD_SETSIZE is used to set up an array where the index is the fd value.
> A better strategy is to use a list to hold the info, but then noone's 
> really
> wants to implement all of the necessary changes especially large changes.
>
> For Windows the snippet above already shows a problem since the code
> should use INVALID_SOCKET instead of -1. Create the Macro for Unix
> to be -1 and using INVALID_SOCKET would make this work on all Unix and
> Windows platforms, but that's a simple change. On WIndows highestFD would
> be 2**32-1 and not be related to FD_SETSIZE.
>
> I don't have time to look at the code and it's been a long time since 
> I touched
> the BIND 8 code but I suspect that there's a lot more work that would
> need to be done here to get all of the problems fixed.
>
> Danny
>
>
>