Blocking Action Until Socket Responds

[SirWobbyTheFirst]

Hi everyone, I was wondering how I could make rev wait for an acknowledgement from a socket before continuing, I ask because I'm revisiting an old application which uses a remote login interface and I was wondering how I could get Revolution to pause until a response is received from the server. I cannot use the wait command because that seems to block the entire application.

Any help would be much appreciated. Thank you.

[Mark]

Hi mickpitkin92,

It seems you're doin' it wrong. You shouldn't use a wait command or other methods to halt your script until a socket responds. You need to read from a socket with a message:

Code: Select all

read from socket mySock with message "messageReceived"

The messageReceived message will be accompanied by a few parameters, if I'm not mistaken the correct form is:

Code: Select all

on messageReceived theIP,theMsg
  -- handle the message here
  put theMsg into fld "Message"
  -- write to socket theIP again
  write "got message" to socket theIP
  -- and finally read again
  if theMsg contains "stop" then
    close socket theIP
  else
    read from socket theIP with message "messageReceived"
  end if
end messageReceived

This is just a very basic fictional example but I hope you get the idea.

Best regards,

Mark

[SirWobbyTheFirst]

Ah perfect, I'll keep that in mind. Thank you mark.

[Janschenkel]

There are two ways to use sockets: synchonously and asynchronously. Using the variants 'with message' at the end, means you're working asynchronously: the engine will get back to you later and send that message to your control, along with a few parameters, such as the socket and the data. If you don't use 'with message' at the end, then the engine will sit there and wait until the operation completes.
Handling your communication asynchronously is more complicated, but provides a better user experience, as the interface isn't locked. Obviously, if you go for the asynchronous method, it's your job to prevent the user from doing something wrong - by disabling buttons and menu items, for instance.

Jan Schenkel.

[mwieder]

Here's a twist: I just came up with a need for *both* asynchronous and synchronous socket communication. I've normally got asynchronous reads queued up, but there are some situations where I explicitly want to wait for a packet to come in. Since I'm already waiting for asynchronous reads, that's where my packets go instead of into my synchronous read that eventually ends up timing out. And then, of course, my data has gone out into the asynchronous loop instead.

So has anyone got a good way of dealing with this? I could open a secondary channel on a different socket for the synchonous reads, but I'm trying to get away without doing that. I tried closing the socket, then reopening it, but I get an error 111 on the socket when I do that. And I don't want to kill the asynchronous read permanently because I rely on that for normal communications.

[mwieder]

[Note to self:] Actually mixing the two works fine. What messed me up was thinking that I needed to queue up another asynchronous read after I did the synchronous one. No worries. But do note that queueing a second "read with messages" when you've already got one queued up waiting for messages will result in timeouts and mess with your head.