TCPClient problem SOLVED

Hi, I am having some strange behaviour with the TCP client ()SX 10.9 OF 0.8.3)

I am sending messages to a hardware device, it works perfectly with telnet. It seems like something is not being flushed in the tcpClient.sendMessage() method

I can send a command once in my app with ofxTcpClient for example

tcpClient.send("play\r\n");

The device responds with its ack.

When I send the same command a second time the device responds with a syntax error message even though the command is identical and I am still connected to the server.

However if I use this code.

               tcpClient.setup("192.168.1.50", 9993);
               tcpClient.send("play\r\n");
               tcpClient.close();

I can send the messages correctly and I get the correct ack from the unit and repeat this as many times as I like. But as I want to send a lot of commands and timing is critical closing and opening the connection is not a good solution (it takes time and if I try make the connection again too soon I just get error messages.

Fred

the problem is that tcp being a stream oriented protocol, needs some kind of delimiter to be able to distiinguish where each message ends. in the case of the device you are using that delimiter seems to be “\r\n” but openframeworks by default uses it’s own delimiter “[/TCP]\0”. You can change the delimiter using:

tcpClient.setMessageDelimiter("\r\n")

and then send your messages as

tcpClient.send("play");

another options is to just use:

tcpClient.sendRaw("play\r\n");

which sends the message without the additional delimiter. the advantage of using setMessageDelimiter is that when you receive an answer if the device also uses “\r\n” to delimit them you can just use tcpClient.receive() and you’ll get the full message, otherwise you’ll need to check for the delimiter yourself and keep calling receiveRaw() until you receive the whole message

For some reason, setting the delimiter did not work but

tcpClient.sendRaw("play");
tcpClient.sendRaw("\r\n");

worked fine, I assume it is a quirk of the hardware, but I am curious that it worked fine in telnet.