Encoding Arrays with File Paths

[Alex Tweedly]

On 25/02/2025 19:49, Bob Sneidar via use-livecode wrote:
> <snip>
>
> Because I developed my own encryption API which uses AES256 but has a couple tricks. SSL certs will not suffice, and the whole point to having my own encryption technique is so that I can avoid SSL certs and the process of registering them and installing them.
OK
> Because I am encrypting the file data before sending, I have to base64encode the data before sending over the wire,
Um, no.
>   unless someone has a better suggestion for how to format the data in an internet friendly way.
There's no need. You're sending over a TCP socket, not HTTP - so there's 
no need for an "internet friendly" encoding - you can send arbitrary 
binary data (since you have effectively length+data - even if the length 
is sent separately). No need for base64encode or anything like that.
> Also I dont really have any experience in setting up web servers, and since I am developing this for the company I work for, they will likely not want this running on a different server than they already use which is MS SQL, and probably wont want it running on their mission critical servers either.
>
> After going back and forth with Mark, I see that I am going to have to break the data up anyway, so I am going to send an array first which has all the information I need to control the server side (things like versioning, extended paths, workflow stuff etc.) and then send each file separately using whatever method works best. I am not averse to sending the file size first.
> On Feb 25, 2025, at 10:03 AM, Richard Gaskin via use-livecode<use-livecode at lists.runrev.com> wrote:
>
> This excercise raises a question:  rather than invent another protocol, why not use HTTP?

Usually, because HTTP is quite decidedly a client-server protocol. If 
you have a peer-peer protocol need, then you have to bend HTTP out of 
shape :-)

Or, because the server already has an HTTP server running on it under 
some IT dept's control, and you're not allowed to hook into it.

Or, because in the event of a breakdown in the firewall, a 
mal-intentioned outsider could more easily circumvent your protections. 
A "private" protocol is an extra level of defence (assuming you do it 
right).

Or, just because it's more interesting :-)

>   Saves dev time, eliminates the need to write and maintain documentation for a custom protocol, leverages existing robust tooling, allows for integration with other packages as customer needs evolve, and stakeholders often get to buy-in faster where open standards are employed.

Alex.