WebSync FAQ - Frozen Mountain

WebSync FAQ

General

  • How many users can be supported with WebSync?

    To give WebSync a real test, we purchased an Acer desktop with 3 cores and 3 Gig of RAM. We then hooked up two laptops (2 gig ram, dual core processors) to simulate the clients. When testing upper limits of client connections, we hit 30,000 clients simultaneuously connected with no problems and we pushed over 30,000 messages a second.

    When we hit these upper limits, the problems we started having were related to the laptops not being able to process the responses, not due to the server failing to send them. This was done over a 100 Mbit connection.

  • Is the WebSync Server and Client code thread-safe?

    Yes. All public methods are accessible in a completely thread-safe manner.

  • What character set is used in WebSync?

    WebSync encodes all requests and responses in UTF-8.

  • How do I publish data from my server so it goes out to my connected clients?

    For this, you will want to use a "Publisher", which will create and send a request to the WebSync server with about two or 3 lines of code. Check out our section in the documentation about publishers.

  • How do I know when someone has subscribed or unsubscribed from a channel?

    All you need to do is set up a handler for the "onSubscribersChanged" event. This is a simple function that will fire when a user enters or leaves a given channel, containing details about which users have entered or left.

  • Is there a maximum message size?

    Not really, but there is a caveat. If you're using a certain web browser (*cough* IE *cough*), and you're using cross-domain requests, you're going to be limited to the length of a GET request, since it uses JSONP. This limit is 2083 characters, which is significant, but worth noting. Since this limit only applies to publishes, you can easily bypass it by ensuring that your publishes occur on the same domain as your page.

  • Is there a maximum number of channels I can have?

    Not at all, set up as many as you want. In fact, WebSync can actually be more efficient with more channels. They'll get created and torn down as needed, so be creative!

  • Are there restrictions on channel names?

    Only one: channel names must start with a "/". Beyond that, the sky's the limit.

  • Do my channel names have to be unique?

    They can be whatever you want them to be. There is no restriction on how many or what names you use for your channels, so as long as you understand that messages are grouped by channel, you're good to go.

  • How do I detect when users disconnect from the server?

    There are 2 ways to detect when users disconnect from the server:

    1. Use the "onSubscribersChanged" event on the client
      This event exists on the clients to provide a simple way to know when people leave a given channel. While this doesn't explicitly let you know that a user has closed their browser, many times it accomplishes the desired end result.
    2. Use the "Disconnect" event on the server
      Using this method will guarantee you are notified when a client disconnects. Regardless of *how* they disconnect, this event will fire and you will be able to take the appropriate action.

    Note that you can use the "autoDisconnect" property of the JavaScript client to make the disconnect event occur more "immediately" for web-based clients. If you set the disconnect property of the JavaScript to { sync: true }, the browser will make a syncronous XHR request to the server when it closes to disconnect the client. Note that for this to work properly, you must also set the disconnect url to be on the same domain as the page being closed.

WebSync On-Demand

  • Where does my private key go?

    Your private key should be used in your proxy. The request goes from the client to your web server, at which point you add in your private key to override the key sent from the client. The request is then forwarded to our WebSync On-Demand servers for processing.

  • How do I set up a proxy?

    Proxies are very simple to set up, and involve simply running a simple page on your server that can pre-process the request. Check out our section in the documentation about proxies for details.

WebSync Server

  • Why am I getting the error "String reference not set to an instance of a String. Parameter name: s"?

    This is almost always due to bad data being passed into JSON.Deserialize(). This method relies on Microsoft's DataContractJsonSerializer, which does not accept a null value as the target of deserialization. Ensure that you're not passing null as the value to deserialize.

  • Why am I getting "fm is undefined" when I try to run my page?

    This means that your client handler is not properly registered, or the path you've specified to the client handler was not found. Try browsing directly to the URL for your client.ashx file, and confirm that it's returning valid javascript. If it is, then confirm that the path you've specified in your web page matches the URL you browsed to.

  • Why do I get a 404 error when I browse to the URL that's supposed to contain my client javascript in IIS, when it worked in Visual Studio?

    This is almost always a question of finding the right path according to your web.config. First, confirm that the path to your client.ashx (or whatever you called it) is correct by looking at the "Handler Mappings" section of IIS. Then, confirm that you're browsing to the correct url, and your page is pointing to the right url in it's <script> tag. If those settings are correct, then you might want to confirm that IIS is configured to handle ".ashx" extensions.

    If all of the above checks out, you might want to make sure that you've got the right configuration according to your version of IIS and the "Application Mode" of your app pool. For IIS 6 and IIS 7 classic mode, the "system.web/httpHandlers" section will be used, and for IIS 7 integrated mode, the "system.webServer/handlers" section will be used. In an attempt to cover both scenarios, all our examples include both sections, with the "validateIntegratedModeConfiguration" flag set to false to disable validation in IIS 7.

  • What's the difference between Execution.Normal and Execution.FireAndForget?

    For each event in WebSync, there are 2 possible scenarios for how the event gets processed, specified as attributes on the method in the format Execution.[XYZ]. These 2 scenarios are:

    1. Execution.Normal. In this mode, the referenced function will be executed inline by WebSync, and WebSync will not continue processing the current request until the function has completed. This allows modification of messages, because the request will not continue until all event code has run. This does NOT prevent WebSync from handling other incoming requests.
    2. Execution.FireAndForget. This mode is used when you are performing operations that could potentially take a long time to complete. It allows you to perform these long operations without interfering with the response time of WebSync. You cannot modify the messages if you are using this mode, which means it cannot be used for authentication/authorization.

    WebSync uses Execution.Normal by default, which means that WebSync will wait for your method to finish before continuing with processing the request.

WebSync, version 2.0 (old)

  • How do I detect when someone closes their browser? (Deprecated in version 3.0: see above)

    Short version: the "BeforeUnsubscribe" and "AfterUnsubscribe" events are guaranteed to fire for every WebSync client when they are no longer subscribed to a channel, regardless of whether they manually unsubscribed, manually disconnected, or killed their browser session.

    Long version: the age old question of tracking when users leave your site is a good one. And you must remember that you can't just detect browser closing, because you have to handle someone killing the browser process, shutting down their computer, etc. The good news is, WebSync can handle all this for you.

    First, you need to understand that WebSync automatically cleans up after itself. If, after a (configurable) period of time, a client fails to communicate with WebSync, WebSync will flag and disconnect the client. When this happens, WebSync will fire the "IdleDisconnect" event. This is distinct from the "Disconnect" event, which is fired when a user manually disconnects. (These two events are distinct from each other because "IdleDisconnect" events do not involve actual messages sent from the disconnecting client.)

    Second, you need to know that clients are guaranteed to fire the "unsubscribe" events for all channels to which they were at some point subscribed. That means regardless of whether they call "unsubscribe" manually, disconnect via the "disconnect" method, or were disconnected due to inactivity, the "unsubscribe" events will always fire.

    Given those two pieces of information, it follows that you can always know when a client is no longer available by simply hooking into one of the "unsubscribe" events, and tracking the "clientId" as needed.

  • What's the difference between EventContinue.Immediate and EventContinue.OnComplete? (Deprecated in version 3.0: see above)

    For each event in WebSync, there are 2 possible scenarios for how the event gets processed, specified as attributes on the method in the format EventContinue.[XYZ]. These 2 scenarios are:

    1. EventContinue.Immediate. In this mode, the referenced function will be executed on a separate thread from the main WebSync thread. WebSync will queue the function for execution, but will not wait for it to complete before continuing.
    2. EventContinue.OnComplete. In this mode, the referenced function will be executed inline by WebSync, and WebSync will not continue processing the current request until the function signals that it has completed by invoking "HandlerEventArgs.Complete()". This allows modification of messages, because the request will wait indefinitely until it is told to continue. This does NOT prevent WebSync from handling other incoming requests.

    For performance reasons, WebSync uses EventContinue.Immediate by default. This allows processing of the request without impacting latency within WebSync, which is good for doing simple things like logging, storage, and so on. However, if you need to cancel a message, or if you want to ensure that any errors that occur during the processing of the message get back to the client, you must specify EventContinue.OnComplete. This way, WebSync will wait for your processing to occur before determining how to finish handling the request.

  • How do I know when someone has subscribed or unsubscribed from a channel? (Deprecated in version 3.0: see above)

    In the latest version of WebSync On-Demand, you have access to "meta" data. This information tells you when someone arrives or leaves a channel. You can set up a handler for this data when you subscribe to a channel. You can learn about it by looking in the documentation for the "subscribe" method found here, in particular the "onMetaReceive" function.