Umbrellas for iChalk

The Most Common Problem
You may occasionally run into trouble due to imperfection in iChalk or in your network condition. The most common problem occurs when you have real time mode on with the update-cycle set to less than a few seconds. While it is impressive to have your drawing almost instantaneously updated at the other end, for complex pictures and less than optimal network conditions, it is possible to lose some of the data. When this happens, the first thing you may try is to switch off the real-time mode as it is most likely the culprit. You may, instead, try to increase the real-time update cycle time to more than three seconds in the preferences. The server (who started the shared board) may order everybody to make fresh copy of the last transmitted board by issuing the "Server: Fresh Copy" command in the Connections:Advanced menu. (See below) This way, everybody can make a fresh restart with good part of data retained.
Using Panic Items in the Menu
  • Needless to say, it pays to SAVE often. That way, at least someone in the group has the up-to-date copy of the group work, and in the worst case, the whole group can start from there afresh.

  • If not, before folding the table, try one of the items from the sub-menu humorously titled "Advanced" in the "Connections" menu. Please do not try them if not as the last resort. Some of the items are available only for the host. As someone who did extra work to set up a collaboration, we thought he or she deserves some extra control. They will be gray-out for non-hosts.

  • Unlock Keys The most benign problem may arise because some of vital exchange of information got sucked into a network congestion. This could have left the server in an inconsistent state, especially leaving its content in a "locked" state. Any subsequent attempt to change the document may be bluntly ignored even when your button indicates green or blue. If this ever happens, here is what you do: in the Connection menu, go to the submenu called "Advanced", find the item called "Unlock Keys". It is safer if you do this when everybody has green button.

  • Force Local More serious trouble may have left your connection in such a mess that you really feel like opting out to rescue whatever remains on your machine. Item called "Force Local" will force yourself dropped from collaboration into the local mode. This is similar to the normal "disconnect" action, but this time you do it without notifying the other members of the group. This may leave other people (if they are still there) in a slightly confused state since they may still have you in their list. But what do they expect? You didn't cause this yourself! As a penalty, you may have trouble joining again later, since the server still carries your (ghost) name with it and may refuse your reentrance in certain situations.
  • Server only
  • Server:Force Yield As the server, you (and only you) have the authority to make anybody in the group yield control of the document. This is for when, for either a psychological or physical reason, one can not let go of the hold on the board. The item called "Server:Force Yield" will cause the board to be freed. (assuming that everybody still listens to and obeys you....) If your collaborator keeps you on hold for unreasonable duration, bribe the leader of your group to exercise this option.

  • Server: Fresh Copy When network congestion forces an update process to terminate prematurely, some members in the group may end up with a corrupted document. If you suspect that the users do not see the same content in the board, the server should issue the "Server: Fresh Copy" command to re-synchronize. It will initiate a process where every member will restore the document to the state when it was updated the last time. (just one cmd-return key ago) It will be rather unfortunate for someone who is in control and is busy editing it at the very moment, since it may be lost, but it is better to pull everybody up to speed before it gets irrevocably out of control. As you know by now, it is possible for the server to remain serving while not being a client to oneself. That is, one can do all the drudgery not participating in the collaboration by disconnecting from oneself. In that rare situation, one should not exercise this option as it will replace the group work with whatever is locally on the serving side.

  • Server: Toggle Bouncer This is one of the preventive measures the server may take when the size of the group becomes uncomfortable for efficient communications. When this menu item is turned on, iChalk will put up a blunt bouncer against anyone who tries to join the group. (He will be immediately fired when the host deactivates it.) If one could foresee the problem, then the maximum number may be set in the Host panel at the beginning of the collaboration.

  • Server: Drop Selected The server may choose a group member in the list (accessed in the Chat drawer) and toss out. We hope it is with a good reason. One legitimate reason could be to remove the ghost client out of the way. A client becomes a ghost when he or she chooses the "Go Local" in panic for some reason. [Under normal circumstances, the member should have left the group by choosing "Disconnect" properly notifying everybody in the group.] The ghost status will remain so unless the server detects it and take care of it as part of its automatic patrol (see below). While it is better to keep clean account of everybody, this may not be a critical issue for most cases.
  • Automatically tossing out unreliable members
    This may sounds a little harsh, but no hard feelings. The server checks on regular basis (called poll-interval in the Network pane of the Preferences) to check on every active member of the group. If any one misses this important call given number of times in a row (set by No Answer Tolerance in the same panel), the server will drop the member off the list as it has become unforgivably unresponsive. This is to save others from suffering bad connection. Server still maintains the dropped member alias in a different list, and will reinstate its status if it receives a signal from the member later. Therefore, in most the time, the dropped member may not even notice all this going on while he/she was caught in a momentary network congestion.
    Hijacking the control of the session
    We hope you will not be reading this and find out about this shameful technique. When the status button is red, if you press it once, the auxiliary window opens for you to while away. However, if you persist and press it six times in a row, it will grab the control from the current (and rightful) owner. Now, let us see what a brilliant idea you had to justify this!
    Fine tuning the connection timeout parameters
    In the iChalk Preferences, you will come across the Network section with various timeout and tolerance parameters. Finding the right parameters may be critical for a smooth session especially when group members have a wide range of network quality. With some patience, you may be able to dramatically reduce need for "umbrellas" tweaking these parameters. We find that 120.0 seconds for Host timeout works for both LAN and internet connections. Client timeout may be between 5.0 and 10.0 seconds for fast LAN, maybe 30.0 seconds for internet. Poll interval for host may be as small as a few seconds, but give it at least 30 seconds, if you anticipate a laggard among your clients.