socket write/read conflict?

[Alex Tweedly]

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.