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
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
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
