WebSync: FAQ

General Questions

• How many users can be supported with WebSync?

  To give WebSync a real test, we purchased an old 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.

WebSync On-Demand Questions

• 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. Check out our section in the documentation about proxies for details.

• 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 our On-Demand servers 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?

  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.

• Is there a maximum message size?

  Not really, but there is a caveat. If you're using a certain web browser (cough IE cough), 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.

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

  Not at all, set up as many as you need. 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 only have to be unique to your domain. Channels are scoped to the requesting domain, so your channels can be the same as those of another domain, and they will not cross-talk.

WebSync Server Questions

• How do I detect when someone closes their browser?

  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.

• 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.

• What's the difference between EventContinue.Immediate and EventContinue.OnComplete?

  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.