Transcript Classroom Presenter: Multicasting

Classroom Presenter:
Multicasting
Michael Mayes
Brian Temple
University of Washington’s
Involvement
 Initial development began at Microsoft
Research in 2001
 Continuing development at the University
of Washington
 Classroom Presenter 3
 Release Target: April 2007
Classroom Presenter
 Distributed, Tablet
PC Application
 Presentation features
 Instructor notes on
slides delivered to
students
 Slide minimization
 Student submissions
to teacher
 UI Designed for use
during presentation
on tablet
 Simple application
 Ink Overlay on
images
 Export PPT to image
 Real time ink
broadcast
Reasons why Classroom
Presenter is better than
PowerPoint
 Simple pen based
UI
 Instructor Appends
Notes to Slides
 Slide previews
 Lecture export to
HTML
 Extra writing space
 Distributed
Presentation
 Full screen erase
 Default Inking
Needs Analysis
 Real-time Voting and Questionnaires
 Save and review slides without
purchasing Microsoft PowerPoint
 Students can display understanding
without being singled out in large lecture
halls
 Allows shy and quiet students to remain
anonymous from other students
Market Analysis
 Ideal for Lecture Halls and Businesses
 Real-time Feedback
 Integrate client work into the public
discussion
 Better than some other classroom
response systems
 Allows for real-time worldwide
presentations
Multicast
 Broadcasts content to all participants at once instead
of a TCP/IP connection to each participant
 UDP connection
 No ACKs to guarantee content was received
 Useful for real-time media such as video conferencing and
multiplayer games
Literature Survey
Classroom Collaboration
 Learning becomes more enjoyable
 Bridge gap between local and remote users
 Providing both asynchronous and synchronous
resources
 Email mailing lists
 Websites with downloadable content
 Interactive media proven more effective than
passive media
 Learning is enforced and enhanced through feedback
Literature Survery
 Wireless Multicast Issues
 QoS (Quality of Service)
 Dense and Sparse mode protocols
 Multicast forwarding algorithm
 Multicast Reliability
 Must be able to detect transmission errors and
correct them efficiently
 Wireless networking is prone to interference and
weak signals
 Implementing an acceptable error correcting
protocol
Goals and Objectives
 Increase wireless network performance for
over 20 participants
 Multicast is required to effective be able to
implement Classroom Presenter in a Lecture Hall
 Do so without degrading teacher workstation
performance
 Students can write notes and questions on
future and past slides for the instructor to
clarify
System Diagram
Overall Approach
 Determine if current multicast
implementation should be improved or
scratched
 Development in C#
 Research the method for reliability in
place for multicast
 Improve this method to allow for
increased amount of users
Overall Approach
 Negative-acknowledge (NACK)-Oriented Reliable Multicast
(NORM) Protocol
 Selective, negative acknowledgment for reliability
 IETF (Internet Engineering Task Force)
 Reliable Multicast Transport (RMT)
 Designed to provide end-to-end reliable transport over generic
IP multicast routing and forwarding services
 NORM uses a congestion control scheme to manage
bandwidth
 Offers various ways to allow different applications or higher
level transport protocols to utilize its service in different ways.
 Testing
 Small tests performed between 2 laptops with Linksys access
point
 Use of IT Lab for large tests
Gantt Chart
Remaining
Completed
Conclusion
Performance Testing
Implementation
Intial Testing
Research
Gathering Background
Information
ay
M
y,
da
,
14
07
20
7
00
,2
30
il
pr
7
00
,2
16
il
pr
,
19
07
20
07
20
7
00
7
00
7
00
,2
08
7
00
,2
22
,2
05
,2
19
,
05
y
ar
y
ar
y
ar
ru
eb
y
ar
ru
eb
h
h
7
00
,2
02
il
pr
F
y,
da
c
ar
M
y,
da
c
ar
M
y,
da
A
y,
da
A
y,
da
A
y,
da
on
M
on
M
on
M
on
M
on
M
on
M
on
M
F
y,
da
nu
Ja
y,
da
nu
Ja
y,
da
on
M
on
M
on
M
System Requirements
 Operating Environment
 Microsoft Windows based application
 Could be expanded to other Operating Systems
in the future
 Microsoft Visual Studio .NET
 PCs with wireless network adaptors
 Wireless router
System Requirements
 Market Users
 Large demand for applications such as Classroom
Presenter from Universities and Businesses
 MU’s University Physics courses currently use the “clicker”
to collect feedback
 Classroom Presenter is currently open source and
free to download and use
 Allows students to view PowerPoint slides without
purchasing Microsoft PowerPoint
 Every student must have a laptop
 Only financial burden
 Some colleges require students to buy a laptop
 MU’s School of Journalism
System Requirements
 Environmental Constraints
 No learning curve for typical college student
 Established reliable wireless network
 System Components
 Real-time protocol (RTP)
 Reliability
 Ink
 Real-time drawings and slide editing
Requirement Analysis
 Performance requirements
 Real-time data should have a delay of no more than
10 seconds
 Current multicast delay is 3-5 minutes
 Resource Requirements
 IT Lab and wireless network
 Classroom Presenter’s up-to-date source code
 Evaluation metrics
 Ink delay
 Instructor’s system load
 Bandwidth utilization
Risk/Profit Analysis
 The set up for a lab could be pricey (~$22,000)
 20 Tablet PCs at around $1000
 Wireless Access Point $300
 Projector $1500
 Additional Development would be necessary to the product before
it is entirely marketable. (~$20,000+)
 $50 an hour is a liberal estimate if open source moved to marketed
business plan.
 At its current state it would require significant man hours to improve.
Over 400.
 If just used in 1/8 of US Colleges and Universities (4,216), each
with a small lab (20 stations), and marketed at $100 a license, the
revenue would be near 1 million.
 Not including use in business.
Classroom Presenter
For more information or to download CP3:
www.cs.washington.edu/education/dl/presenter
www.cs.washington.edu/education/courses/cse421/06au