Encoding Arrays with File Paths

[Bob Sneidar]

Okay I verified in my actual code. This is problematic if I don’t know how much data is actually going to be sent. I ended up with roughly 138,000 bytes before it choked. I supposed I could start with 128k chunks then dial it down if it’s too much. I wish I know what the limiting factors are because this has to work over the internet. 

Bob S


> On Feb 24, 2025, at 12:40 AM, Mark Waddingham via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> 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 ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Build Amazing Things
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode