How to find if a socket is in non-blocking mode on Windows
Rnjn
blocking mode on Windows. I understand that there can be two ways of
doing this on windows
- Call ioctlsocket with FIONBIO command.
- Call WSAAsyncSelect or WSAEventSelect.
I am writing a network library where my library function creates a
socket but the user might use above mentioned ways for putting the
socket into non-blocking mode independent of my library calls. Now
depending on the mode of the socket, my library should behave
differently. ioctlsocket seems to only provide way to set the socket
to blocking mode.
Is there a way of finding out this information?
Continuing in the same vein is there a way of quering the hWnd, wMsg,
and lEvent parameters passed in a WSAAsyncSelect call?
David Schwartz
When a socket is handed off between a library and an application, they
have to agree on what mode it should be in and how it will be used.
Or by "network library" do you mean something that integrates with
Winsock, like an LSP?
DS
Rnjn
It is not exactly an LSP but the behavior is pretty much close to
that. My
library provides SOCKS capabilities to the network applications. So
when
the application calls connect, the underlying function implementing
connect
call should behave in a different manner.
>
> DS
David Schwartz
> It is not exactly an LSP but the behavior is pretty much close to
> that. My
> library provides SOCKS capabilities to the network applications. So
> when
> the application calls connect, the underlying function implementing
> connect
> call should behave in a different manner.
How were you planning on intercepting the application's call to
connect? Why can't you intercept all the other calls that create/setup
the socket the same way so you know its state?
You have three choices:
1) If you want applications to access your program using the regular
Winsock API, you must be an LSP. There is simply no other way to get
all the various ways correct. (Completion ports, Windows event
notification, completion functions, blocking operations, and more.)
Applications don't even have to know your library is there, but you
have to properly support everything they might do which, for practical
purposes, requires an LSP.
2) If you want to define your own API, you can define it any way you
want. Applications will have to be specifically-coded to use your
library.
3) Intercept and perfectly emulate all socket calls that you need any
control over. If you did this, you'd already know if the socket was
blocking.
DS
Rnjn
>
> 2) If you want to define your own API, you can define it any way you
> want. Applications will have to be specifically-coded to use your
> library.
Well I am defining my own APIs and I was planning to implements APIs
corresponding to a limited set like
- socket
- connect
- bind
- send
- recv
- shutdown
- closesocket
- listen
- accept
- An API to retreive the actual platform socket/file descriptor This
API should
be called for setting up an event loop only and for no other
activities.
This set was chosen because ultimately the goal is to provide APIs on
atleast
Linux as well. The send and recv have been done in such a manner so as
to
accept callback function. Of course the semantics for calling this
callback
function would be different on Windows and Linux. I do not wish to
provide any
platform specific WSAAsyncSelect type calls.Rather I thought the user
can use
the winsock calls for setting up the event loop through the last
mentioned API.
Here the API corresponding to connect would not behave properly unless
I know
for sure the behaviour of the socket as well. That is why the original
set of
questions.
Best Regards,
RS
David Schwartz
> This set was chosen because ultimately the goal is to provide APIs on
> atleast
> Linux as well. The send and recv have been done in such a manner so as
> to
> accept callback function. Of course the semantics for calling this
> callback
> function would be different on Windows and Linux. I do not wish to
> provide any
> platform specific WSAAsyncSelect type calls.Rather I thought the user
> can use
> the winsock calls for setting up the event loop through the last
> mentioned API.
> Here the API corresponding to connect would not behave properly unless
> I know
> for sure the behaviour of the socket as well. That is why the original
> set of
> questions.
Then my advice would be to make one function that does the socket,
bind (if needed), and connect. Once you've done all the setup you need
to do, then hand it off to the application.
DS