Socket reads and handlers

[studawg66]

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:

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

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!

[lilRalph]

G'Day Studawg66,

There are people in this forum who know far more than I about socket management with LiveCode but my understanding is that by using the callback you have changed the code to event driven.

What this really means is that you no longer need to do the looping polling that the old code had to do as the socket will trigger the event when there is data in the buffer.
This is similar to the way I manage the interaction with web pages as the internet is so variable that timing and loop polling just take way too long and regularly time out.

I would leave the socket open, assuming that you do have a relatively constant data stream appearing at the socket port. You should have a timeout function for the socket if you need it to shut down due to inactivity but otherwise I wouldn't bother.

We are all newbies here and everywhere else in one way or another. There is so many different ways to use any language that no-one person knows it all except perhaps the developers.

For an excellent source of accurate info about sockets try this https://beej.us/guide/bgnet/ it is a bit language specific but the info is excellent and I have used it on more than one occasion in other languages.

[studawg66]

Thanks, Ralph.
I believe you are right, based on the behavior I'm seeing. This is actually really encouraging and I will be able to rewrite my code to run more efficiently. Rather than running the "read from socket" every x seconds, I can just run it once inside my "open socket" routine. That will tidy up things considerably.
And thanks for that about the sockettimeoutinterval. I don't think there is much use for it either. What I will probably do is just keep it at 10 seconds and have the socketTimeout handler just send a status message to a field that says something like "socket heartbeat" as opposed to "timeout." That way I can have a timestamped message for debug purposes just confirming that the socket is still reading messages.
By design, our control system needs these sockets to stay open all the time, so the socket will stay open. The only time it closes is on network outages or equipment failure/reboots. For this reason, I have another routine that checks the status of the socket every so many seconds and if it is closed it reopens it. Now that we've sorted out the behavior of the socket read, this reset handler will be the only routine that I will have to loop through using the "send to me in x seconds" call.