I/O Completion Ports vs. Asynchronous I/O

[Josh]

A while back I started a project to write a mail server. I was doing this
in c++ and found that I/O completion ports were the best solution for the
project. I've since decided to port my application to the .NET framework
and noticed that the concept of an I/O completion port doesn't exist
natively in the framework. It does have similar counterparts with
BeginRead, BeginSend, etc.

I see I have two options, I can write some unsafe code to import the IOCP
API calls into my application and continue to use them. This solution would
give me the presumed performance benefits of IOCP, while letting me code the
rest of the application in .NET. Alternately I could use .NET's
BeginRead/BeginSend/etc. which would let me have a completely managed
solution, while losing some of the performance benefits. I really don't
have any benchmarking data comparing the efficiency/scalability of the two
methods and wanted to know if anybody has such data. Alternately if you can
simply tell me which path would be better for writing something like a full
featured mail server, and your reasons behind that decision, that would be
great as well. Thanks!

Josh Carlson

[Ivar]

Hi,

I have done mailserver without asyncronous communication.
(Each session has it's own thread, which is created by control/listner
thread)
Speed is ok. I tried async and didn't get any prefrormace gain instead code
will be more messy.

See it yourself: www.lumisoft.ee .
(You may get some idea from there or you may suggest me improvements)

"Josh" <jo**@chegg.com> wrote in message
news:be********@library1.airnews.net...

A while back I started a project to write a mail server. I was doing this
in c++ and found that I/O completion ports were the best solution for the
project. I've since decided to port my application to the .NET framework
and noticed that the concept of an I/O completion port doesn't exist
natively in the framework. It does have similar counterparts with
BeginRead, BeginSend, etc.

I see I have two options, I can write some unsafe code to import the IOCP
API calls into my application and continue to use them. This solution would give me the presumed performance benefits of IOCP, while letting me code the rest of the application in .NET. Alternately I could use .NET's
BeginRead/BeginSend/etc. which would let me have a completely managed
solution, while losing some of the performance benefits. I really don't
have any benchmarking data comparing the efficiency/scalability of the two
methods and wanted to know if anybody has such data. Alternately if you can simply tell me which path would be better for writing something like a full featured mail server, and your reasons behind that decision, that would be
great as well. Thanks!

Josh Carlson

[Tom Shelton]

"Josh" <jo**@chegg.com> wrote in message
news:be********@library1.airnews.net...

A while back I started a project to write a mail server. I was doing this
in c++ and found that I/O completion ports were the best solution for the
project. I've since decided to port my application to the .NET framework
and noticed that the concept of an I/O completion port doesn't exist
natively in the framework. It does have similar counterparts with
BeginRead, BeginSend, etc.

I see I have two options, I can write some unsafe code to import the IOCP
API calls into my application and continue to use them. This solution would give me the presumed performance benefits of IOCP, while letting me code the rest of the application in .NET. Alternately I could use .NET's
BeginRead/BeginSend/etc. which would let me have a completely managed
solution, while losing some of the performance benefits. I really don't
have any benchmarking data comparing the efficiency/scalability of the two
methods and wanted to know if anybody has such data. Alternately if you can simply tell me which path would be better for writing something like a full featured mail server, and your reasons behind that decision, that would be
great as well. Thanks!

Josh Carlson

Josh,

On nt based systems, the Async IO functions use completion ports under the
hood. You don't have to do anything except use the BeginXXX methods.

Tom Shelton

[George Gre]

Hi,

I have also implement a IOCP solution using WinAPI/C++ and a .NET C# using
BeginXXX.. calls.

I have done some performance testing between the two by running 50+ clients
sending the server 50K data and the server echoing
back the data to the client. Responses were in the order of <10ms in both
solutions and the CPU almost in idle state. The big difference was that the
..NET solution was using more threads and far more memory.

Hope this helps,
George.

"Tom Shelton" <ts****@yahoo.com> wrote in message
news:uL**************@TK2MSFTNGP10.phx.gbl...

"Josh" <jo**@chegg.com> wrote in message
news:be********@library1.airnews.net...

A while back I started a project to write a mail server. I was doing this in c++ and found that I/O completion ports were the best solution for the project. I've since decided to port my application to the .NET framework and noticed that the concept of an I/O completion port doesn't exist
natively in the framework. It does have similar counterparts with
BeginRead, BeginSend, etc.

I see I have two options, I can write some unsafe code to import the IOCP API calls into my application and continue to use them. This solution

would

give me the presumed performance benefits of IOCP, while letting me code

the

rest of the application in .NET. Alternately I could use .NET's
BeginRead/BeginSend/etc. which would let me have a completely managed
solution, while losing some of the performance benefits. I really don't
have any benchmarking data comparing the efficiency/scalability of the two methods and wanted to know if anybody has such data. Alternately if you

can

simply tell me which path would be better for writing something like a

full

featured mail server, and your reasons behind that decision, that would be great as well. Thanks!

Josh Carlson

Josh,

On nt based systems, the Async IO functions use completion ports under the
hood. You don't have to do anything except use the BeginXXX methods.

Tom Shelton