Or you could send a timestamp along with the message.
If you are going to "beep" do it immediately after recv'g the first message, but wait a few msecs to retrieve additional messages before deciding who was first. Whenever you get one and there is already one pending, check the timestamps, and retain the earlier one.
This only works, of course, if the computers' clocks are in sync. You should run some kind of network time sync on the computers in the school's lab just to be safe (I know there are free ones avail. for Windows and Linux/UNIX; OS X has one built-in, and I think OS 9 does as well...).
On Dec 1, 2004, at 7:52 PM, Alex Tweedly wrote:
At 07:47 02/12/2004 +0900, kweto wrote:
Hello again All,
I've begun learning and putting into effect everyone's kind advise about
linking stacks thru sockets. Especially useful were the chat stacks. I think
I have a strong sense now of how to make it all work. Thank you to all!
Now, a related-but-OT question. If messages from several computers/stacks
are sent out "simultaneously" to the one computer/stack which is intended
for accepting messages, in what order are those in-coming messages likely to
be handled? Of course, computers are fast so maybe there's nothing to worry
about, but a group of young learners can surprise teachers in unpredicted
ways, especially if they're clicking madly on the "I know the answer!"
buzzer-like button of the LAN-based, interconnected stacks I'm now planning.
I'm worried/scared that, even though given things being equal (such as
computer make and operating system), either the central stack itself or
perhaps even the router might re-shuffle "simultaneous" messages in some
sort of order other than a real-time one, and thus one learner will seem to
be winning all the time.
As Marl says, not a technical problem. Though it is a good reminder to think about the potential load that a number of over-eager students might impose on a central server. Probably also not a big issue, given how fast computers are these days.
Nevertheless, I'd be inclined to treat this as an "educational opportunity".
1. Ensure that there is very clear visual feedback when a click has been detected (and the message sent ....)
2. Tell the pupils that there is no benefit to be gained from pressing the same button repeatedly.
(Of course, they've been telling us that for years about elevator call buttons, or pedestrian crosswalk buttons, and it's not stopped all those people you see pressing the same button over and over :-)
so, consider also,
3. Let it "leak out" that there might be a penalty for repeatedly pressing the same button.
Hmmmm, in fact - why not impose a minor penalty for frantically pressing the same button; indicates that someone is unwilling, or unable, to follow instructions.
Of course, you could simply disable the button after the first message has been sent, until the teacher has asked the next question or reset the test, or .... but seeing who won't listen when told there is no point in doing something appeals to my sense of fun much more.
-- Alex. _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
----------------------------------------------------------- Frank D. Engel, Jr. <[EMAIL PROTECTED]>
$ ln -s /usr/share/kjvbible /usr/manual
$ true | cat /usr/manual | grep "John 3:16"
John 3:16 For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.
$
___________________________________________________________ $0 Web Hosting with up to 120MB web space, 1000 MB Transfer 10 Personalized POP and Web E-mail Accounts, and much more. Signup at www.doteasy.com
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
