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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Petros Koutoupis' RapidDisk
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- The Italian Army Switches to LibreOffice
- Linux Mint 18
- Oracle vs. Google: Round 2
- The FBI and the Mozilla Foundation Lock Horns over Known Security Hole
- Varnish Software's Varnish Massive Storage Engine
- Firefox 46.0 Released
- Privacy and the New Math
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide