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 don’t 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 won’t 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@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.
_______________________________________________
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
