OpenSockets and multiple stacks...?

[Alex Tweedly]

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

-------------- next part --------------
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