Sending Byte List

[rlebeau]

I've relegated my receive code to the thread onRun event TFClient.IdThreadComponentRun, otherwise I could use it to receive one series at a time, but they prefer firing them at me so I need to receive full buffers of bytes containing strain gauge data in quick intervals. There will be ~175 gauges, currently I'm testing with 11 copies of the same one. If I read 49 bytes at once for my test case it works fine. When I stopped to read the header first last night I found it triggers the onRun event if there is any more data in the buffer, so then I did an experiment reading one byte at a time and displaying it in the TFClient.IdThreadComponentRun onRun event when it fires and sure enough, this will read the entire buffer perfectly.

OnRun is a looped event. As soon as it exits, it is triggered again, over and over, for the lifetime of the thread. It is not dependent on socket I/O.

That's cool and could maybe be the way to go, but if I do that I don't know when it's finished and I can process the data.

That is why you should be reading a full message on each triggering of the OnRun event. Read a full header, read its full payload, process, exit. Repeat.

Any way to really know how many bytes have been received in the IOHandler?

Technically yes (see the IOHandler.InputBuffer.Size property), but that is not the way you should be approaching this situation. Your messages have structure to them. Code for that structure.

When I use SizeOf(RxBuffer) it's always 4

That means your RxBuffer is likely a dynamic array, so it is effectively just a pointer to data stored elsewhere in memory. A pointer has a fixed size (4 bytes when compiling for 32bit).

I'm getting garbage in my Uint16's- this could be an endian issue, I'm not certain yet

Most likely, yes. Most platforms that Delphi supports are little endian systems, but Indy assumes network byte order (big endian) by default, as most network protocols use that endian for cross-platform compatibility. It is a common standard. TIdIOHandler's reading and sending methods for integers have an optional AConvert parameter that is set to True by default, so they perform conversions between network endian and host endian for you.

Since you are sending data between TIdTCPServer and TIdTCPClient, things should "just work" out of the box. Unless you are not using TIdIOHandler's integer sending methods, but are instead receiving data from an external source and just forwarding it as-is. In which case, if the UInt16s are using the same endian as the receiver (check the source's documentation), you can set the AConvert parameter to False when reading the UInt16s.

Can I use the HostToLittleEndian function from Indy?

That function is for sending, not for reading. You would have to use LittleEndianToHost() instead. But that is moot if you use the AConvert parameter of TIdIOHandler.ReadUInt16() instead.

I have endian changing routines but if it's 'already in there' why do that.

Exactly, which is why the AConvert parameter exists.

When I read it by bytes I get $0B in the first byte (lines 10&11 below) which is 11 sensors if I decode just that byte.

Bytes 0B 00 is decimal 11 as a (U)Int16 in little endian.

On lines 2 and 3, you have "Payload length" and "payload size". Assuming those 2 bytes are actually a single (U)Int16, then bytes F3 0C would be decimal 3315 in little endian. Does that look like a reasonable payload size for your messsaging?