I have used WriteFile and ReadFile in my tests with IOCP. But now I have a question about that.
The last two days I was looking for information about using WSASend/WSARecv or WriteFile/ReadFile when AcceptEx is used in an IOCP server. I found some sources that say to use WSASend instead of WriteFile, and another ones that say the opposite.
Untill Yesterday, MSDN said that when AcceptEx operation is successfully completed, the accepted socket can be passed, but to the following functions only:
And becasuse of that I have think that using WriteFile were well.
But I just went to MSDN to get information about AcceptEx and looks like today they changed the API description. They added the: WSASend and WSARecv APIs.
MSDN Today:
This was not consistent to me. That's the why I decided to post my question here.
So, now MS let me use WSASend and WSARecv.
I have read that using WSASend (instead of WriteFile) decrease of the number context switches, so, in this case will be better to use WSASend. But, the problem is that I do not know if this is true.
Comments are welcome.
Kecol.-
PS: Where is Thomas? We are going to start writing tutorials for him. :)
The last two days I was looking for information about using WSASend/WSARecv or WriteFile/ReadFile when AcceptEx is used in an IOCP server. I found some sources that say to use WSASend instead of WriteFile, and another ones that say the opposite.
Untill Yesterday, MSDN said that when AcceptEx operation is successfully completed, the accepted socket can be passed, but to the following functions only:
ReadFile
WriteFile
send
recv
TransmitFile
closesocket
setsockopt (only for SO_UPDATE_ACCEPT_CONTEXT)
WriteFile
send
recv
TransmitFile
closesocket
setsockopt (only for SO_UPDATE_ACCEPT_CONTEXT)
And becasuse of that I have think that using WriteFile were well.
But I just went to MSDN to get information about AcceptEx and looks like today they changed the API description. They added the: WSASend and WSARecv APIs.
MSDN Today:
When this operation is successfully completed, sAcceptSocket can be passed, but to the following functions only:
ReadFile
WriteFile
send
WSASend
recv
WSARecv
TransmitFile
closesocket
setsockopt (only for SO_UPDATE_ACCEPT_CONTEXT)
ReadFile
WriteFile
send
WSASend
recv
WSARecv
TransmitFile
closesocket
setsockopt (only for SO_UPDATE_ACCEPT_CONTEXT)
This was not consistent to me. That's the why I decided to post my question here.
So, now MS let me use WSASend and WSARecv.
I have read that using WSASend (instead of WriteFile) decrease of the number context switches, so, in this case will be better to use WSASend. But, the problem is that I do not know if this is true.
Comments are welcome.
Kecol.-
PS: Where is Thomas? We are going to start writing tutorials for him. :)
Kecol,
I would use the WSAxxxx API's over the xxxxFile API's as they handle multiple buffers, this is unless the protocol your
writing is better suited to files.
I prefer the WSAxxxx API's as you have better control over the send and receive process and the size and count of
buffers that will be used.
The MSDN doco was changed as far as I know.
Rgs, James.
I would use the WSAxxxx API's over the xxxxFile API's as they handle multiple buffers, this is unless the protocol your
writing is better suited to files.
I prefer the WSAxxxx API's as you have better control over the send and receive process and the size and count of
buffers that will be used.
The MSDN doco was changed as far as I know.
Rgs, James.
James, thanks for reply. May be this thread will answer some other questions.
Regards.
Kecol.-
PS: Congratulations for FASt Server, it is a good project. I know last release has examples for plugin support, but I have not checked yet.
Regards.
Kecol.-
PS: Congratulations for FASt Server, it is a good project. I know last release has examples for plugin support, but I have not checked yet.
In recent books im reading it says that the WSA functions are for 16bit windows and the
others are fully 32 bit. This was necessary to maintain compatibility with Winsock and older
versions of windows.
Im still looking into this as the wsa version provide a nice buffer handling.
others are fully 32 bit. This was necessary to maintain compatibility with Winsock and older
versions of windows.
Im still looking into this as the wsa version provide a nice buffer handling.
In recent books im reading it says that the WSA functions are for 16bit windows and the others are fully 32 bit.
That sounds pretty weird... especially since PlatformSDK doesn't mention this, but has the following as the first remark: The WSASend function provides functionality over and above the standard send function in two important areas:
Ok, maybe I am not reading it right, so Ill quote from
"Win32 Network Programming by Ralph Davis - Chapter 9 - Page 253 - Addison Wesley - ISBN: 0201489309"
In Sockets 2.0, the socket() function no longer creates overlapped sockets. You get an overlapped socket by calling WSASocket()
and setting WSA_FLAG_OVERLAPPED bit. Then there is a whole suite of functions that abstract the underlying Win32 calls. In
either NT or Windows 95, you can jsut call the Win32 functions directly; its not necessary to use the Socket 2 calls. They are
provided so can can use Sockets 2 in the Win16 environment. Table 9-2 shows the correspondence between Win32 and Sockets 2
functions.
Windows Socket 2.0? ? Win32
WSARecv()? ? ? ? ? ? ? ? ?ReadFile()/ReadFileEx()
<!-- est of table omitted -->
If you havent read this book I strongly suggest you do. Its full of gems.
rgs James.
"Win32 Network Programming by Ralph Davis - Chapter 9 - Page 253 - Addison Wesley - ISBN: 0201489309"
In Sockets 2.0, the socket() function no longer creates overlapped sockets. You get an overlapped socket by calling WSASocket()
and setting WSA_FLAG_OVERLAPPED bit. Then there is a whole suite of functions that abstract the underlying Win32 calls. In
either NT or Windows 95, you can jsut call the Win32 functions directly; its not necessary to use the Socket 2 calls. They are
provided so can can use Sockets 2 in the Win16 environment. Table 9-2 shows the correspondence between Win32 and Sockets 2
functions.
Windows Socket 2.0? ? Win32
WSARecv()? ? ? ? ? ? ? ? ?ReadFile()/ReadFileEx()
<!-- est of table omitted -->
If you havent read this book I strongly suggest you do. Its full of gems.
rgs James.
Well, it's probably correct that you cannot use the ReadFile* functions on sockets in win16, and you certainly *can* do it on win32, so the book is correct there; the WSA* functions aren't just for win16 compatibility though, they offer extended functionality.
Books from Addison Wesley are usually pretty good, so it confuses me that the author isn't more precise :)
Books from Addison Wesley are usually pretty good, so it confuses me that the author isn't more precise :)
I found some interesting information (my second time): http://support.microsoft.com/kb/q192800/. They are five IOCP tips, but check the first one.
TIP 1: Use Winsock2 IOCP-capable functions, such as WSASend and WSARecv, over Win32 file I/O functions, such as WriteFile and ReadFile.
Socket handles from Microsoft-based protocol providers are IFS handles so you can use Win32 file I/O calls with the handle. However, the interactions between the provider and file system involve many kernel/user mode transition, thread context switches, and parameter marshals that result in a significant performance penalty. You should use only Winsock2 IOCP- capable functions with IOCP.
The additional parameter marshals and mode transitions in ReadFile and WriteFile only occur if the provider does not have XP1_IFS_HANDLES bit set in dwServiceFlags1 of its WSAPROTOCOL_INFO structure.
NOTE: These providers have an unavoidable additional mode transition, even in the case of WSASend and WSARecv, although ReadFile and WriteFile will have more of them.
Socket handles from Microsoft-based protocol providers are IFS handles so you can use Win32 file I/O calls with the handle. However, the interactions between the provider and file system involve many kernel/user mode transition, thread context switches, and parameter marshals that result in a significant performance penalty. You should use only Winsock2 IOCP- capable functions with IOCP.
The additional parameter marshals and mode transitions in ReadFile and WriteFile only occur if the provider does not have XP1_IFS_HANDLES bit set in dwServiceFlags1 of its WSAPROTOCOL_INFO structure.
NOTE: These providers have an unavoidable additional mode transition, even in the case of WSASend and WSARecv, although ReadFile and WriteFile will have more of them.
Thanks, Kecol... can you give URL to this article, for future use?
f0dder, the URL is hidden in my last post. :)
It is a short article, but really interesting.
It is a short article, but really interesting.
Thanks guys,
Im sure to use the WSA functions in any case because of the extended functionality.
Just thought Id post what I have read.
Rgs James.
Im sure to use the WSA functions in any case because of the extended functionality.
Just thought Id post what I have read.
Rgs James.
James, you can always encapsulate the socket functions and abstract them away, so the chosen method doesn't limit you; I guess this is somewhat what you're doing with fAST :)