IP Socket Device

[incoronado]

This is the first time I've used the IP Socket Device. The Device I am using terminates the message with a <CR><LF>. The issue I am having is that it is saving the message in multiple Data Received messages. Is there a way to increase the timeout so the entire message can be read from the Data Received or specify the terminating character(s) on receive. I know I can specify the termination character(s) on send.

[incoronado]

Here is an Example...

[Russound IP.Received Data] has changed to [N S[2].albumName="Achtung Baby"N S[2].artistName="U2"N S[2].coverArtURL="http://www.siriusxm.com/albumart/Live/1430/u2_5833F]

[Russound IP.Received Data] has changed to [F42_m.jpg"N S[2].songName="Mysterious Ways"]

This is supposed to be one message terminated by vbCRLF. There is no easy way for me to know programatically if the message is complete or not. It seems like there is a timeout terminating before complete. Also I Don't see any vbCRLF. IP Socket Device Plugin must be stripping that off.

Any Ideas are appreciated.

[ScottBot]

There's no timeout setting for the Device. I would think they would send the CR/LF along with the rest of the data (not flush the data and then later flush the CR/LF).

I don't know if it will help diagnose the issue, but you can enable tracing for the Device. That might show what is happening to the CR/LF.

[incoronado]

Is there a size limit on the buffer? I didn't check "received data" property to see if there was anything strange about it. Also, I didn't restart HB after adding the device. Putty handles this like I would expect (the entire string on one line) so I don't think is something in the IP stack.

[incoronado]

OK. I've done some more extensive troubleshooting.

I have captured IP data packet with Wireshark and exported just the data inside the packet. I pasted the exported packet data in notepad ++ and I have attached a screenshot to display EOL symbols. This is one entire Packet. It appears HB is stripping off the CRLF obscuring it from use in programming logic. I have even parsed the data with InStr(ReceivedData, vbCRLF) thinking the characters might not be visible in the logs. They are not in the "Received Data"

Capture.PNG (4.04 KiB) Viewed 10300 times

As you can see below Housebot received one TCP packet into two separate "Received Data" transactions. It looks like it is fragmenting the packet into multiple writes to "Received Data" when the packet is long/large. It seems to work properly with shorter packet payloads. Because it is also stripping off the <CR><LF>, parsing the data is significantly more difficult. I need a way to frame the message by either detecting a termination character(s) or assume the entire packet has been written into one write to "Received Data"

Log data:

[Russound IP.Received Data] has changed to [N S[2].albumName=""N S[2].artistName="SiriusXM"N S[2].coverArtURL="http://www.siriusxm.com/albumart/Live/D ... DefaultMDS_]

[Russound IP.Received Data] has changed to [m_27.jpg"N S[2].songName="Deep Tracks"]

[ScottBot]

The buffer size is 128 bytes. So longer strings will get broken into multiple PV changes. I can increase that if you have longer data streams that are causing a problem (your examples weren't too long).

I see nowhere in the code where the CRLF gets stripped, but I haven't tested it. And it doesn't appear that there's much tracing to help out. I can add some debug messages to dump the data received, if you think that will help.

[incoronado]

OK. That explains what I 'm seing. 128 bytes is really small. What are the downsides to making that larger? Can't imagine that most TCP messaging implementations wouldn't overrun that. Most operating systems have a 256K limit. If I can Read CRLF this won't be a problem. I'll research that more. I need a way to detect when a TCP message is broken up into multiple messages so I can reassemble into a complete message. I don't want to get into a situation where I always have to wait for the next message to validate that the message is complete.

[ScottBot]

...What are the downsides to making that larger?

None really, other than the plugin requiring a little more memory to run. I wrote that plugin for myself a long time ago for a specific purpose that was only dealing with very small data control packets.

I've attached a new plugin that you can unzip and copy to the HouseBot\Plugins\Devices directory (be sure to restart HouseBot). It uses a 1k buffer. See if that behaves better.

[incoronado]

That worked!!! I also checked for the CRLF and I did find my problem. CRLFs are indeed showing up in the message. As usual you have delivered. Thank you!