ASP.NET 4.0 Hosting & ASP.NET 4.5 Hosting BLOG

BLOG about ASP.NET 4.5 Hosting, ASP.NET 4.0 Hosting and .NET 4.5 Framework and its Capabilities

WebSocket Hosting in Windows Server 2012 with

clock November 28, 2012 07:15 by author Administrator

As both the WebSocket Protocol and the WebSocket API gain full-fledged support in the Windows 8 Consumer preview, ASP.NET developers can start taking advantage of the bidirectional capabilities by using System.Web.WebSockets library., as the premier provider of ASP.NET and Windows Hosting service, proudly announces that we have supported the latest Windows Server 2012. This Windows Server version does support WebSocket technology and ASP.NET developers can maximize this opportunity directly.

In the Windows 8 consumer preview and Server beta, IE10 and all other Microsoft WebSocket client and server features now support the final version of the IETF WebSocket Protocol. In addition, IE10 implements the W3C WebSocket API Candidate Recommendation. An article on the IE team blog explains this in much more detail.

Meanwhile, ASP.NET Developers can start using the System.Web.WebSockets library introduced in .NET Framework 4.5 to leverage this technology. Note that this is different from the System.Net.WebSockets namespace which contains the actual implementation of the WebSocket standard in .NET – System.Web.WebSockets provides the integration of this implementation with ASP.NET.

WebSocket is a technology for providing bi-directional communication channels over a single TCP socket. This is a much simpler alternative to using Comet Channels to allow the web server to push data to a web client, without the client explicitly requesting it. Although the technology itself has been available since much earlier (Google Chrome first announced support for it in late 2009), it finally became a Proposed Standard last December essentially receiving a nod from the Internet Engineering Task Force.

Node.js hosting on Windows Server 2012 with

clock November 26, 2012 08:17 by author Administrator

Node.js is a server side software system designed for writing scalable Internet applications, notably web servers. Programs are written on the server side in JavaScript, using event-driven, asynchronous I/O to minimize overhead and maximize scalability. opens an opportunity to everyone to host their website with Node.js on our Windows 2012 web server. You can always start from our cheapest Standard Plan @$4.49/month to have your site hosted on our environment.

Node.js Background and Details

Node.js consists of Google's V8 JavaScript engine, libUV, and several built-in libraries.

Node.js was created by Ryan Dahl starting in 2009, and its growth is sponsored by Joyent, his employer.

Dahl's original goal was to create the ability to make web sites with push capabilities as seen in web applications like Gmail. After trying solutions in several other programming languages he chose JavaScript because of the lack of an existing I/O API. This allowed him to define a convention of non-blocking, event-driven I/O.

Similar environments written in other programming languages include Twisted for Python, Perl Object Environment for Perl, libevent for C, Vert.x for Java and EventMachine for Ruby. Unlike most JavaScript programs, it is not executed in a web browser, but is instead a server-side JavaScript application. Node.js implements some CommonJS specifications. It provides a REPL environment for interactive testing.


If you need further references about Node.js, please refer to:


Working with WebSockets in WCF 4.5

clock November 24, 2012 07:06 by author Administrator

Web Services have one great virtue: they're completely interoperable. They also have one great failing: in order to be interoperable, Web Services use a set of technologies that are guaranteed to give you, at best, adequate performance. Fortunately, WCF 4.5 has a solution: support for WebSockets.

Ever since Web Services appeared, developers have been trying to make them run faster. REST and JSON can be seen as a way of speeding things up by reducing the overhead in the messaging format used by Web Services. However, even with REST and JSON you're still moving and parsing text, which is the bulkiest and slowest data transfer mechanism; you'd get better performance if you could move binary data around. And REST and JSON don't tackle another reason for why Web Services give poor performance: HTTP, the network protocol used by Web Services. There are slower protocols than HTTP around, but no one is using them.

But performance isn't the only issue that using HTTP creates: HTTP in Web Services is tied to a request/response cycle. The reason Ajax applications make all their requests asynchronously is because if you call a service that takes a long time to complete, your request has to wait for that response before you can get your result.

On top of that, if your service has something else to tell your client after that initial response (an ongoing set of updates, for instance), then either your client has to make repeated polling calls to the service to get the result (another performance burden) or, in a non-Ajax application, you have to set up a complementary Web Service that the service can call with the updates.

A far better arrangement would be for the client to submit its request in a "fire and forget" kind of arrangement and then for the service to call back to the client when it has the data (and keep calling back if there are updates to send).

WebSockets addresses all of those issues, while still being an industry standard and therefore interoperable (confusions in vendor's implementations of the standard may interfere). In fact, your browser probably already supports WebSockets.

For most processing, WebSockets uses TCP to communicate, giving you the benefit of a faster protocol. WebSockets also supports sending both binary (for speed) and text (for interoperability). But in many ways, the best part of WebSockets is that it supports two-way communication: The client can call the service just to open communication; and after that, the service can call the client whenever it has information to share. And WCF 4.5 provides support for WebSockets.

So in the next few columns, I'm going to look at WebSockets in WCF 4.5. I'll look at the two ways you can implement WebSockets (one complicated and flexible, one simpler and less flexible) and create client a JavaScript client. Along the way I'll also discuss some of the issues you should consider in creating a WebSocket application.

Configuring the Server

One warning: You may not be able to use the code in this series, yet. As I write this (April 2012), WebSockets is only supported on Windows 8 (I worked on the 64-bit beta ISO for Windows 8 Server); even then, you'll need to configure Windows 8 to support WebSockets.

To configure Windows 8, in Server Manager, from the Manage menu, run the Add Server Roles and Features wizard. In the Wizard, you'll need to add the Web Server (IIS) role. After that, under Features, select ASP.NET 4.5 (if it isn't already selected) and, under Web Services, select HTTP Activation. Finally, under Web Services (IIS)/Role Services, select WebSockets. After  finishinb the Wizard, select Local Server and set IIS Enhanced Security Configuration to off.

To work with WCF 4.5, you'll need Visual Studio 11 (again, in beta, as I write this). The first time you run it, Visual Studio 11 will probably offer to download an update; if so, take the update (I took the update and I won't guarantee that the following code will work without it).

Second warning: This may be a frustrating set of columns if you're reading them as soon as I post them. I've got a fair amount of ground to cover so, in this column, I'll only be setting up to write the code that a WebSocket service requires. But hang tough; the next column will have the code and subsequent columns will show you how to build the clients and provide an alternative way to build a WebSocket service.

Building the Service

I did my testing with a WCF Service Application Project. To take advantage of IIS's support for WebSockets that I'd just finished configuring, I went to the Web tab of my Project Properties and unchecked the Use IIS Express option so that I was testing with the "real" IIS.

Once you've set up your server and project, the first step in creating your WebSocket service is to define two interfaces: one with a single method that accepts requests from clients and another interface with a single method to send results.

For the first interface, I'll define a method that accepts an Order Id (I call the method OrderStatusById method and the interface IRequestOrderStatusUpdates). In the ServiceContract attribute on the interface that accepts requests, you need to use the attribute's CallbackContract to specify the second interface (the one with the method used to send data back to the client is ISendOrderStatus in this example). The method must accept a Message as its only input parameter and the method's OperationContract attribute must set its IsOneWay property to True and its Action property to an asterisk.

The result for my Order status example looks like this:

Public Interface IRequestOrderStatusUpdate

  <OperationContract(IsOneWay:=True, Action:="*")>
  Sub OrderStatusByID(OrderStatusMessage  As Channels.Message)

End Interface

The definition for the return method is similar, except that you don't need any special specifications for the ServiceContract attribute. I've called my method SendOrderStatus:

Public Interface ISendOrderStatus

  <OperationContract(IsOneWay:=True, Action:="*")>
  Sub SendOrderStatus(OrderStatusMessage  As Channels.Message)

End Interface

At this point you're ready to write the code for these methods, which I'll look at in my next column (the column after that will look at building a client).

ASP.NET 4.0 & ASP.NET 4.5 Hosting


ASPHostCentral is a premier web hosting company where you will find low cost and reliable web hosting. We have supported the latest ASP.NET 4.5 hosting and ASP.NET MVC 4 hosting. We have supported the latest SQL Server 2012 Hosting and Windows Server 2012 Hosting too!



<<  May 2017  >>

View posts in large calendar

Sign in