OpenSockets and multiple stacks...?

[Alex Tweedly]

Sarah Reichelt wrote:

>>Not sure if this is possible, but I'd like to be able to have a single stack, let's call it the instructors stack, send out a text message to multiple stacks all within a single classroom network all at one time. The "multiple stacks" would be student stacks.
>>
>>
>>I have had a look at some of the sample stacks in the "User Spaces" specifically the work that AlexTweedly has done with his "TCP and UDP" stacks, but have yet to determine if sockets would work in a implementation as i have described. I get the impression that sockets is something that can only occur between two stacks, not between one and many, or many to many.
>>
>>Or, do sockets allow you to open multiple sockets in order to facilitate mutliple connections to a single server stack?
>>
>>What I would like to get to is a Revolution based system similar to a classroom performance system (http://www.pearsonncs.com/cps/) but utilizing laptops and the improved capabilities of Revolution.
>>
>>    
>>
>
>I can't remember the exact details, but I seem to recall that you can
>broadcast a message over a UDP port by using IP address
>255.255.255.255
>
>Choose a certain port number (50000 in my examples) and on the
>instructor's computer open a socket to that port:
>  open socket to "255.255.255.255:50000"
>Send data out that port:
>  write "Hello there" to socket "255.255.255.255:50000"
>
>Have the student computers listen on that port number:
>  accept datagram connections on port 50000 with message doMessage
>
>The doMessage handler can get the received data and process it.
>
>Dar Scott had a UDP stack that demonstrated this better than I can explain it.
>  
>
Sarah's right - that is indeed one option. I'd be very wary of it, 
though. It will work fine in development and testing - but could fail in 
real deployments. It has two potential problems - at the opposite ends 
of the spectrum.

1. IP Broadcast packets are not forwarded by a router; so if the 
classroom network is internally routed, this will fail. Generally, I 
wouldn't expect this - but it's certainly possible, maybe even likely in 
some scenarios such as classrooms with a mix of wired desktops and 
wireless laptops - the wifi network may be allocated from a separate 
address space and routed within the campus.

2. IP Broadcasts are forwarded everywhere within the subnet; so if you 
have multiple classrooms on the campus, and they are not each a separate 
routed subnet, then you have a collision problem. You'd need to add 
program logic to ensure that the different instructors only pick up 
their own students, and only talk to their own students.  You also have 
the problem of all this broadcast traffic clogging up the network - 
modern campuses are typically switched networks to localize traffic, and 
broadcasts which go everywhere can destroy the localization.

So I'd (slightly regretfully) recommend using normal unicast (single 
machine to single machine) IP communication.


You also have the choice between UDP and TCP. While it is tempting to 
use UDP, I think this system needs a reliable form of communication so 
you can be sure the instructor receives all the info sent (and the 
students all receive what the instructor sends). Doing that in UDP for a 
multi-user system is certainly doable - but it's a fair amount of work 
to do it well, especially if you sometimes need to send large amounts of 
data.  Unless you get pretty clever, you'll need a response from each 
student to say that data has been received, with time-outs, repeated 
data (which all the others must ignore), etc.

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.


It irks me to say that (I spent 5 years designing multicast protocols so 
this kind of problem could be solved more easily), but for the moment, 
given lack of multicast support in Rev and on most campuses, that is the 
pragmatic suggestion.

But if you'd like to tackle the other approach using UDP and either 
broadcast or repeated unicast packets, I'd be very willing to help.

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 :-)



-- 
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/148 - Release Date: 25/10/2005