Messages are read twice from socket

[StUl]

Hi everyone,

I have a bit of a strange problem and I first have to say that I am not 100 % sure if it is runRev related at all. But anyway, here is what I'm doing:

I have a socket connection with runRev as the server and an application written in C++ as the client, using my own protocol. Everything works fine except that if runRev receives a specific message (let's call it "theEvilMessage"), the message is read twice from the socket, either appended in one message or sequencially. The code I use to read from the socket is

Code: Select all

on gotSocketData pSocket, pData
   split pData using tab
   switch pData[1]
      case "theEvilMessage"
         -- do something unrelated
         break
   end switch
   read from socket sSocket with message "gotSocketData"
end gotSocketData

The messages contain parameters separated by tabs, hence the split.

As far as I can tell, the C++ application only sends the message once. At least the write method of the qt 4.5 TcpSocket class is only called once, that I am sure of.

My question is: Has anyone experienced similar phenomena? Does anybody know what my problem is?

I hope someone can help. If you need further information, I will be happy to provide it.

Thanks in advance,
Stefan

[bangkok]

You should perhaps put another message.

Code: Select all

on gotSocketData pSocket, pData
   split pData using tab
   switch pData[1]
      case "theEvilMessage"
         -- do something unrelated
         break
   end switch
   read from socket sSocket with message "gotSocketDataDone"
wait for messages
end gotSocketData

on gotSocketDataDone theIP, theMessage
--do something
close socket theIP
end gotSocketDataDone

And I would add
wait for messages
after the read from socket

[StUl]

Thanks for your reply. I tried adding the wait for messages and it improved things but sometimes the message is still read twice.

I cannot close the socket because I have to check continuesly for new messages which have to be handled. Any other opinions on this topic?

[bangkok]

Thanks for your reply. I tried adding the wait for messages and it improved things but sometimes the message is still read twice.

I cannot close the socket because I have to check continuesly for new messages which have to be handled. Any other opinions on this topic?

Okay. But have you tried to "differentiate" the message.

Because right now, it seems to me that the script that reads the socket is called twice (one time before reading, and one time after reading). that could explain the problem, no ?

[StUl]

I'm not sure what you mean by differentiate. I don't see why the script would be called twice as the message is supposed to be erased from the socket after reading. Or maybe that assumption is the reason why I do have such problems indentifying the cause of this.

Anyway, as I understand the read from socket with message command is that it only sends the message if new data is received at the socket, right? So there would be no reason for the handler to be called twice with the same data.

[bangkok]

Anyway, as I understand the read from socket with message command is that it only sends the message if new data is received at the socket, right? So there would be no reason for the handler to be called twice with the same data.

It seems logical... On the other hand, there is no point to give the same message name for 2 different actions, right ?

You should try my solution : one message to be fired when data arrive, and another message once the reading is done.

I'm not positive it would solve your problem. But before I've encountered this issue of reading the same data, several times.

With the structure I describe, it solved this issue (plus the "wait for message", after the read socket command).

[StUl]

You should try my solution : one message to be fired when data arrive, and another message once the reading is done.

I'm not positive it would solve your problem. But before I've encountered this issue of reading the same data, several times.

With the structure I describe, it solved this issue (plus the "wait for message", after the read socket command).

I don't see how to apply you're structure to my programm. Maybe I haven't described accurately enough what my handler does. Once a messages from the read from socket command is emitted, the handler checks the message type by spliting it at the tab chars. There are several message types and the swich statement has several case statemets. The messages have arguments which are appanded to the messages all separated by tabs. And I am processing the arguments so that it is harmful if two identical messages arrive.
There is no order in which the messages can arrive, this is totally random. So I have to be able to handle each message type after receiving the message. That's why I call the same handler again and again. And as I understand your suggestion, I would have to create a second handler which does excatly the same es the first one which doesn't make sense to me. But I tried it anyway (who kows, right? ) but it didn't change anything.

I am totally clueless and I guess I just have to live with it and find a workaround. I still don't understand how the same message can be read twice from the socket. Or maybe this behavior is caused by the underlying socket implementation rather than runRev, although I doubt that.

[bangkok]

Here is a script that should work. Sorry, my english is not really good, it's difficult sometimes to explain.

Code: Select all

on mouseUp
   open socket to "192.9.202.108:8192" with message "gotSocketData" --or "127.0.0.1:8192" for local machine
end mouseUp

on gotSocketData pSocket
   read from socket pSocket  until "#" with message "processData"
   wait for messages
end gotSocketData 

on processData pSocket, pData
   split pData using tab
   switch pData[1]
      case "theEvilMessage"
         -- do something unrelated
         break
   end switch
end processData 

WATCHOUT : it's important to put all this script within the same object (here for instance, a button).

This is what I called a structure with 2 different call back message.

To summarize the idea :

-you open the socket
-a callback message is fired, once the connexion is made
-then read the data until a special character is read (here : "#")
-then when read is completed (condition of the until "#" is being met), a second message is fired
-the second call back message allow you to process the data that have been received

[StUl]

-you open the socket
-a callback message is fired, once the connexion is made
-then read the data until a special character is read (here : "#")
-then when read is completed (condition of the until "#" is being met), a second message is fired
-the second call back message allow you to process the data that have been received

That's basically what I did. I should have mentioned that there is another call of the read from socket command in another handler which sends the first gotSocketData message after reading. So the gotSocketData is only sent aver reading, not after the socket is opened. The only difference is that you read with a character to stop at and I don't. I already tried this whiout any success.

But getting back to your example: how would you implement furher read operations on the socket without clicking the button again?

PS: I'm not a native either, so no worries .

[bangkok]

Okay. So you use RunRev as a server, right ?

So why not do something like this :

--within the same button

Code: Select all

on mouseUp
   accept connections on 8192 with message "incoming"
end mouseUp

on incoming theIP
   read from socket theIP until return with message "gotSocketData"
end incoming

on gotSocketData pSocket, pData
   split pData using tab
   switch pData[1]
      case "theEvilMessage"
         -- do something unrelated
         break
   end switch
end gotSocketData

With this solution, the server is listening continuously and is able to process the incoming data each time, but it still requires a special char at the end of the string that has been sent (by your C+ client).

[StUl]

If I understand the accept command right, it opens a new socket. The way I use sockets is to keep them open until the application is finished and not opening an new one for each message to be sent. But your code seems to do that, right?

Although I already tried this before, I added "until return" to my read command, thinking I might have missed something the last time. At this really did the trick . I don't know what I did wront the last time I tried this. So my solution now is like this (applyied to your button script):

Code: Select all

on mouseUp
    accept connections on 8192 with message "incoming"
end mouseUp

on incoming theIP
   read from socket theIP until return with message "gotSocketData"
end incoming

on gotSocketData pSocket, pData
   split pData using tab
   switch pData[1]
      case "theEvilMessage"
         -- do something unrelated
         break
   end switch
   read from socket theIP until return with message "gotSocketData"
end gotSocketData

This way I don't need to open a new socket for each message.

Thanks for your suggestions, you were a big help .

[bangkok]

If I understand the accept command right, it opens a new socket. The way I use sockets is to keep them open until the application is finished and not opening an new one for each message to be sent. But your code seems to do that, right?

It doesn't open a new socket. It opens "the" socket, if I may say, on the server side (your runrev app). This socket remains open, until you close it (when you quit the app for instance)

And it's your client (C+) that will create the connexion, and then close the socket (after receiving an answer, or a confirmation after the processing, from the server).

I insist : there is no need to put a second :
read from socket theIP until return with message "gotSocketData"
within the gotSocketData handler.

You'll find enclosed 2 stacks : server and client. With your handler. That's the best solution to help you.