.NET Remoting Channels (Custom)
-
There are two types of channels that .NET framework provide 1)TCP and 2)HTTP and there are custom channels that u can create using any stream oriented transfer technology like Sockets, Named Pipes and MSMQ. My question is which channel is suitable in which situation. Can anybody tell me when should i use named pipes channel and when MSMQ. Need urgent response .... @!$h@
-
There are two types of channels that .NET framework provide 1)TCP and 2)HTTP and there are custom channels that u can create using any stream oriented transfer technology like Sockets, Named Pipes and MSMQ. My question is which channel is suitable in which situation. Can anybody tell me when should i use named pipes channel and when MSMQ. Need urgent response .... @!$h@
If you use the TCP channel, then you have your own server code which is handling the reciept of the requests and issuing the responses. The HTTP channel places your remoting objects in IIS and it handles all of the server functions with only your remoting objects needed. This lets you focus only on the functions the remote objects perform and not the server functions you need to expose. Channels are the first part of it. Then there are formatters. There are binary formatters and SOAP formatters. Generally, SOAP is horrendously slow. So you should stick to binary even over HTTP. (IIS establishes the binary formatter by default at the server side.) ______________________________ The Tao gave birth to machine language. Machine language gave birth to the assembler. The assembler gave birth to the compiler. Now there are ten thousand languages. Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao. But do not program in COBOL if you can avoid it.
-
If you use the TCP channel, then you have your own server code which is handling the reciept of the requests and issuing the responses. The HTTP channel places your remoting objects in IIS and it handles all of the server functions with only your remoting objects needed. This lets you focus only on the functions the remote objects perform and not the server functions you need to expose. Channels are the first part of it. Then there are formatters. There are binary formatters and SOAP formatters. Generally, SOAP is horrendously slow. So you should stick to binary even over HTTP. (IIS establishes the binary formatter by default at the server side.) ______________________________ The Tao gave birth to machine language. Machine language gave birth to the assembler. The assembler gave birth to the compiler. Now there are ten thousand languages. Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao. But do not program in COBOL if you can avoid it.
what about other (custom) channels like MSMQ, Pipes, Sockets? @!$h@
-
what about other (custom) channels like MSMQ, Pipes, Sockets? @!$h@
Dear @!$h@, With any custom channel it is not as simple as just defining a channel...and anyone who even thinks of deploying remoting over Named Pipes should be taken outside and shot. Named Pipes is really an ancient technology that deserves a quiet death. You may need to provide your own sink providers, incorporate sink formatters and sink serializers/deserializers. Most writings on remoting only discuss TCP or HTTP with no other form considered. ______________________________ The Tao gave birth to machine language. Machine language gave birth to the assembler. The assembler gave birth to the compiler. Now there are ten thousand languages. Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao. But do not program in COBOL if you can avoid it.
-
what about other (custom) channels like MSMQ, Pipes, Sockets? @!$h@
IIRC, someone did define a custom channel using MSMQ here on CodeProject. You could try a search to learn more (perhaps "MSMQ channel" for keywords). I believe it was by Roman Kiss.
Microsoft MVP, Visual C# My Articles
-
If you use the TCP channel, then you have your own server code which is handling the reciept of the requests and issuing the responses. The HTTP channel places your remoting objects in IIS and it handles all of the server functions with only your remoting objects needed. This lets you focus only on the functions the remote objects perform and not the server functions you need to expose. Channels are the first part of it. Then there are formatters. There are binary formatters and SOAP formatters. Generally, SOAP is horrendously slow. So you should stick to binary even over HTTP. (IIS establishes the binary formatter by default at the server side.) ______________________________ The Tao gave birth to machine language. Machine language gave birth to the assembler. The assembler gave birth to the compiler. Now there are ten thousand languages. Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao. But do not program in COBOL if you can avoid it.
Actually, I thought using the HttpChannel defaults to SOAP? In any case, though, the BinaryFormatter is much faster (even just for serialization, not to mention over the transport channel). The one thing that does stink is that even using the BinaryFormatter, DataSets (which are application uses a lot) are still serialized to XML. This will be changed in .NET 2.0 if you set a property on the DataSet before serializing it. This was recently shown on MSDN TV and there is, obviously, a significant reduction in size (about 400%)!
Microsoft MVP, Visual C# My Articles
-
IIRC, someone did define a custom channel using MSMQ here on CodeProject. You could try a search to learn more (perhaps "MSMQ channel" for keywords). I believe it was by Roman Kiss.
Microsoft MVP, Visual C# My Articles
yes i referred to that but Roman Kiss only mentioned how to make MSMQ based Channel and not the advantages/disadvantages of using MSMQ channel over the other channels. @!$h@
-
Actually, I thought using the HttpChannel defaults to SOAP? In any case, though, the BinaryFormatter is much faster (even just for serialization, not to mention over the transport channel). The one thing that does stink is that even using the BinaryFormatter, DataSets (which are application uses a lot) are still serialized to XML. This will be changed in .NET 2.0 if you set a property on the DataSet before serializing it. This was recently shown on MSDN TV and there is, obviously, a significant reduction in size (about 400%)!
Microsoft MVP, Visual C# My Articles
Heath Stewart wrote: The one thing that does stink is that even using the BinaryFormatter, DataSets (which are application uses a lot) are still serialized to XML. This will be changed in .NET 2.0 if you set a property on the DataSet before serializing it. This was recently shown on MSDN TV and there is, obviously, a significant reduction in size (about 400%)! nice piece of information. But this is about formatters and not channels. what i have conceived as yet is that there are only two available formatters SOAP and Binary and about Channels TCP and HTTP. You can write ur custom channels but the formatter you will associate with ur channel could be either SOAP or Binary. My question is about channels and not formatters. @!$h@
-
yes i referred to that but Roman Kiss only mentioned how to make MSMQ based Channel and not the advantages/disadvantages of using MSMQ channel over the other channels. @!$h@
The advantages and disadvantages are whatever advantages and disadvantages of using MSMQ for anything, really. I don't have a lot of experience with MSMQ (just never had a good enough reason or opportunity as of yet). One advantage I can think of is a distributed system were you could have multiple remoting objects handling requests. I don't know if this would really be necessary, but it may be one way to do load balancing with massive clients connected if you devised a way that whichever remoting object answered first would cause the others not to handle the request. This can be achieved - and probably better - by implementing your own
RealProxyderivative, for which the book, "Microsoft .NET Remoting" from MS Press[^], has an example.Microsoft MVP, Visual C# My Articles
-
Heath Stewart wrote: The one thing that does stink is that even using the BinaryFormatter, DataSets (which are application uses a lot) are still serialized to XML. This will be changed in .NET 2.0 if you set a property on the DataSet before serializing it. This was recently shown on MSDN TV and there is, obviously, a significant reduction in size (about 400%)! nice piece of information. But this is about formatters and not channels. what i have conceived as yet is that there are only two available formatters SOAP and Binary and about Channels TCP and HTTP. You can write ur custom channels but the formatter you will associate with ur channel could be either SOAP or Binary. My question is about channels and not formatters. @!$h@
Yes, I know. I was posting this in reference to what theRealCondor said - call it an aside. It was not intended to be a direct response to your question.
Microsoft MVP, Visual C# My Articles