Robert Klemme wrote: > 2009/10/29 Matt Brooks <mattbrooks / gatech.edu>: > >> Hopefully that makes sense, It is a little complicated which is why >> initially I didn't go into why I have a buffer and all... > > Um, I have to say I'm a bit stumped. First of all, from your > explanation it is not clear to me about which of the two (?) processes > we are talking. It's easier (at least for me) if you use variables, > e.g. "I have a process A which opens a server socket. Process B > connects to A with 1 connection ... Process B is the one I implement > in Ruby and...". > >> Ideas on how to prevent my false positive situation when using line[cmd] >> way? > > Maybe. A few things strike me as odd: > > - Several different threads seem to be reading from the same > connection. Not sure whether that's a good idea because that makes > synchronization necessary. > > - Since several threads seem to be reading from the socket, any thread > may read another thread's answer which is why you need the buffer. > > - No need to reach character by character until \n, you can use #each > or #gets for that which should be significantly faster. > > I would start by only having one thread writing to the socket and one > thread reading from it. The writer reads messages from a queue where > they are placed by worker threads. How we connect the reader with the > worker threads so that each worker thread gets it's reply depends on > things that aren't clear to me yet. > > Kind regards > > robert I tried each, gets, and readline, none of which returned anything... weird huh. It just sits there forever. Im still thinking about it... You seem to understand the situation so that is good, none the less for others.... to clarify on threads... a redo... with A and B I can't simply send the message and wait for it to return, because I have multiple threads, A and B, sending different messages at the same time, therefore, the order in which response messages return is unknown, so they just go into an array of size 600, one message per index. Each message is terminated with a newline, \n. The order of operations it usually psuedo code, SEND(CHLE,23,4) GETMESSAGE(CHLE,23). Because, CHLE,23 is all I am certain that will return for that message, so i look for that. Therefore this pseudo GETMESSAGE function reads from the tcp port I opened up earlier, 1 character at a time, loading each into a temp string, until a \n is seen, then it loads that string into the buffer[0] spot, then checks if it happens to match the message I was waiting for anyway, sometimes it does, in that case it returns that message.(Perfect scenario, done, move on to sending next message...) Other times it does not match, like when THREAD B sent a different message and it was THREAD B's return message, therefore it is just thrown in the buffer, so later it can be found by THREAD B. And Immediately I, THREAD A, search the whole buffer for a match to my message I am looking for(what if the response was actually already in the buffer from the THREAD B writing it previously into the buffer), so i look through the buffer using the line[cmd] way. If it does NOT find it, I go back to reading one char at a time until a \n is seen. If it does find it, it returns it(like the perfect scenario earlier). Since after all the above happens, Then presumably the THREAD B gets its chance to find THREAD B's return message, it reads till a \n, throws it in buffer, checks if matches, if it does awesome good timing, and would be done. However, usually not a match right away so then looks through buffer, because chances are THREAD A wrote it in the buffer already while it was looking for THREAD A's specific response message. This all works perfectly, except from time to time I get a false positive on a match when using line[cmd]. When for example I am looking for specifically "CHLE,23" and "CHLE,231" actually is returned. I want CHLE,23,3,2,3,4,5,3,2 to say YES a match if I was looking for "CHLE,23" but if CHLE,231,3,2,3,4,5,3,2 is returned and I was looking for "CHLE,23" I want it to say NO not a match. -- Posted via http://www.ruby-forum.com/.