This project is read-only.

.NET Remoting VS Socket Programming VS Web Services

Sep 23, 2009 at 9:28 AM

Before  implementing our distributed application we  need to consider one of the  following  technologies

  • Sockets
  • .NET Remoting
  • Web Services

Lets  make the comparisson of them

Sep 23, 2009 at 9:30 AM


.NET Remoting is built on Socket programming and XML Web services are built on top of Remoting.
All of them provide the Server-Client functionality. You use Socket programming when Client is waiting for notifications/events from server. Remoting  is a higher layer on Sockets. When both client and server is under your control you can use Remoting. Web Services are total freedom. Client and server can be implemented in different technologies.

Sep 23, 2009 at 9:35 AM


Sockets are raw binary streams between two endpoints. You would need to wrap your own RPC (etc) layer to process the messages, and deal with a lot of infrastructure code. However, since they are so close to the metal this can be very, very efficient. It is not tied to any specific architecture, as long as both ends talk the same message format. Tools like protobuf-net can help you construct binary messages for streams (rather than rolling your own serialization code).

Remoting is a .NET specific tool, and is very brittle re versioning. I wouldn't recommend remoting for client/server - use things like WCF instead.

WCF is a more flexible comms stack - a lot of power and complexity, but arguably a bit of bloat too (xml, complex security etc). It is data-contract based, so roughly open (client/server can be different), but still a bit .NET focused.


Choosing between sockets and remoting you better consider on what type of application you are developing. Sockets are definitely for your own protocol implementations, low level programming and the only way to go if you have to communicate to the other tcp/ip applications. Remoting is a preffered way to develop new .NET communication applications, where you don't need to come down to tcp/ip stack and ensure your application talks to the others (probably legacy applications). In case you could go only with .NET it's better to choose .NET 3.5 and WCF framework instead of .net 2.0 remoting, the last one is dead and unsupported technology.


Direct socket manipulation can give you more power, flexibility, performance, and unfortunately complexity when compared to Remoting or WCF. However, if you need the benefits of low-level TCP/IP, such as non-blocking IO and custom protocols, tools such as Ragel and frameworks like Mina can ease the complexity burden. I recommend trying the higher-level APIs like WCF first and only use direct sockets if these don't meet your needs.

Sep 23, 2009 at 11:35 AM
Edited Sep 23, 2009 at 11:36 AM
ASP.NET Web Services or .NET Remoting: How to Choose 

Microsoft Developer Network


Over time, it has become common practice to build applications as a set of components that are distributed across a network of machines and work together as part of one overall program. Traditionally, distributed application logic called for component-object technology such as the Microsoft® Distributed Component Object Model (DCOM), the Object Management Group's Common Object Request Broker Architecture (CORBA), or Sun's Remote Method Invocation (RMI). These technologies provided reliable, scalable architecture to meet the growing needs of applications.

Though these component-based technologies work very well in an intranet environment, attempting to use them over the Internet presents two significant problems. First, the technologies do not interoperate. While they all dealt with objects, they disagreed over the details, for example, lifecycle management, support for constructors, and degree of support for inheritance. Second, and more important, their focus on RPC-style communication typically led to tightly coupled systems built around the explicit invocations of object methods.

Browser-based Web applications, in contrast, are loosely coupled and remarkably interoperable. They communicate using HTTP to exchange MIME-typed data in a wide range of formats. Web services adapt the traditional Web programming model for use from all sorts of applications, not just browser-based ones. They exchange SOAP messages using HTTP and other Internet protocols. Because Web services rely on industry standards, including HTTP, XML, SOAP and WSDL, to expose application functionality on the Internet, they are independent of programming language, platform and device.

The ASP.NET Web services infrastructure provides a simple API for Web services based on mapping SOAP messages to method invocations. It accomplishes this by providing a very simple programming model based on mapping SOAP message exchanges to individual method invocations. The clients of ASP.NET Web services do not have to know anything about the platform, object model, or programming language used to build them. The services themselves don't have to know anything about the clients that are sending them messages. The only requirement is that both parties agree on the format of the SOAP messages being produced and consumed, as defined by the Web service's contract definition expressed using WSDL and XML Schema (XSD).

.NET Remoting provides an infrastructure for distributed objects. It exposes the full-object semantics of .NET to remote processes using plumbing that is both very flexible and extensible. Compared to ASP.NET Web services, which provide a very simple programming model based on message passing, .NET Remoting offers much more complex functionality, including support for passing objects by value or by reference, callbacks, and multiple-object activation and lifecycle management policies. In order to use .NET Remoting, a client needs to be aware of all these details—in short the client needs to be built using .NET. (Or with another framework that supports .NET Remoting; the only one we are aware of is Intrinsyc's Ja.NET for Java.) The .NET Remoting plumbing also supports SOAP messages, but it is important to note that this doesn't change its client requirements. If a Remoting endpoint exposes .NET-specific object semantics, via SOAP or not, the client must understand them.

The fact that the .NET Framework includes support for two distinct distributed programming models, Web services and distributed objects, has caused a fair amount of confusion for developers. When should a system use ASP.NET Web services and when should it use .NET Remoting? To answer this question, you have to understand how both these technologies really work.

Serialization and Metadata

All distributed communication plumbing ultimately does two things: it marshals instances of programmatic data types into messages that can be sent across the network, and it provides a description of what those messages look like. The former is accomplished using some form of serialization engine, or marshaler. The latter is achieved through some form of metadata. For instance, for most (latter day) DCOM interfaces, the serialization engine was the Type Library Marshaler and type libraries provided the metadata. The key difference between ASP.NET Web services and .NET Remoting is in how they serialize data into messages and the format they choose for metadata.

ASP.NET Web Services, XmlSerializer and XSD

ASP.NET Web services rely on the System.Xml.Serialization.XmlSerializer class to marshal data to and from SOAP messages at runtime. For metadata, they generate WSDL and XSD definitions that describe what their messages contain. The reliance on pure WSDL and XSD makes ASP.NET Web services metadata portable; it expresses data structures in a way that other Web service toolkits on different platforms and with different programming models can understand. In some cases, this imposes constraints on the types you can expose from a Web service—XmlSerializer will only marshal things that can be expressed in XSD. Specifically, XmlSerializer will not marshal object graphs and it has limited support for container types.

Though these limitations may seem significant from a classic distributed object perspective, they help ensure interoperability with other Web service frameworks—a basic goal of the loosely coupled Web service model. Support for interoperability is augmented by a rich set of custom attributes that allow you to annotate your data types to control the way in which the XmlSerializer marshals them. As a result, you have very fine-grained control over the shape of the XML being generated when an object is serialized. In addition, an ASP.NET-based Web service can be tailored to describe its messages in terms of literal XSD or the SOAP encoding rules (i.e., SOAP Section 5). Literal XSD is the default, and will be the standard going forward. SOAP-encoding support is included for interoperability with existing toolkits. This is beneficial, especially when you need to communicate with an existing Web service or client that needs to communicate using a predefined message format.

.NET Remoting, IFormatter and the Common Language Runtime

.NET Remoting relies on the pluggable implementations of the IFormatter interface used by the System.Runtime.Serialization engine to marshal data to and from messages. There are two standard formatters, System.Runtime.Serialization.Formatters.Binary.BinaryFormatter and System.Runtime.Serialization.Formatters.Soap.SoapFormatter. The BinaryFormatter and SoapFormatter, as the names suggest, marshal types in binary and SOAP format respectively. For metadata, .NET Remoting relies on the common language runtime assemblies, which contain all the relevant information about the data types they implement, and expose it via reflection. The reliance on the assemblies for metadata makes it easy to preserve the full runtime type-system fidelity. As a result, when the .NET Remoting plumbing marshals data, it includes all of a class's public and private members; handles object graphs correctly; and supports all container types (e.g., System.Collections.Hashtable). However, the reliance on runtime metadata also limits the reach of a .NET Remoting system—a client has to understand .NET constructs in order to communicate with a .NET Remoting endpoint. In addition to pluggable formatters, the .NET Remoting layer supports pluggable channels, which abstract away the details of how messages are sent. There are two standard channels, one for raw TCP and one for HTTP. Messages can be sent over either channel independent of format.


Distributed Application Design: ASP.NET Web Services vs. .NET Remoting

ASP.NET Web services favor the XML Schema type system, and provide a simple programming model with broad cross-platform reach. .NET Remoting favors the runtime type system, and provides a more complex programming model with much more limited reach. This essential difference is the primary factor in determining which technology to use. However, there are a wide range of other design factors, including transport protocols, host processes, security, performance, state management, and support for transactions to consider as well.

Transport Protocols and Host Processes

Although the SOAP specification does not mandate HTTP as the transport protocol, the client can access Web services implemented using ASP.NET Web services only over HTTP, because it is the only transport protocol ASP.NET supports. The services are invoked via IIS and execute in the ASP.NET worker process, aspnet_wp.exe.

.NET Remoting gives you the flexibility to host remote objects in any type of application including a Windows Form, a managed Windows Service, a console application or the ASP.NET worker process. As previously noted, .NET Remoting provides two transport channels—TCP and HTTP. Both channels provide communication between arbitrary sending and receiving processes using sockets.

It is also possible to integrate the HTTP channel with IIS and the ASP.NET worker process. This is important for several reasons. First, it is the only way to auto-start a .NET Remoting endpoint when a client request arrives. The .NET Remoting plumbing does not include a DCOM style Service Control Manager (SCM) to start remote servers. If you expose remote objects from arbitrary processes, you have to ensure those process are running. You also have to ensure they are thread-safe, e.g., that thread A can't activate an object after thread B started to shut the process down. If you expose remote objects from ASP.NET, you can take advantage of the fact that the Aspnet_wp.exe worker process is both auto-starting and thread-safe. Second, as described in the next section, integration with IIS is the only way you can secure a cross-process .NET Remoting call.

Both the ASP.NET Web services and the .NET Remoting infrastructures are extensible. You can filter inbound and outbound messages, control aspects of type marshaling and metadata generation. With .NET Remoting, you can also implement your own formatters and channels.


Since ASP.NET Web services rely on HTTP, they integrate with the standard Internet security infrastructure. ASP.NET leverages the security features available with IIS to provide strong support for standard HTTP authentication schemes including Basic, Digest, digital certificates, and even Microsoft® .NET Passport. (You can also use Windows Integrated authentication, but only for clients in a trusted domain.) One advantage of using the available HTTP authentication schemes is that no code change is required in a Web service; IIS performs authentication before the ASP.NET Web services are called. ASP.NET also provides support for .NET Passport-based authentication and other custom authentication schemes. ASP.NET supports access control based on target URLs, and by integrating with the .NET code access security (CAS) infrastructure. SSL can be used to ensure private communication over the wire.

Although these standard transport-level techniques to secure Web services are quite effective, they only go so far. In complex scenarios involving multiple Web services in different trust domains, you have to build custom ad hoc solutions. Microsoft and others are working on a set of security specifications that build on the extensibility of SOAP messages to offer message-level security capabilities. One of these is the XML Web Services Security Language (WS-Security), which defines a framework for message-level credential transfer, message integrity, and message confidentiality.

As noted in the previous section, the .NET Remoting plumbing does not secure cross-process invocations in the general case. A .NET Remoting endpoint hosted in IIS with ASP.NET can leverage all the same security features available to ASP.NET Web services, including support for secure communication over the wire using SSL. If you are using the TCP channel or the HTTP channel hosted in processes other than aspnet_wp.exe, you have to implement authentication, authorization and privacy mechanisms yourself.

One additional security concern is the ability to execute code from a semi-trusted environment without having to change the default security policy. ASP.NET Web Services client proxies work in these environments, but .NET Remoting proxies do not. In order to use a .NET Remoting proxy from a semi-trusted environment, you need a special serialization permission that is not given to code loaded from your intranet or the Internet by default. If you want to use a .NET Remoting client from within a semi-trusted environment, you have to alter the default security policy for code loaded from those zones. In situations where you are connecting to systems from clients running in a sandbox—like a downloaded Windows Forms application, for instance—ASP.NET Web Services are a simpler choice because security policy changes are not required.

State Management

The ASP.NET Web Services model assumes stateless service architecture by default; it does not inherently correlate multiple calls from the same user. In addition, each time a client invokes an ASP.NET Web service, a new object is created to service the request. The object is destroyed after the method call completes. To maintain state between requests, you can either use the same techniques used by ASP.NET pages, i.e., the Session and Application property bags, or you can implement your own custom solution.

.NET Remoting supports a range of state management options and may or may not correlate multiple calls from the same user, depending on what object lifetime scheme you choose. SingleCall objects are stateless (like the objects used to invoke ASP.NET Web services), Singleton objects share state for all clients, and client-activated objects maintain state on a per-client basis (with all the associated scalability and reliability issues this raises).


In terms of raw performance, the .NET Remoting plumbing provides the fastest communication when you use the TCP channel and the binary formatter. In almost all the tests that we carried out to compare the relative performance of ASP.NET Web services and .NET Remoting, ASP.NET Web services outperformed .NET Remoting endpoints that used the SOAP formatter with either the HTTP or the TCP channel. More interestingly, ASP.NET and .NET Remoting endpoints that used the binary formatter and the HTTP channel were very similar in performance. (See Performance Comparison: .NET Remoting vs. ASP.NET Web Services for more details.)


Choosing an Architecture

If you are designing a distributed application built on .NET, you have to consider all of the issues discussed in this paper and draw some conclusions about what your system's architecture should look like. In general, this turns out to be easier than you might think. While there is always a special case that requires an alternate approach, here are some general assumptions you can make that will simplify things for you.

First, use ASP.NET Web services by default. They are simpler to implement and use, they offer the broadest possible reach to client platforms, and ASP.NET Web services client proxy code can be invoked from code run in a sandbox under the default security policy.

If you need a more traditional distributed object model with full CLR type fidelity, you don't need interoperability with other platforms, and you control the configuration of both clients and servers, consider .NET Remoting. If you choose .NET Remoting, prefer the HTTP channel integrated with IIS and ASP.NET, otherwise you have to build your own process lifecycle management and security infrastructure. Given that .NET Remoting requires a .NET client, it makes sense to use the binary formatter instead of the SOAP formatter; interoperability is not an issue and performance will be noticeably better.