Links: Prev Section Next Section Top
This appendix attempts to briefly answer "Why we choose what we did?"
The use of the word "baseline" is important as there are many other products (Microsoft NetMeeting, AOL Instant Messenger, ICQ, Yahoo! Pager, etc.) which feature text chat capability. IRC was chosen as the baseline technology for the Synchronous Work for the following reasons (+ means positive feature, - means "accepted negative) feature:
Note that many of the techniques discussed in the main body of this report apply equally well to IRC and other text-based chat mechanisms.
TCP (transmission control protocol, a connection oriented protocol) uses a fixed port choice (often referred to as well-known port number) to connect the client process to the server. Firewalls, which allow owners to block some TCP/IP uses while allowing others, can block on a variety of characteristics including port numbers.
The normal port used by IRC servers is 6667. Use of this standard eliminates some configuration effort on clients as most client software defaults to this standard value. However, if a particular owner has decided to exclude normal IRC chat (due to other chat services that are not considered "important" to the owner) then using another port may allow the chat user doing "electronic meetings" through a firewall to a IRC server set up for electronic meetings.
Our present IRC server allows users to connect on either port 6667 or 7000 (the former for ease of setup and the latter for firewall issues.) MSChat limits port choices to 6000-7000 and 7000 was arbitrarily chosen as the alternate port number. [[We are requesting that e-conf users behind firewalls research this issue and give advise on the alternate port number. See the note below for an alternative approach to firewalls.]] [[The tools folks may wish to take this on as a sub-topic in the other appendix.]]
Note: Another solution to the firewall problem is to approach the firewall owner and seek to have an additional rule added to the firewall rules which allows IRC conversations to a particular meeting server based on fully qualified domain name (FQDN) or IP number.
Auto-flood protection is used by IRC clients to solve a "denial of service" problem where some (bad) IRC user tries to deny another (victim) IRC user access to the groups information. The bad IRC user does this by "flooding" the victim with so many lines of input that they can't handle any other input. The client setting which helps fix this problem is to auto-ignore IRC users who send more than some number of lines in a time period.
Alas, this features prevents an IRC user like a moderator from sending multiple lines by a "cut & paste" method without risking becoming ignored by meeting participants. In closed IRC environments such as the one being proposed for meetings, the "benefits" of multi-line sending exceed the problems of multi-line sending and thus users are advised to permit this multi-line sending.
Note: This setting is often "missed" by beginning participants so the moderator should be prepared to assist them in real time "fixing" of their clients. [[Note to tools folks --> you might wish to emphasize this setting on a tool by tool basis in the documentation.]]
Electronic chat meetings generally proceed slower than the equivalent face-to-face meeting depending upon the amount of preparation by all participants. Unlike face-to-face meetings, participants who are "listening" can actually handle a minor interruption or stretch without impacting the meeting. Our recommendation is to limit meetings to a maximum of two hours, and strive to keep the meeting as short as possible while ensuring full participation.
|
Links: Prev Section
Next Section
Top
|
|