Distance Education Using Linux and the MBone
The MBone tools were not specifically designed with distance education in mind. In fact, though interoperability and uniformity between the applications was a goal of the original designers, it had yet to be achieved when the first MBone classes began at NC State. Additionally, the tools themselves have a relatively steep learning curve for nontechnical users. For example, in order to create a new session, a number of technical options have to be set in sdr, including Type of Session, Session Scope, Type of Media and Session Time. Experienced users have little difficulty navigating these options, but to meet the needs of distance education, users have to be able to operate the tools with only minimal training. In order to accomplish this goal, the distance education Teaching Assistant was created. DETA is a wizard-style interface to the MBone tools. It hides all of the technical options the inexperienced user should not have to deal with. Originally, it primarily functioned as a simplified interface for starting Mbone-based Distance Education classes. Over the years, a number of features have been added, including the ability to give preprepared presentations and automatic digital archiving of classes.
The underlying purpose behind DETA is to meld the various tools and supporting programs into a single, easy-to-use application. DETA is written in the Tcl/Tk interpreted scripting language. The primary reason for this choice has to do with the MBone tools. All of them are Tcl-based applications written in C or C++. This not only provides great flexibility within the applications themselves, but also allows for basic interoperability between them. This interoperability is achieved through Tcl's Send command. Send allows one Tcl interpreter to execute commands remotely within another applications interpreter. In DETA, the Send command is primarily used to remotely operate SDR, as well as to set options within the other MBone tools.
One of the drawbacks of using the Tcl Send command for communication is that it doesn't hide any of the various tool's internal implementation. This becomes an issue when that implementation is changed, or a new tool is added. The core DETA script then has to be altered to adapt to the changes in the tools. One solution to this problem is to modify the various tools directly so that they communicate via a common, implementation-independent bus. This would require separate modified versions of the MBone tools. Rather than use modified versions of the MBone tools, it was decided to modularize the code that communicates with the various tools into separate interface packages. The interfaces contain all of the tool-specific Tcl code in string arrays. These arrays are sourced by the primary DETA script at startup. In this way, the core script can be modified without affecting implementation-dependent code, and new or updated tools can be added simply by creating new interface modules.
When the user first starts DETA, he or she is given four mode options, as seen in Figure 1. The first is to create a new session. This creates a new multicast session that will be announced while the session is active, and which will expire after the session becomes inactive. By creating the session, the user becomes the designated host of that session. The second option is to host an existing session. This mode is included so that users can host permanently existing sessions. At NC State, a session directory server was written by Troy Holder that continuously announces class sessions. In this way, semester-long class announcements do not have to be re-created at every meeting. The third option is to join an existing session. This is the option that a remote participant would select. It allows the user to select a desired session from a list of available sessions and then join it. The last option is to play a recorded session. This mode is used to select a previously archived session for playback via a remote VCR server. Once the mode is selected, the user enters information about the session. Figure 2 shows the information required when creating a new session. This includes the name of the session, the lecturer name, and the MBone tools to use in the session. This is saved between sessions and usually doesn't need to be re-entered. Once the options for the session have been set, DETA creates the session and loads the MBone tools.
In addition to melding the core MBone tools, a number of features have been added to DETA. The first is a tool called WBDImport developed at NC State. This tool is modeled after WBImport, which was written by Van Jacobson. It allows the user to give a PowerPoint-style presentation using the shared whiteboard tool. The format used for slide files is generic PostScript. The user indicates which files will be used at startup, either by specifying a directory containing the slides, or by specifying a text file containing a list of all the files and their locations. During the session, a WBDImport window lists all of the slides specified at startup. To show a slide, the user simply clicks the name of the desired slide and it is loaded into the shared whiteboard. This tool allows professors to prepare a set of slides in advance and then annotate them during a lecture. The slides and the annotations are sent out live to all the participants in the session. Using preprepared slides in this way has been found superior to handwriting for classes requiring large amounts of written notes.
The audio tool used in DETA allows only one user to speak at a time. If there is a question at a remote site, it is important that there be someway to signal the host so that the question can be asked. A tool called the Electronic Hand Raiser provides this capability. Remote users have a control panel with a button labeled “Ask Question”. When they click this, the session host will hear a tone and see a message button indicating who the question is from. To acknowledge the question, the host clicks the message, and then allows the remote site to ask their question. There is also a “Cancel Question” button at the remote site if the remote user wishes to withdraw their question. In addition to dealing with the problem of half-duplex audio, this tool provides a form of floor control that matches traditional classroom protocols (See Figure 4). Figure 3 shows a live DETA session with the MBone video, audio and whiteboard tools, as well as the Electronic Hand Raiser and WBDImport tool.
Another feature of DETA is integrated recording and playback of sessions. To record a session, the host checks the record option and the session is automatically recorded on a separate VCR server. To play back a session, the user selects the play session option and then chooses the desired session. Once the session is selected, DETA provides a VCR-style interface (see Figure 4). This interface also allows the user to start the various tools and provides standard VCR controls such as play and rewind. The VCR server itself is a separate Tcl script that DETA communicates with via TCP/IP sockets. The primary function of the server is to start and stop a Java application called mVCR. mVCR was written by Peter Parnes at the Lulea University of Technology in Sweden. It is capable of capturing and playing back multicast data streams for the MBone audio, video and whiteboard tools. The DETA VCR Server and mVCR, in combination with DETA, provide immediate on-demand playback of sessions. As soon as a class session is complete, that session is available for remote playback. This greatly reduces the cost and overhead necessary to provide time-delayed classes to remote sites. Additionally, students who missed a class or wish to review a class can individually replay recorded sessions.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development