Socket reads and handlers
Posted: Fri Dec 18, 2015 2:15 pm
I inherited a clock/timer program (way more complicated than it sounds) written years ago in RunRev3.5 and run as standalone on Mac OSX until this year. We had a few little bumps along the way, but I was able to adjust most everything to get us a good working copy for Win7. The last issue I'm working with (I hope) is the way the program reads data from our control system via a socket. Basically, we have an AMX master controller with a UI where the user can start and stop the timers, flip to different cards for display, and a few other odds and ends. So the RunRev/LC program opens a socket and then just processes data as it is sent. Here's where I need help:
In the old version, the "read from socket" command was called inside a handler that ran once per second. It looked something like this:
Then the "IPReadDone" handler just parses out the data and processes it accordingly.
This all works just fine EXCEPT that reading from the socket can take as long as half a second, even if there is no message to read. This means that every time the read is called I have about a 500ms blocking delay in all other code in my stack. Not good when your stack is a clock/timer!
Just yesterday (I'm a newb, forgive me) I discovered that if I use the callbackMessage argument on the read, it doesn't block! This was BIG news and it seems to have fixed my problem with the "pause" in my timers. But here is what I don't quite understand: I extended the send time on the readFromSocket handler to just run every 3 seconds. In the OLD program (above) this gave anywhere from 0-3 second delay in execution of an operation called from the control system. Makes sense. But now that I changed the read from socket command to add the "with message" at the end, data are received almost instantaneously. So help me understand what is happening. My questions are:
1. It is apparently just processing those messages as they are received, so does that mean I only need to call the "readFromSocket" handler one time? I do leave the socket open all the time. I was under the impression that it was just a "read once" kind of operation, but that is apparently not the case.
2. Do I just call this once, or should I periodically (every few seconds, minutes?) call the read from socket again, just to be sure it didn't quit?
3. What does the sockettimeoutinterval really do? I have it at the default 10 sec, but all it does is send that message every 10 sec. Doesn't seem to actually DO anything. I will also add that in the OLD code, I never got that timeout message, even though the timeout interval was set much lower back then. So I guess when it was waiting for read to complete it could not even pass the timeout message until it was done.
4. Any other "best practices" or things I should watch out for here?
I have another socket question to discuss later, but I won't confuse things here. Thanks in advance!
In the old version, the "read from socket" command was called inside a handler that ran once per second. It looked something like this:
Code: Select all
on readFromSocket IPAddressPort1
if socketStatus1 is "Opened" then
-- read a message from the controlling server
read from socket IPAddressPort1 until EOFString
-- handle message if one received
if it is not empty then
put it into textString
IPReadDone IPAddressPort1, textString
end if
end if
end readFromSocket
This all works just fine EXCEPT that reading from the socket can take as long as half a second, even if there is no message to read. This means that every time the read is called I have about a 500ms blocking delay in all other code in my stack. Not good when your stack is a clock/timer!
Just yesterday (I'm a newb, forgive me) I discovered that if I use the callbackMessage argument on the read, it doesn't block! This was BIG news and it seems to have fixed my problem with the "pause" in my timers. But here is what I don't quite understand: I extended the send time on the readFromSocket handler to just run every 3 seconds. In the OLD program (above) this gave anywhere from 0-3 second delay in execution of an operation called from the control system. Makes sense. But now that I changed the read from socket command to add the "with message" at the end, data are received almost instantaneously. So help me understand what is happening. My questions are:
1. It is apparently just processing those messages as they are received, so does that mean I only need to call the "readFromSocket" handler one time? I do leave the socket open all the time. I was under the impression that it was just a "read once" kind of operation, but that is apparently not the case.
2. Do I just call this once, or should I periodically (every few seconds, minutes?) call the read from socket again, just to be sure it didn't quit?
3. What does the sockettimeoutinterval really do? I have it at the default 10 sec, but all it does is send that message every 10 sec. Doesn't seem to actually DO anything. I will also add that in the OLD code, I never got that timeout message, even though the timeout interval was set much lower back then. So I guess when it was waiting for read to complete it could not even pass the timeout message until it was done.
4. Any other "best practices" or things I should watch out for here?
I have another socket question to discuss later, but I won't confuse things here. Thanks in advance!