I’ve developed a very basic Web Socket server implementation in C# just as a proof of concept. It handles the most basic operations you would expect from a server: start a new connection, disconnect, and send and receive data. Besides, I’ve developed the client part as well using regular ASP.NET. Actually it’s just plain HTML and JavaScript being served from an ASP.NET server – this example doesn’t use any fancy runat=server controls or anything of the like. The functionality is achieved with very simple and easy to understand JavaScript.

So what does this example do? It provides two projects: a Web Socket server and a Web Socket client. The server is a windows console application that once executed just sits there waiting for a connection request. When a client connects, the server sends its date and time to the client every 10 seconds. The client is a web page with some controls to connect/disconnect and to send data to the server, as well as a log window to see what’s going on. Take a look at the example at the bottom of the page.

Here’s a description of the public members of the Web Socket Server:

// Possible status of the server
enum ServerStatusLevel { Off, WaitingConnection, ConnectionEstablished };
// Constructor of the server with default values
WebSocketServer();
// Constructor of the server with the specified values
WebSocketServer (int serverPort, string serverLocation, string connectionOrigin);
// Close the server and release all resources
void Dispose();
// Start the server and make it listen for connection requests
void StartServer();
// Send data to the connected client
void Send (string message);
// Whether events should be logged or not
bool LogEvents;
// Origin of the connection
string ConnectionOrigin;
// Location of the server
string ServerLocation;
// Port of the server
int ServerPort;
// Current status of the server
ServerStatusLevel Status;
// Fired when data is received from the client
event DataReceivedEventHandler DataReceived;
// Fired when client is disconnected
event DisconnectedEventHandler Disconnected;
// Fired when a new connection is established
event NewConnectionEventHandler NewConnection;

Note how I provide two constructors for the Web Socket Server class: one with default parameters (if you want to keep it as simple as possible), and another one to specify the values you want. Anyways, you can still change them after creating the new instance, as the properties are public. You can also specify whether you want the server to log out the events to the console with the LogEvents property.

In order to get the data being sent from the client, you must attach your own function to the DataReceived event, which will then receive the message as a parameter.

So here’s how you would use this Web Socket Server:

public void Test()
{
    WebSocketServer WSServer = new WebSocketServer();  // Default values
    WSServer.NewConnection += new NewConnectionEventHandler(WSServer_NewConnection);
    WSServer.Disconnected += new DisconnectedEventHandler(WSServer_Disconnected);
    WSServer.DataReceived += new DataReceivedEventHandler(WSServer_DataReceived);
    WSServer.StartServer();
}

void WSServer_DataReceived(string message, EventArgs e)
{
    Console.WriteLine("Data received from the client: " + message);
}

void WSServer_Disconnected(EventArgs e)
{
    Console.WriteLine("Server disconnected");
}

void WSServer_NewConnection(EventArgs e)
{
    Console.WriteLine("New connection established");
    WSServer.Send("Hello new client! I hope you enjoy your visit!");
}

It’s a very simple Web Socket server, so it’s very easy to use. You shouldn’t have much problem understanding it.

Go ahead and download the Visual Studio solution and give it a try!

UPDATE (October 12th, 2010):

The Web Socket protocol is not closed yet, so it is being constantly updated. This means that previous Web Socket server implementations might stop working after an update has been made to the API. The original version of the code I released here complied with version 75 of the Web Socket draft. The current version is 76, so I updated my code and released a second project.

No idea of what I’m talking about? I’ll make it easy for you… download the v76 implementation first, and if it doesn’t work then check out the v75 implementation. If you’re using one of the latest browsers, you should have no trouble.

WebSocketsTest (draft 75).zip (Older browsers)

WebSocketsTest (draft 76).zip (Latest browsers)

Related posts:

1. HTML 5 Web Sockets
2. AJAX call using an ASP.NET web page
3. AJAX call using an ASP.NET HTTP Handler
4. AJAX call using an ASP.NET Page Method
5. AJAX call using ASP.NET Web Services

The history: the beginning of AJAX

The world wide web and the Internet started as a stateless content delivery mechanism, taking a step backwards compared to traditional desktop applications. Early Internet applications needed to explicitly request every piece of information, and the server sent only the requested data.

Then came what we now call “Web 2.0 application development”: Dynamic HTML, heavy usage of JavaScript, AJAX, and various plugins (Adobe Flash and Microsoft Silverlight). These applications were dynamic and responsive, and they brought much of that rich interactive experience users enjoyed in desktop client/server applications to the Internet. However, due to the request and response architecture that these applications are based on, the latest Rich Internet Applications still cannot match the connectivity and the capability to get real-time data that client/server applications had more than a decade ago.

The reason is that these applications still need to initiate the communication from the web browser to get some data from the server: that is, the client part of the application running in the web browser has no way to know whether the server has some data for it.

The next logical step: polling and Comet programming techniques

Thus, software engineers started working in solving this problem. The client needed to be conscious of any request the server might have for it. But how to achieve this? Well, if communication can only be started by the client, then let’s just make it that way. We’ll make the client constantly ask the server whether there’s some data ready for it. This is what is called polling.

By using this technique, the web application essentially polls the server on a regular basis, based on a timer, using a simple HTTP request each time the timer expires. However, the cost of polling frequently is very high – both in terms of network bandwidth as well as server infrastructure needed to support a huge number of polling requests. The server must have the capability to buffer the data that it needs to send to the client until the next request comes from the client.

After a short while, this technique was seen totally unusable due to its great resource requirements. Then came the Comet programming techniques – long polling and streaming:

In long polling, also known as asynchronous polling, the browser sends a request to the server and the server keeps the request open for a set period. If a notification is received within that period, a response containing the message is sent to the client. If a notification is not received within the set time period, the server sends a response to terminate the open request and the browser resends the request to the server.

When streaming is used, the browser sends a complete request, but the server sends and maintains an open response that is continuously updated. A request is sent and kept open indefinitely (or for a set period of time) and the response is updated whenever a message is ready to be sent, but the server never signals to complete the response, thus keeping the connection open to deliver future messages.

But if you think about it, these techniques are just hacks, tricks used to simulate a technology that doesn’t exist: server-sent events. If the server could actually start the communication, none of these ugly tricks would be needed.

The evolution: server-sent events & Web Sockets

We had to wait until HTML 5 came to solve this problem. The Communication section in the HTML 5 specification section introduces server-sent events and Web Sockets. These new features enable a new paradigm of web application programming that will revolutionize the way to develop and deploy web applications.

Server-sent events are not quite the solution, but a formalization of Comet programming techniques. The server-sent event HTML 5 specification introduces a new DOM element called eventsource.

But the guy we must pay all our attention to is the HTML 5 Web Socket specification: the Web Socket interface defines a full duplex communications channel that is exposed via a JavaScript interface in HTML 5 compliant browsers.

When a new Web Socket connection is established, the browser opens an HTTP connection to the server first and then negotiates with the server to upgrade the connection to a dedicated and persistent Web Socket connection. This process automatically sets up a tunnel through to the server, solving numerous issues that the various Comet programming techniques encountered. Once established the Web Socket is a full duplex channel between the client and the server.

I’ve developed a Web Socket server and client implementation. Check it out for yourself and see what I’m talking about!

Related posts:

1. HTML 5 C# Web Sockets server and ASP.NET client implementation
2. Different ways to use AJAX in ASP.NET
3. AJAX call using an ASP.NET web page
4. AJAX call using ASP.NET Web Services

CSS 3 has quite a few new concepts. Let’s take a look:

New properties

• Borders: border-color, border-image, border-radius, box-shadow.
• Backgrounds: background-origin, background-clip, background-size, layering multiple background images.
• Color: HSL colors, HSLA colors, RGBA colors opacity.
• Text: text-shadow, text-overflow.
• Interface: box-sizing, resize.
• Selectors: attribute selectors.
• Formats: media queries, multiple column layout, speech.

New features

Using these new properties we’ll be able to achieve things such as:

• Borders, background
  CSS 3 will allow images for borders, round corners and shadows. Objects can not only be positioned, but its direction can also be changed (horizontal or vertical).
• Multi-column layout
  Designing pages with multiple columns now will be easier than ever. Until now we needed to enclose the content in two separate DIVs to simulate a two-column layout; now we’ll just use column-count: 2. Not all that hard, right?
• Advanced Layout
  This new feature will allow objects to be distributed along the screen in a better an easier way, and combine them in different manners without additional tags. Besides, the page model will be included: this means that we will be able to indicate page footers, crossed references, and section headers.
• Selectors
  There are new selectors to make it easier locating exactly the element you want:
  E:only-of-type: an element which is unique in its type.
  E:not(s): an element which doesn’t match simple selector.
  E ~ F: an element F with an element E right before.
  E:nth-child: the n-th child element of a parent node. With this selector we’ll be able to implement things such as zebra tables.
  E:nth-last-child: the last child element from a parent node.
  E:nth-of-type: the n-th element which is of a certain type.
  E:first-of-type: the first element which is of a certain type.
• Resizing
  Up till now, if we wanted our elements to be resizable we needed to use Javascript to alter its attributes. With CSS 3 it will now be a task of the browser, just by using the resize property.
• And many more things …

Some properties of CSS 3 are already being implemented in most major browsers. There’s not a 100% fully compliant web browser yet (specially because CSS 3 is not finished yet), but it won’t take much time to have one. This means that maybe we won’t be able to use all of these new features right now, but we can certainly start using some of them. So, what are you waiting for? The sooner the better!

Further reading

• W3C CSS3
• www.css3.info
• 70 Must-Have CSS3 and HTML5 Tutorials and Resources

Related posts:

1. HTML 5: dramatic improvements in the web language
2. The Semantic Web

New tags

• <article /> This new element defines a portion of the content as an article. Perfect for newspapers or blogs.
• <aside /> Represents a fragment of information that slightly relates with the rest of the content.
• <dialog /> Depicts conversations.
• <figure /> Used to associate a caption with an embedded content, such as graphics or video.
• <footer /> Page section to hold author information, copyright statement, etc…
• <header /> Page section to hold some introductory information.
• <nav /> Section oriented to navigation.
• <section /> Element that defines a generic section.
• <audio /> and <video /> Provides multimedia content.
• <embed /> Supports plugin contents.
• <m /> Marked text.
• <meter /> Used to display measures.
• <time /> Used to display dates and/or time.
• <canvas /> Used to show real-time renderized graphics, such as games. For example, Sierra adventure games.
• <command /> Related with commands a user can invoke.
• <datagrid /> Shows additional information if it is requested by the user.
• <datalist /> Used together with the new attribute for <input /> can be used to create comboboxes.
• <output /> Denotes what kind of output the page produces.
• <progress /> Represents a progress bar in a time consuming task, such as donwloading a file.

New local attributes

There’s a few new attributes for some of the elements that were already present in HTML4.

• media: for greater consistency with the link element.
• ping: whitespace-delimited URLs list to which a ping will be produced when the link is followed. For the elements <area /> and <a />.
• target: for greater consistency the <a /> element.
• autofocus: indicates that the <input />, <select />, <textarea /> or <button /> element should get the focus at page load.
• form: attribute for <input />, <ouput />, <select /> <textarea />, <button /> and <fieldset /> which allows them to be associated to a form. This way, they can now be placed anywhere on a page, not as children of the form element.
• replace: will affect the element once changes are performed to it. For elements <input />, <button /> and <form />.
• data: specifies data for the elements <form />, <select /> and <datalist />.
• required: denotes a required element, for <input /> and <textarea />.
• disabled: for the <fieldset /> element.
• autocomplete, min, max, pattern, step: these attributes delimitate the possibilities of the <input /> element.
• list: for <datalist /> and <select /> elements.
• template: for <input /> and <button /> elements, it will be used to repeat templates.
• scoped: for the <style /> element, enables the use of scoped style sheets.
• async: for the <script /> element. AJAX turned into an attribute.

New global attributes

Some attributes that apply to the whole web page document:

• contenteditable: denotes an editable area.
• contextmenu: contextual menu supplied by the user.
• draggable: … needs explanation?
• tabindex: a numeric value representing the order of elements we will tour around when pressing the TAB key.
• irrelevant: … need I say more?
• repeat, repeat-start, repeat-min, repeat-max: these attributes refer to iterations.

HTMLDocument extensions

There are some improvements, and some other elements that finally get standarized:

• getElementsByClassName(): selects elements given a class. Time responses seem to be dramatically improved by using this function.
• innerHTML: present in all ECMAScript implementations, it was not a standard till now.
• activeElement, hasFocus(): will allow us to know which is element is active and which one has the focus.
• getSelection(): returns an object with the current selection.
• designMode, execCommand(): used to edit documents.

HTMLElement extensions:

The DOM element has also had some changes:

• getElementsByClassName(): returns the children of an element that has a given class.
• innerHTML: reads/changes the content of a node.
• classList: a very interesting implementation that, along with className, lets us interact with element classes, providing methods such as has(), toggle(), add() and remove().
• relList: works as classList on the rel attributes of the elements <a />, <area /> and <link />.

This is just a quick overview of the most important changes that HTML will bring. But there’s many more not mentioned here. For a complete reference guide, consult the W3C official draft.

HTML 5 is still a draft. Its definition is not finished yet. But all major browsers are already starting to implement some of its features. There’s still many years to wait for HTML 5 to be as widespread as HTML 4.01 is today, but the improvements this new version bring are so impressive that may affect its adoption speed. The originally proposed name for HTML 5 was Web Applications 1.0, which provides a very good idea about the goal of this new standard.

Further reading

• Yes, you can use HTML 5 today!
• HTML 5 cheat sheet
• Coding an HTML 5 layout from scratch
• A selection of supported features in HTML 5
• Preparing for HTML 5 with semantic class names

Related posts:

1. CSS 3: one more step in the evolution of the web
2. HTML 5 Web Sockets
3. The Semantic Web

Semantics is the study of meaning, usually in language. The word “semantics” itself denotes a range of ideas [...]. It is often used [...] to denote a problem of understanding that comes down to word selection or connotation.

The Semantic Web is an extended web, with a greater meaning, in which users will be able to find answers to their questions faster and easier due to a better-defined information. This meaning-based web is supported by a set of standardized  languages that solve the problems the semantic-less web has, in which access to some information is a difficult and frustrating task.

The web has changed the way we communicate and do our work. Worldwide low-cost instantaneous communication is possible nowadays. We have access to millions of resources, regardless of our geographic location or language. These features have made the web tremendously successful… and at the same time they have provided its biggest problems: information overload and heterogeneity of information sources.

The Semantic Web aims at solving these two great problems, allowing software to perform some of the tasks the user must take care of now. Thanks to semantics in the web, software can process its contents and make logical decisions to solve everyday problems automatically.

Imagine you would want to find the nearest open pharmacy. You would go to your favorite web search engine and type “pharmacies open right now”. Today’s search engines would offer different information about pharmacies, but nothing related to what the user exactly wants to know. The next step would be to go through all the options listed and manually search for the precise information. Figure 1 shows the results a user would get with a regular search engine today.

By building semantics into the core of the web the search results would be accurate. Software would be able to properly understand what the user is asking for. Figure 2 shows results with a semantic search engine. These results give the user the exact information he was looking for. Geographic location would be detected automatically, and words like “right now” acquire greater sense and get translated to today’s date. All the information would be full of meaning.

The way information will be processed won’t be based on input/output parameters, but on its semantics. The Semantic Web provides an infrastructure based on metadata, allowing software to reason on the web, extending its capabilities.

It’s not about a magical artificial intelligence that will enable machines to understand human words… it’s just the skill of a machine to solve well-defined problems through well-defined operations that will be performed on a well-defined data set.

Further reading

This article covered just the very basics of the Semantic Web. If you’re still interested, you can expand your knowledge at:

• Semantic Web
• Web Ontology Language
• semanticweb.org
• Swoogle: experimental semantic search engine (if you’re going to use this, you might as well be interested in the FAQ)

Related posts:

1. HTML 5: dramatic improvements in the web language

Martin Kool has made this possible. He has developed an open source engine to play games straight in your browser, using the canvas tag from HTML 5. And besides, he has ported many of the old Sierra adventure games, like Leisure Suit Larry in the Land of the Lounge Lizards, Space Quest I: The Sarien Encounter, Gold Rush, etc.

I would say it has kind of a retro look ...

This engine works on Firefox 2+, IE 6+, Chrome, Safari and Opera. It also seems to work on iPhone and Wii (although it may still need some tweaks). You can play these games with both keyboard and mouse. And if you’re tired of playing you can save your game and continue from that point the next day: an URL is generated containing your position and status.

Making of

Martin tells us in his pages how he managed to develop the whole thing:

In 2003, I created Good Old Adventures. It was a chat environment set in the Sierra worlds without actual gameplay. All images were manually crafted, copy/pasting from WinAGI Game Development Studio. A time consuming process.

Four years later I wrote a few conversion tools in .NET to extract Sierra’s in-game images and objects from the original games, and display them properly on the web. The “only thing” left to do then was to export and understand all in-game logics.

I was able to convert the logics to javascript, but there was one big problem: Sierra’s code used GOTO statements, and those could jump anywhere in the code, even inside a nested “if”-statement. It seemed unsolvable in javascript.

I sat down together with Sjoerd Visscher, one of my collegues at Q42, and we came up with a solution. Using a decompilation approach to get rid of nested “if”-statements and putting the whole shebang inside a huge switch/case statement, we could mimic line numbers and GOTO’s while maintaining performance.

Martin’s achievement is some impressive demonstration of what can be done with the new canvas tag. HTML 5 will totally change the way we see the web.

Related posts:

1. HTML 5: dramatic improvements in the web language