Nicolas Cueto wrote:
Hello List,
I've made a quiz-type game where 2-6 students on client stacks buzz in
their answers to a server stack, all on a local network. The server
stack, as well as sending out the questions, informs live to all the
students/client-stacks about who buzzed in what.
I thought I had it working until we found a problem. If two out of six
students happen to buzz in an answer almost simultaneously (by
clicking a button on a game controller pad), as expected five of the
students will receive the server's message about who buzzed in first,
but one of those two students who buzzed at the same time won't.
Except for this simultaneity, all other server-to-client
communications work.
After trying to track this down for weeks, I'm posting here in hopes
of some list magic.
My guess, as the subject line reads, is that a client stack might be
writing to a socket at the same time that the server is trying to
write to that same socket. But, not understanding well how sockets
work, the problem may lie elsewhere. I think I've eliminated the
obvious types of mistakes, but...
So, I am including below the essence of what my server and script
stacks do. It is quite long, so apologies beforehand.
I'm afraid I can't see anything that looks like it could cause your
problem. What I'd do if it were me is :
1. add a logging capability to the 'chatreceived' handler
on chatReceived s,data
if gLoggingFile then
put the millisecs && s && data &CR after URL gLoggingFile
end if
## Student/client has sent a message.
## Perhaps it's a choice/answer ...
2. add a similar log/debug to broadcastToAllClients
3. see what you find out :-)
Also, a couple of comments - some probably just artefacts of summarizing the
script to send to us.
1. In chatreceived (and clientConnected), you do
read from socket s with message chatReceived
which would only read one character (according to the docs). I guess you
really do a "read until someChar ??
2. In clientConnected, you do
wait 50 milliseconds with messages
## Bug? Without this line, read from socket takes a long time
## and returns empty.
read from socket s for 1 line
I would recommend that you NEVER do a blocking read in a server. I'd
make that something like
read from socket s until CR with message gotClientIdentification
and put the remaining code into gotClientIdentification (or siply add
it to the logic in chatreceived).
And I'm pretty sure you can then remove the "wait 50 msec with messages"
3. In the array gAllClientIPsArray, it seems that the 3rd item of each
entry will always match the key of the array, because of
put tChatMessage & comma & s into gAllClientIPsArray[s]
That just seems like duplicate effort (and a possible source of error /
confusion). Why not leave that out, and just use the key ?
4. If you do #3, then you can simplify
on broadcastToAllClients message
## Tell all the students/clients who made what choice.
put keys(gAllClientIPsArray) into tChatterList
repeat for each line tArrayKey in tChatterList
put gAllClientIPsArray[tArrayKey] into tArrayDataLine
-- the client ID, the student ID, the client IP
-- eg, Blitz-1,10000,127.0.0.1:1448
put item 3 of tArrayDataLine into tSocket
write message to socket tSocket
end repeat
to
on broadcastToAllClients message
## Tell all the students/clients who made what choice.
repeat for each key tSocket in gAllClientIPsArray
write message to socket tSocket
end repeat
end broadcastToAllClients
(Again, this may be due to summarizing, and there may be more to do here
- but even then it would likely be
repeat for each element tArrayDataLine in gAllClientsIPsArray
-- do something to send to this client
)
Hope that helps a little bit. Try the logging / debug code and see what
happens (and let us know if it shows anything and we can help with
analyzing it :-)
-- Alex.
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
