WebSync 2.4.2 Released

by Administrator 22. October 2009 23:37

As always, once you have a new version of a product out, the requests come flooding in. To that end, hot on the heels of our recent 2.4.1 release, we're now releasing WebSync version 2.4.2, fully backwards compatible and ridiculously over-tested!

WebSync Server

For WebSync Server, this release fixes one issue, and introduces some nice new features. Here are the details.

Bugfixes

  • We've applied a fix to address issues with encoding of extended characters sets. UTF-8 encoding is now used across the board.

Features

  • The javascript client is now more resilient to bad data; as a result, the javascript client will now display a nice message if you attempt to send invalid data through WebSync, letting you know exactly what caused the problem.
  • The "Unsubscribe" event will be fired for users that are getting disconnected due to idling, which means all clients are guaranteed to unsubscribe to any channel to which they've subscribed.
  • The database name is no longer required to be "WebSync"
  • Support for external config files was added
  • Connection string names and HTTP Direct Publish settings can now be specified in the config file, allowing you to override attributes you've set in code

WebSync On-Demand

For WebSync On-Demand users, you will also get the benefits of the additional error checking and extended character sets, and will also get a great new feature - meta data! In the past, the one difficulty with using WebSync On-Demand was knowing when users subscribed to or unsubscribed from a given channel. With version 2.4.2, this problem is a thing of the past, as we've added support for meta-information. To take advantage of this feature, you simply add an additional property when subscribing to a channel, "onMetaReceive". This function will receive notifications when new users subscribe or unsubscribe from the specified channel, and you can make your application update accordingly. You can learn more about this new property by reading the subscribe documentation. And for those of you wondering what happens when someone kills their browser without properly unsubscribing first - when WebSync performs its automatic cleanup, you'll be notified that the user has unsubscribed, so you're covered there too!

Don't forget to update your client javascript url to:

http://sync.frozenmountain.com/client.js?v=2.4.2

Those of you using the .Net API, please get a new copy of the WebSync.Core.dll from our downloads section.

Tags: ,

Comments

11/15/2009 1:35:16 AM #

Phil Leggetter

Great work guys. I'm really pleased to see a Comet solution available to IIS server users. I'm looking forward to downloading the trial and having a play.

I'd also be interesting in hearing about how well you think WebSync will scale.

"Peak tested at over 30,000 messages per second on a local network."

Does this mean that if you have 1,000 users, each can receive 30 updates per second?

I'd also be interested in hearing how you have dealt with the threading scalability issues inherent in using IIS:
http://www.aaronlerch.com/blog/2007/07/08/creating-comet-applications-with-aspnet/

Again, great work and good luck.

Phil Leggetter United Kingdom | Reply

11/16/2009 12:38:39 AM #

anton.venema

You should see higher performance in that particular scenario.  In our tests, our server was a basic Acer AM1201, and we had 30,000 users connected to a [b]single channel[/b] receiving 1 update per second.  Distributing the load across multiple channels enables more efficient message distribution on the server, which cascades out as an overall improvement.

The threading and scaling issues are... complex to say the least. :)  We spent many long hours running tests through a performance profiler and analyzing the results to identify bottlenecks within both our own code and the .NET framework.  We should maybe save the details for a later blog post.

anton.venema United States | Reply

Add comment




  Country flag


  • Comment
  • Preview
Loading