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@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 ~ 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 _______________________________________________ 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
