On 2025-02-21 16:25, Bob Sneidar via use-livecode wrote:
Yes and I replied to the ticket. The base64encoded data received is the same as that which was sent, so I do not think data length is the issue. Also if I send the file data just by itself without putting it into an array, the file arrives at the server intact and can be base64Decoded and decrypted and saved to disk with no issues. Further if I run the server on a MacOS device it works fine.

It wasn't for me - for the 970kb file it didn't send all the data - only about 100kb got across to the server with the current implementation (how much is entirely machine/network dependent as its entirely timing based - this was a macOS host with a Windows 11 VM).

However, when I tweaked the script to send an 8 byte (decimal) length first, read that in the server and then 'read for' that length in bytes, it worked fine (the method described in the bug report).

I think that read from socket with messages will continue to read until it encounters an EOF, and THEN it will generate the message. It would be a pretty poor implementation to send the message in the middle of receiving data!

It does not - it reads until there is no more data immediately available (i.e. the data which has accumulated in the socket since the last time it was read) and sends a message with that.

In general socket protocols use delimiters or lengths so that the receiver knows how much data to expect - and the 'read until' and 'read for' commands allow this.

Reading what is available is still useful though - as it allows data to be processed in chunks as it arrives.

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Build Amazing Things

_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to