Mark Wieder wrote:
Alex-
Tuesday, October 25, 2005, 5:52:12 PM, you wrote:
The other option would be to do it as a peer-to-peer distribution using
local repeaters - an even more interesting protocol design problem, but
probably even less pragmatic a choice :-)
Another way to tackle this would be to have the student stacks
"subscribe" to the instructors stack by opening socket connections.
Then the instructors stack could just push out messages to the
subscribed sockets. This would save you from having to use multicast
packets and give you a finite and known pool of sockets to deal with.
(Although the peer-to-peer approach is most definitely the more
interesting way to go about designing it).
I think that was what I was trying to describe in:
Unless your classroom is larger than say 100 people, and assuming you
can make the instructor's machine be a reasonable performance machine
with a good connection (either wired or very good wifi), then I'd be
tempted to go with the easy solution of opening a TCP socket from each
student to the teacher, and just repeating all data.
peer-to-peer, although interesting, introduces (in this context) a range
of privacy / confidentiality / trust concerns that I am not sure I'd
want to tackle. Direct TCP sockets from each one to the instructor
eliminates the worst of those.
Jonathan's suggestion of a TCP command instructing the students to
refresh a stack from a shared drive sounds like a good way to handle
bulk data transfer to the students. But the CPS system mentioned in the
original question involves a significant amount of input from students
to instructor, so the interesting part of the system is going to be
handling that.
I can easily envisage a library which abstracts the tasks of (all from
the view of the instructor)
- sending a command to every student
- sending command or text to individual student(s)
- soliciting and receiving input from all (or from a subset)
- collating and presenting the received responses (e.g. from multiple
choice questions)
- identifying those who have yet to respond
etc.
If I were John Patten (the original questioner), I'd probably design
that abstraction layer carefully, to allow the option of changing how
the communication happens later. Then code it up the simplest way (each
student opens TCP connection to instructor), comfortable that if the
communication scheme has to change, that will be (at least 95%) hidden
within the abstraction layer.
--
Alex Tweedly http://www.tweedly.net
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.361 / Virus Database: 267.12.5/149 - Release Date: 25/10/2005
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
