Vragen
0
Beantwoord
Truncated response from a TCP connection
Dan 5 jaar geleden
in Tips and Tricks
•
bijgewerkt door Vladimir Ovchinnikov (expert) 5 jaar geleden •
10
I'm writing a script to control a Sony Projector via TCP.
I have created the device using IR.CreateDevice, and have properly defined the IP & port (the connection is established).
When sending a simple status command (`02, 0a, 53, 4f, 4e, 59, 01, 00, 11, 00`) via driver.Send(msg), the expected response would be `02, 0a, 53, 4f, 4e, 59, 00, 00, 11, 02, 01, 80`, whereas I only see `02, 0a, 53, 4f, 4e, 59` (i.e. everything after the first null character was truncated).
Using a separate TCP client app (Hercules) sees the correct response.
Is there a way to force the EVENT_RECEIVE_TEXT listener I am using to keep listening following a null character received?
Thanks,
Dan
Customer support service by UserEcho
Hello.
You can use the AddEndOfString method in EVENT_RECEIVE_TEXT to define a string that will be the end of the message.
Hi Vladimir,
Thanks for your reply - the AddEndOfString method seems useful, but unfortunately with the protocol
I’m using there isn’t any defined end of string character. The final byte of the message could either represent the end of the ‘data’ section or an error message, so is unknown to me in advance.
I do know that there will always be at least 10 characters received, with the 10th character representing the length of the data in the following bytes (0-128 bytes).
If you know the length of the resulting string in advance, you can save the resulting strings to variables and then concatenate. For example, in JS you count 10 characters - this is the resulting string. If the length is unknown and there is no end-of-line character, then collect all in one piece, if there is no new data more than a certain period. For example, there is no data for more than 4 seconds. So you run the risk of stability, if you constantly receive data, because you can exhaust all available memory.
This was my first thought, however I only receive data once - the '11, 02, 01, 80' that I would also expect to receive in my example above if this was the case is not seen.
Then estimate the size of the received data and if memory allows, just collect the data in one piece.
I see - thanks for your help, Vladimir
Hello, is your problem still unresolved?
Yes, the problem is resolved, thanks! I simply needed to be using the EVENT_RECEIVE_DATA listener instead to allow for 0x00 characters
Happy to help.