Hey folks, we recently had an interesting discussion with some of the folks at Tech Werks about a recent implementation of WebSync On-Demand. The following is a summary from their founder, Bill Baker:

Tech Werks, a video streaming technology company, has been working with Frozen Mountain for several years, integrating Frozen Mountain's WebSync On-Demand services into their video encoders and live presentations. 

In addition to their work with various national and international television networks, Tech Werks supplies video streaming services and specialized on-line applications for the United States State Department. 

Recently, Tech Werks supplied these services for the APEC summits. The most recent Summit (November 2011) was held in Hawaii and involved many world leaders, including Presidents from the US (Barack Obama), China (Hu Jintao), Russia (Dmitry Medvedev), and Japan (Yoshihiko Noda).

During the primary Summit meetings, several world leaders had PowerPoint/KeyNote presentations.

The State Department asked Tech Werks to supply a system whereby each leader could use a simple tablet device (iPads in this case) to display and control their presentation, and send this presentation in real time to 25 other tablets for each leader to view. 

Needing a solution quickly, Tech Werks turned to Frozen Mountain's WebSync On-Demand comet solution as the real-time delivery service. 

Tech Werks integrated Frozen Mountain's WebSync On-Demand SDK into their pre-existing "app", and loaded the app on over 100 tablets, 25 of which were located on each seat in the primary plenary. 

During the summit meeting, each leader had a tablet and could advance forward and backwards through their presentation, and as they did so, all 25 tablets advanced forward and backwards in sync with the presenter.  

The app worked flawlessly, thanks to Frozen Mountain’s WebSync On-Demand Service.

Today I'm pleased to announce the release of WebSync 3.5, which adds full support for Java-based clients, which means we now have native support for Android and Blackberry!

Previously, WebSync was a real-time communications platform for .NET and the browser. With this release, we now have full native support for the full line of most popular smartphones and mobile devices - iPhones, iPads, Android phones, Android tablets, and Blackberry devices too!

We've done our best to keep the APIs between the various languages as consistent as possible, so the learning curve is absolutely minimal.

We've also added (as usual) a few little performance improvements, and in a couple places, better error handling.

So what are you waiting for? Go get the latest copy, or point your script to client.ashx?v=3.5.0!

Hey everyone!

Good news! We've just released WebSync 3.4.2! As always, you can check out the changelog, but the items of note are:

• better support for transferring of in-memory cache between overlapped worker processes, to avoid clients getting inadvertently idled out when the application pool resets and reduce the load on the database for SQL providers
• performance improvements for iOS and JavaScript JSON parsing
• support for changes to the system clock
• performance improvements to the SQL provider
• fix for the notorious IE "c00c023f" error
• fixed memory leak in the JSON parser

So, overall, pretty awesome release, if I do say so myself!

As always, you can grab a new copy of WebSync Server from our downloads page, and for the On-Demand customers, simply point your script to ?v=3.4.2!

Happy New Year! A new release of WebSync is out! This is basically a patch release, fixing a bunch of minor issues in the 3.3 branch.

Feel free to check out the changelog, download a new trial, update your purchase, or use the latest On-Demand code by pointing your script tag to ?v=3.3.2.

Happy Coding!

Hey everyone, it's that time again!

(Deja vu?)

Well, we had a minor bug in 3.3.0, so hot on it's heels is WebSync 3.3.1. This release resolves a JavaScript client bug that would cause an alert to show up if the following happened in order:

1. you used the meta field in your connect call
2. the server was reset
3. the server-side client record could not be restored (as you'd see in WebSync Express)

For those of you using WebSync Server, and who have downloaded a copy in the past day, you'll want to grab a new copy :).

For those of you using WebSync On-Demand, simply point your client script to ?v=3.3.1

Happy Coding!

Users today are often subjected to the 2-connection limit imposed by some browsers. With WebSync 3.3, we've made removing that limitation as simple as possible. There are now just 3 steps:

1. Add a Wildcard DNS entry for your domain
2. Set up IIS to support that Wildcard DNS entry
3. Tell WebSync about it

Steps 1 and 2 are pretty simple, although they may vary somewhat according to your DNS provider. Step 3, however, is incredibly easy. Simply tell WebSync where your wildcard exists:

client.initialize({
  requestUrl: 'http://www.example.com/request.ashx',
  stream: {
    requestUrl: 'http://*.stream.example.com/request.ashx'
  }
});

Yep, it's really that simple! No more connection limit woes.

Client Imposed Limits

When dealing with long-held connections, one of the most frequently encountered problems is that, by default, most browsers drastically limit the number of concurrent connections. Internet Explorer, still the most-used web browser, limits to 2 connections (Firefox, for comparison, defaults to 6). This creates a problem with long-held requests, because the long-held connection will interfere with other, standard requests.

Thankfully, there's a pretty simple solution: place your streaming connections on a subdomain. Since all browsers treat subdomains as a unique domain for the purposes of limiting concurrency, you can move your streaming connections to a subdomain (or multiple subdomains; wildcard DNS is a great option here) and be off to the races. The downside is that this solution requires that your JavaScript client is capable of cross-domain communication. But good news - the WebSync JavaScript supports cross-domain communication out of the box!

Let's look at an example:

// random character (a-z)
var c = String.fromCharCode(Math.floor(Math.random()*25+97));

fm.websync.client.initialize({
    requestUrl: 'http://www.foo.com/request.ashx',
    stream: {
        requestUrl: 'http://' + c + '.stream.foo.com/request.ashx'
    }
});

This example places our "normal" requests (such as publishes/subscribes/etc) on the root domain, and the "stream" requests (all the long-held stuff) on a random subdomain under "stream.foo.com". When the page loads, we'll grab a random domain, so until a given user loads up at least 3 pages, all at the same time, that all randomly get the exact same character, the long-held connections won't interfere.

If you wanted to make this even more bullet proof, simply replace the single character 'c' with a multiple-character subdomain. Since we're using wildcard DNS, it doesn't really matter what the characters are, just that they're unique for the given client.

Hey everyone!

We have a new release of WebSync, version 3.2. This is an awesome release, as it adds a bunch of new features and gives a dramatic boost in performance.

Here's the quick summary; for a detailed list, check out the changelog.

• Improved connection management in the .NET client, including enforced timeouts to ensure connections are destroyed no matter what after a specified period of time
• Shutdown management so WebSync shuts down quickly and gracefully when reset
• Improved error handling on initial load, including detection of invalid method signatures for event handlers
• Improved Azure support via the stateless SQL provider
• Improved documentation to work via the file system in IE
• Huge performance improvement with respect to message throughput

The biggest change is the performance improvement. Previously, WebSync was able to deliver upwards of 30,000 messages a second. With WebSync 3.2, it's now capable of delivering over 100,000 messages per second!

As always, for those of you using On-Demand, simply adjust your client script to point to client.js?v=3.2.0, and you'll get all the latest changes. For those of you using WebSync Server, check out the Portal and download the latest copy from your Order History.

Happy coding!

Warning: technical content ahead!

Recently, we were recently doing some work for a client when we came across a minor problem. We were building an application that had a bit of a unique requirement: the entire application had to work with the inclusion of a single <script> tag. Scripts could be added dynamically, but the end user had to only see a single tag.

"Simple enough", we thought; we'll simply combine the JS and CSS server-side, and be done with it. Of course, that would have meant manually extracting the JavaScript for the WebSync client from the server code. Now, that's not difficult to do (it's just an embedded resource), but we were curious if there was an even simpler solution. An extra request was completely acceptable, and since we were already using jQuery, we figured we'd just use that to load the script. The result was this:

$(function(){
  $.getScript("/client.ashx", function(){
    client.initialize();
    client.connect();
    // ...etc
  });
});

"Great", we thought. Problem solved. But then we realized that none of our client requests were being sent anymore! We pondered for a moment, and then remembered that the WebSync client is designed to monitor the "contentReady" event of the DOM so as to avoid the dreaded never-ending loading indicator. So, if the client script loads after the DOM event has already fired, the client is never notified that it is allowed to start making requests.

Thankfully, the designers of WebSync (that's us!) put some thought into this problem, and had a solution already waiting in the wings:

$(function(){
  $.getScript("/client.ashx", function(){
    fm.utilities.ready();
  });
});

That handy extra line tells the WebSync client that the DOM is ready to be used. It then fires any events that were queued up in the addOnLoad() utility function, running them immediately. That's it! So what're you waiting for - get coding!

Hey everyone!

It's that time again - time to check out the latest version of WebSync! In 3.1, we've got a bunch of new stuff, and a number of other fixes too:

• General
  • Full support for the .NET Compact Framework, version 2.0+ (woohoo!)
  • Updated the core serialization so it can handle incorrect but salvageable JSON inputs
  • Updated examples so that the serialized data is the same between the .NET and JavaScript examples
  • Updated the StatelessProvider API to take a ClientRecord parameter for ConnectClient method implementations for future compatibility

• Server
  • Added a new static method for deserializing incoming message and publications directly from a raw HTTP request (so you can pre-process them if you need)
  • Added a few minor performance improvements

• Clients
  • [.NET] Added a new "OnRequestCreated" event for the .NET client and publisher to allow full control of the web request before it's delivered
  • [.NET] Fixed a bug in the .NET client where the subscription reference would get held after the channel was unsubscribed
  • [JavaScript] Added handling for complete network failures (such as pulling the computer's network jack) to the JavaScript client
  • [All] Fixed a bug in the server that allowed a client that had been disconnected to publish
  • [All] Fixed a bug in the .NET and JavaScript clients with mult-channel subscriptions

As a random side note, the JavaScript client is now very determined to stay connected; we tried just about everything to prevent it from staying online, and it always jumped right back in...

For those of you using WebSync On-Demand, your new URL is: http://sync3.frozenmountain.com/client.js?v=3.1.0

For those of you using WebSync Server, check out our downloads page. If you've already purchased and want the latest, log in to the Portal and check out your "Order History" tab.

Thanks everyone for your feedback, and enjoy!