Thanks so much this is so great! 'Looped event' explains a lot... Forgive me for newbie questions, I've excitedly adopted Indy Sockets for a whole 3 days now... What you have said means I am on the right track, and very nearly there already. I coded a read method to read the number of sensors get all the data, no matter how big, including the last CRC. The thing is the inverted payloads and payload sizes only refer to the two records/structures in packetized headers, one is only two bytes the other only 5 with most of the variables just one byte, using the structure to decode it seems irrelevant to me.
No, 3315 is not reasonable, the payload bytes are separate bytes with the inverted one being 255 - payloadsize, the other a byte with the size.
I will see about the IOHandler.InputBuffer.Size property, though I have the code written it would seem easier to read the buffer in it's entirety then deal with the byte array.
the AConvert parameter, well that's brilliant! I've read about so many things that would make life really easy for me. Normally we use Records and pointers to records as a 'magic decoder ring' for the buffer, but on dedicated LAN's we use UDP, not TCP and the records are much more complex usually. I had to deal with endian conversion every time because we were dealing with Motorola processors on the other end, but it was years ago.
I'm not actually using the server of this example but receiving from a device.
I have really hit the timing hard, but it's still possible I'm reading the wrong two bytes for the number of sensors, which is the payload that counts. they occur as an array immediately following the second structure.
I was playing with AConvert suspecting that might be an endian swapping deal by setting it to true, maybe I made it Big endian and gave myself the headache... I thought I undid it later, unless it's set to True by default since I never set it explicitly to False. If that is true I can fix it in 10 minutes or less!
I also tried to buy the E-book on Indy, but could not figure out how to pay for and download it.
No, 3315 is not reasonable, the payload bytes are separate bytes with the inverted one being 255 - payloadsize, the other a byte with the size.
I will see about the IOHandler.InputBuffer.Size property, though I have the code written it would seem easier to read the buffer in it's entirety then deal with the byte array.
the AConvert parameter, well that's brilliant! I've read about so many things that would make life really easy for me. Normally we use Records and pointers to records as a 'magic decoder ring' for the buffer, but on dedicated LAN's we use UDP, not TCP and the records are much more complex usually. I had to deal with endian conversion every time because we were dealing with Motorola processors on the other end, but it was years ago.
I'm not actually using the server of this example but receiving from a device.
I have really hit the timing hard, but it's still possible I'm reading the wrong two bytes for the number of sensors, which is the payload that counts. they occur as an array immediately following the second structure.
I was playing with AConvert suspecting that might be an endian swapping deal by setting it to true, maybe I made it Big endian and gave myself the headache... I thought I undid it later, unless it's set to True by default since I never set it explicitly to False. If that is true I can fix it in 10 minutes or less!
I also tried to buy the E-book on Indy, but could not figure out how to pay for and download it.