5

I am using IOCP in my client, but I find it more convenient to use a blocking call when connecting to the server. So is there any problem in using the blocking WSAConnect() instead of the non-blocking ConnectEx() when working with IOCP?

user6088487
  • 189
  • 6
  • 3
    Why are you using IOCP at all if you want synchronous I/O? – Mat Mar 22 '16 at 08:23
  • @Veronika Prüssels *"@Mat If I understand well the OP just cares about the call to connect to be blocking, for convenience reasons."* Yes this is what I want. *"@OP Nothing prevents you from intermixing ConnectEx with a blocking future and promise to use IOCP while still getting blocking behaviour."* What does that mean?! – user6088487 Mar 22 '16 at 08:31
  • @Mat it's fine to want the connecting itself to be synchronous and the reading/writing to be asynchronous. yes, it's funky, but non the last makes sense in some rare situations – David Haim Mar 22 '16 at 13:28

1 Answers1

5

Yes, it's perfectly fine.
a call to WSAConnect will block the thread until a connection has being created/ an error has occured. then, you can do asynchronous IO and get notification about completed packets with your application IOCP. the IOCP will not give any packets regarding WSAConnect.

Another point is that IOCP works exculsivly with Overlapped IO. if your function does not consume any memory location of OVERLAPPED struct (like WSAConnect), you can be sure that IOCP will not deal with that API call. even if OVERLAPPED supplied, that doesn't mean that the action is asynchronous and will be published in the IOCP.

you might want to take a look at Boost.Asio for C++ and libuv for C. the code then will be portable as well (and less buggish). another intresting platform is microsoft Casablanca, which is cross platform, but in my experince the performance is catastrophic.

David Haim
  • 25,446
  • 3
  • 44
  • 78
  • *"even if OVERLAPPED supplied, that doesn't mean that the action is asynchronous and will be published in the IOCP"* Can you clarify what you mean by this statement. Do you mean that I can for example call `WSARecv()` and pass it an `OVERLAPPED` struct and not receive a completion packet? – user6088487 Mar 22 '16 at 11:21
  • for example, `ReadFile` and `WriteFile` gets `OVERLAPPED` which species what offset of the file to start reading from. if the file handle was not opened for asynchronous actions, that action will completed synchronously. – David Haim Mar 22 '16 at 11:26
  • also, you need to explicitly associate the Handle into the IOCP in order to receive IO packets. so, to conclude you need the following conditions in order to get the IOCP going : 1) have handle which support asynchronous IO 2) associate the handle with the IOCP 3) use function which consume `OVERLAPPED` structs. if one of the condition does not apply, IOCP will not kick in for that function – David Haim Mar 22 '16 at 11:29
  • I have one last question: if my socket supports asynchronous IO, and I have associated the socket with the completion port, in this case there would still be no problem in using the blocking `WSAConnect()` on the socket, correct? – user6088487 Mar 22 '16 at 13:09
  • yes. as I said , because `WSAConnect` doesn't consume `OVERLAPPED` IOCP won't montor it at all. and the function still works without problem. – David Haim Mar 22 '16 at 13:19
  • It's also perfectly fine to mix in blocking WSASend() and WSARecv() calls with async IOCP calls on the same socket - though obviously not at the same time! It's unusual but it works just fine. – Len Holgate Apr 21 '16 at 13:22