Indigo/'.NET Framework' vs winsock and more...

[Guest]

Hi

I am writing some kind of a storage system that have to deal with large amounts of data passing over the net, Now, I Wonder... traditional programming would use win32 Winsock DLL as the means of data transportation... now, indigo is the new communication layer of the CLR,
- Does indigo uses Winsock internally?
- Is it possible to use indigo for such a task?
- I assume using indigo has it's performance penalty ( doesn't it ?
- Does Microsoft intend to keep supporting Winsock?
- Will indigo/’.NET Framework’ be a total replacement for Winsock
- Would modules that require high data transfer performance such as the media player internally use CLR technology for the actual data transfer or would it rather use Winsock
- Creating .NET defined an additional layer of programming above(?) win32, Winsock, ... does the win32/winsoc/... programming model would still be required/supported in future versions of windows ( e.g. longhorn ), would there be any need of using native C++ programming at application level?
- My guess is that in a few years all the application programming will be done using CLR*.* and all that is not CLR ( e.g. native C++ ) would only be done in the Kernel, does my assumption is true? Is this the direction that Microsoft is heading to

Nadav.

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Indigo will be available with Longhorn, in 2006 or later , so right now
it's not an option.

- Does indigo uses Winsock internally?

TCP/IP is the network protocol used in the internet, so yes, at the end of
the layers you will have a TCP/IP implementation.

- Is it possible to use indigo for such a task?

As I said Indigo is not released yet ...

- I assume using indigo has it's performance penalty ( doesn't it ? )

- Does Microsoft intend to keep supporting Winsock?

As long as MS machines are connected to the internet, it will.

- Will indigo/'.NET Framework' be a total replacement for Winsock?

As I said, TCP/IP will always be present


Cheers,

 

[Nicholas Paldino [.NET/C# MVP]]

Ignacio and Nadav,

I feel I have to comment on one of the remarks:

TCP/IP is the network protocol used in the internet, so yes, at the end of
the layers you will have a TCP/IP implementation.

This isn't completely correct. While ultimately, most transports will
require network connectivity which will ultimately rely on the Socket class
in the System.Net.Socket namespace, from what I can tell, Indigo can be
transport agnostic. Something besides sockets will be used when calls are
made in Indigo on the same machine, and there is nothing that says you can't
swap out the transport protocol for something else. You could concieve of a
machine writing a file to a network share to be picked up later, if you
wish.

As for the OPs questions:

I am writing some kind of a storage system that have to deal with large

amounts of data passing over the net, Now, I Wonder... traditional
programming would use win32 Winsock DLL as the means of data
transportation... now, indigo is the new communication layer of the CLR,

TCP/IP is just a transport layer, it is not a protocol/communications
layer. Chances are that (if not most definitely) if the protocol works over
the network, then the Winsock libraries will be used to transport the bytes
that make up that message.

- Does indigo uses Winsock internally?

I would wager yes for protocols that require network connectivity.

- Is it possible to use indigo for such a task?

Indigo will be suited for this, I believe. It has a number of different
scenarios that it supports.

- I assume using indigo has it's performance penalty ( doesn't it ? )

It depends on what you want to do, and what serivces you require it to
give you. If you need persistant message storing, as well as distributed
transaction support, then this would have a hit on performance. However, if
you needed to code these things from scratch, you would be stuck doing
development for quite a long time.

- Does Microsoft intend to keep supporting Winsock?

Absolutely. It's not going anywhere.

- Will indigo/’.NET Framework’ be a total replacement for Winsock?

No, once again, Indigo is about the communication, not the transport.
While it does rely on Winsock for some protocols, it is meant to be protocol
agnostic, so you can use any transport that you wish. Winsock deals
strictly with the transporting, not the protocol itself.

- Would modules that require high data transfer performance such as the

media player internally use CLR technology for the actual data transfer or
would it rather use Winsock?

At this point, it is unclear. I seriously doubt that media player would
use this. However, media player already has an existing codebase which will
process that kind of data very easily, so I doubt it will be changed for a
completely new protocol.

However, if you are looking to move large pieces of data, it depends on
what you are trying to move. If you are moving raw bytes, then this might
not be the best way. The attachement story for Indigo (and web services in
general) is not clearly defined yet. There was DIME, but now there is MTOM,
and that part of the WS namespace needs to be clearly defined before Indigo
can implement it.

- Creating .NET defined an additional layer of programming above(?) win32,

Winsock, ... does the win32/winsoc/... programming model would still be
required/supported in future versions of windows ( e.g. longhorn ), would
there be any need of using native C++ programming at application level?

There are a ton of programs and APIs that depend on Winsock. I wouldn't
bet on it going anywhere. The .NET libraries (specifically
System.Net.Sockets) are one of those programs/applications which rely on it.

- My guess is that in a few years all the application programming will be

done using CLR*.* and all that is not CLR ( e.g. native C++ ) would only be
done in the Kernel, does my assumption is true? Is this the direction that
Microsoft is heading to?

While MS is pushing managed code development, unmanaged code will not be
restricted, nor will existing code bases be thrown out the window simply
because they are unmanaged. Expect unmanaged code to be around for a very
long time. However, new functionality that is presented might be presented
through a managed interface only, so if you are writing unmanaged code, you
have to prepare for that eventuality.

Hope this helps.

 

[Guest]

Hi Ignacio

Thanks for your immediate responce, Concerning TCP/IP support, winsock is one way of using TCP/IP, kernel developers use TDI to achieve TCP/IP functionality, taking that in mind, does the .NET Framework ( including indigo ) use the standart Native winsock DLL OR it has a propriotary implementation ( that use TDI internally ): directly uses DeviceIoControl to comunicate with the kernel to achive TCP/IP functionality? ( this way winsock DLL is not mandatory....

Nadav.

 

[Guest]

Hi Nicholas

Thanks for your detailed responce, Taking in mind what you have just said, I would like verify the performance issue of using .NET Framework/Indigo, I am about to write an application that deals with massive amount of data being transffered over the net ( large raw data files ) so performabce is really importent, I Wonder... what would be the best way of implementing this kind of system: using unmanaged code ( Native C++ and winsock ) or using the managed CLR ( .NET Framework/Indigo/System.NET.Sockets )

Nadav.

 

[William Stacey [MVP]]

TCP Socket would probably be the best for the big file transfers. Could
still use remoting for setup and message passing, etc.

--
William Stacey, MVP

Hi Nicholas,

Thanks for your detailed responce, Taking in mind what you have just said,

I would like verify the performance issue of using .NET Framework/Indigo, I
am about to write an application that deals with massive amount of data
being transffered over the net ( large raw data files ) so performabce is
really importent, I Wonder... what would be the best way of implementing
this kind of system: using unmanaged code ( Native C++ and winsock ) or
using the managed CLR ( .NET Framework/Indigo/System.NET.Sockets )?

 

[Guest]

1. By using the term 'TCP Socket' do you refer to the standart win32 winsock DLL or to the System.NET.Sockets.Socket class
2. Are there any performance critical systems ( such as mass storage systems: EMC, TSM, ... Games: Unreal, ... ) written using the .NET framework and the CLR
3. Does the code being compiled by the JIT is optimal
4. Isn't there any perfomance penelty using the GC

P.S. I have created several business application using the .NET Framework/CLR, maybe I am ‘old fashioned’ BUT When dealing with performance critical systems I tend to better rely on the good old unmanaged C++ and win32 winsock DLL… ( any response would be appreciated )

Nadav.

 

[William Stacey [MVP]]

1. By using the term 'TCP Socket' do you refer to the standart win32
winsock DLL or to the System.NET.Sockets.Socket class?

You could use either in .net, but I would use .Net.Sockets classes. They
call the win32 dlls same as if you wrapped them yourself.

2. Are there any performance critical systems ( such as mass storage

systems: EMC, TSM, ... Games: Unreal, ... ) written using the .NET framework
and the CLR?

Perf is not an issue for socket classes from what I see. I did a netdig
client and found not perf issues. There is a game ported to .net. Not sure
about network gaming, but that should not be a speed issue imo.

3. Does the code being compiled by the JIT is optimal?

Calls the win32 socket stuff. You do have a thin wrapper which could be
measured, but have not done side by side.

4. Isn't there any perfomance penelty using the GC?

Depends. Some speed improve, some speed hit. Mostly productivity gain imo.
If you need that absolute speed, then assembly or c++ I would think.

P.S. I have created several business application using the .NET

Framework/CLR, maybe I am ‘old fashioned’ BUT When dealing with performance
critical systems I tend to better rely on the good old unmanaged C++ and
win32 winsock DLL… ( any response would be appreciated ).

If you need that last 20% speed, then yes.