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.
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
|Android's Limits||Jun 04, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Introduction to MapReduce with Hadoop on Linux
- Senior Perl Developer
- Technical Support Rep
- Weechat, Irssi's Little Brother
- UX Designer
- One Tail Just Isn't Enough
- Android's Limits
- Reply to comment | Linux Journal
22 min 26 sec ago
- Reply to comment | Linux Journal
22 min 53 sec ago
- Replica Watches
2 hours 47 min ago
- Reply to comment | Linux Journal
6 hours 58 min ago
- on the path to understanding
7 hours 2 min ago
- As a fisher,we know that a
1 day 2 hours ago
- All I Say Is Worth Share!
1 day 3 hours ago
1 day 3 hours ago
1 day 7 hours ago
- You should consider visiting
1 day 8 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?