Need advice for Middleware

[Calimero]

I have to write a middleware that could be see as a very
specialized Web server (based on threads and sockets)
I hesitate between C++ (speed) and C# (more elegant)
What is the performance penalty if I use C# instead of
native (not managed) C++ ? This software could have to
manage 100's of simultanous connections. Realist in C# ?

Thanks for your advice.

 

[Rob Tillie]

Hmm, maybe it's a good idea to write a demonstrator in both, so you can see
the difference in performance.
The performance will increase with every new version of the .NET
framework...

An important aspect also is security. I assume your webserver needs good
security... this is far more easy to achieve in .NET as in C++.

Greetz,
-- Rob.

 

[Jay Balapa]

Always use c#, donot use unmanaged applications. Unmanaged applications are
cool in a geeky way, but you will run into lot of code reuse issues.

Also try writing your Middleware on IIS as web services. Donot try to
recreate the wheel.
IIS uses threads/sockets internally and is highly optimized.


I have created pure win32 webserver/database server/middle ware from
scratch. Looking back it was wase of time.


Microsoft is actively implementing c# in all its software.
A well designed c# application will be as fast as a c++ application.

jay

 

[Chad Myers]

I have to write a middleware that could be see as a very
specialized Web server (based on threads and sockets)
I hesitate between C++ (speed) and C# (more elegant)
What is the performance penalty if I use C# instead of
native (not managed) C++ ? This software could have to
manage 100's of simultanous connections. Realist in C# ?

I would say that there are many more advantages to
using C# over C++ the least of which is secure code
(no buffer overflows, etc). What little performance
difference there is can be made up for with hardware.
Hardware is cheap now. Up the processor from 2.0 to
2.5 Ghz and there you go.

The question really is, why do you feel the need
to implement some type of socket-based TCP
solution. That seems so 1990's. Web services are
the way to go. IIS is much better at handling
connections than anything you or I or most
people in this group could write, so why not
leverage what's already there and VERY well
tested?

-c

 

[Duncan McNutt [ FTSE ]]

if not faster

 

[Calimero]

Thanks for your comment.
There are several reason why I want to use sockets:
- I want to merge the web server and the app (cgi) into the same app.
- I think I'll get better performance if the web server and the app are
merged.
- It is not only request/answer scheme, but also real-time events (alarms,
security, rights check...)
- Non IT people may have be able to install the whole app, so install is
simpler if no web server to install.
- People who install it do not even have to known what an IP address is.
- Among our customers, many have no server, only peer to peer network.
- The clients are very light (it is the goal) written in C++ (from Win 95 to
XP), so no web service here.