Re: socket write/read conflict?
On Mar 23, 2010, at 7:50 PM, Nicolas Cueto wrote: A question about something Alex wrote. -- And thank you, Alex. I'll be trying out what you wrote and see what happens. As for logging the results, I'd been doing that already, by having the script put results into a field. Odd thing is, this writing to a field seemed to have solved the simultaneity problem. Which made me think that printing the results caused a few milliseconds of delay that gave the read-write chance to function as expected. But then the problem reappeared. Anyway, to my question. What character should I use when reading/writing over sockets to indicate the end of a line of trasmitted data? CR? LF? Something else completely? Thanks. I use something like: !...@#$% I make sure I append those characters to the end of data to be sent over a socket as well. Best regards, Mark Talluto http://www.canelasoftware.com ___ 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
Re: socket write/read conflict?
On Mar 26, 2010, at 11:59 AM, Mark Talluto wrote: I use something like: !...@#$% I make sure I append those characters to the end of data to be sent over a socket as well. !...@#$% sounds like a swear word to me... (from the old comic book days) -- Peter Peter M. Brigham pmb...@gmail.com http://home.comcast.net/~pmbrig ___ 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
Re: socket write/read conflict?
Found the problem. Alex Tweedly pointed out my use of read from socket was missing an until. So, I added an until LF (rather than the !...@#$% expletive), and, shbam, simultaneity problem gone. Thanks. -- Nicolas Cueto ___ 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
Re: socket write/read conflict?
I stand corrected on the comma. I don't know where I got the idea tab was the default. As to the sockets getting confused, this can't really happen since socket is defined by both the server and client IPs AND server and client port numbers. Unless you've got more than one machine with the same IP, each socket would be unique even if all the clients were talking to the same server on the same port. To take a page from Jerry Daniels (of tRev fame), perhaps you can simplify this by making it a little more complicated. Unless I misread your original post, you want to know who answered first in addition to the actual answer. As each answer comes in, why not just grab the seconds each socket either opens or receives data until all have answered. Then you can see who had the lowest seconds (first response), and then read each answer and check for correctness. This takes the time pressure and allows you to better coordinate the response. len morgan On 3/22/2010 11:10 PM, Nicolas Cueto wrote: Thanks for replying, Len. The 127.0.0.1 ip is indeed just an example, and Rev's default itemdelim is not tab but rather comma. -- Nicolas Cueto ___ 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 ___ 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
Re: socket write/read conflict?
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,1,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 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
Re: socket write/read conflict?
A question about something Alex wrote. -- And thank you, Alex. I'll be trying out what you wrote and see what happens. As for logging the results, I'd been doing that already, by having the script put results into a field. Odd thing is, this writing to a field seemed to have solved the simultaneity problem. Which made me think that printing the results caused a few milliseconds of delay that gave the read-write chance to function as expected. But then the problem reappeared. Anyway, to my question. What character should I use when reading/writing over sockets to indicate the end of a line of trasmitted data? CR? LF? Something else completely? Thanks. -- Nicolas Cueto ___ 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
socket write/read conflict?
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. As always, the list's help in this is greatly appreciated. Thank you. -- Nicolas Cueto ## S T A R T O F C L I E N T S T A C K R E L A T E D CLIENT CARD SCRIPT on opencard chatConnect end open local lChatSocket on chatConnect open socket field host :1987| field clientname with message chatConnected end chatConnect on chatConnected s put s into lChatSocket write field clientname comma field studentID return to socket lChatSocket read from socket s with message chatReceived ## Tell server that the student is ready to play, and then ## wait for student's choice of answer (by clicking on a ## game-controller button). end chatConnected on chatReceived s,data ## s contains the host and port of the client, ## data contains the text sent by that client switch (line 1 of data) case live choice feedback ## A student/client on the network has buzzed in a choice/answer. ## ## The script does a long routine here, which includes ## ## several wait and wait with messages ## ## Once done, the script asks server for next question. askServerForQuestion break end switch read from socket s with message chatReceived end chatReceived on askServerForQuestion chatMessage ready for a question end askServerForQuestion on chatMessage data ## Called by student clicking on an image/choice (script below). write data comma field clientname to socket lChatSocket end chatMessage GAME-CONTROLLER BUTTON IMAGE SCRIPTS on rawKeyUp theKey switch theKey case 49 put ImgChoice1 into tImgChoice break end switch put the filename of image tImage into tHilitedImagePath send choiceBehavior tHilitedImagePath to image tImgChoice end rawKeyUp on choiceBehavior tHilitedImagePath put choice the last char of tImgChoice into tChoice put live choice feedback comma tChoice into tMessage chatMessage tMessage ## Tell server this student's choice. end choiceBehavior E N D O F C L I E N T S T A C K R E L A T E D ## ## S T A R T O F S E R V E R S T A C K R E L A T E D on mouseUp accept connections on port 1987 with message clientConnected ## Wait for all students/clients to connect. end mouseUp on clientConnected s ## A student/client has connected. When all expected clients ## are connected, initiate the game. 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 put line 1 of it into tChatMessage put tChatMessage comma s into gAllClientIPsArray[s] add 1 to field numberOfClientsLoggedOn if field numberOfClientsLoggedOn = field expectedNumberOfClients then put yes into field allLogged initiateGame end if read from socket s with message chatReceived end clientConnected on chatReceived s,data ## Student/client has sent a message. ## Perhaps it's a choice/answer ... put item 1 of data into tChatType switch tChatType case live choice feedback choice4AndTheBuzzState data break end switch read from socket s with message chatReceived end chatReceived on choice4AndTheBuzzState theChoice put item 2 of theChoice into tKey if gChoiceFeedbackTally[tKey] = 4 then ## Lock the buzzers, i.e., prevent clients ## from sending server their
Re: socket write/read conflict?
Two things jumped out at me in your code: 1) broadcastToAllClients - you show an IP address of 127.0.0.1. If this was not just an example, you can't use that number. That is the IP of the local host and won't actually ever leave the machine. 2) You are selecting item 3 of tArrayDataLine which I assume is comma delimited (based on the example line above it). I don't set a setItemDelimiter to comma in that handler and I /think /the default delimiter is tab. I also believe that the itemDelimiter you set is only valid for the current handler so as soon as this handler is finished, it will revert back to tab. Hope that helps a little. len On 3/22/2010 10:14 PM, 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. As always, the list's help in this is greatly appreciated. Thank you. -- Nicolas Cueto ___ 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
Re: socket write/read conflict?
Thanks for replying, Len. The 127.0.0.1 ip is indeed just an example, and Rev's default itemdelim is not tab but rather comma. -- Nicolas Cueto ___ 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
socket write/read conflict?
Nicolas Cueto I'm a fifth grade teacher. I'd love to see what you got. Max ___ 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
