stacks interacting over LAN? (newbie)

[Frank D. Engel, Jr.]

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
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
-----------------------------------------------------------
Frank D. Engel, Jr.  <fde101 at fjrhome.net>

$ 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