Re: I need some feedback
Re: I need some feedback
- Subject: Re: I need some feedback
- From: 孔祥波 <email@hidden>
- Date: Thu, 17 Jan 2019 10:30:06 +0800
CommonCrypto good enough , iOS/macOS have hardware accelerate.
yarshure
On Thu, Jan 17, 2019 at 4:32 AM Howard Shere <email@hidden>
wrote:
>
> We can’t entirely stream from the files because we need to encrypt the
> data.
>
> Any thoughts on using multiple threads rather than one? Or using the GPU
> to encrypt/decrypt the data?
>
> I lean towards using a single thread unless the performance becomes
> limited by the encryption/decryption work, then multiple threads might
> help...
>
>
> On Jan 10, 2019, at 9:58 AM, Quinn The Eskimo! <email@hidden> wrote:
>
>
>
> On 10 Jan 2019, at 15:42, Howard Shere <email@hidden>
> wrote:
>
> Lots of files.
>
>
> That’s likely to be the most interesting part of this. Transferring a
> single large file over Wi-Fi is pretty straightforward: Open a TCP
> connection and pour bytes down it. That’ll be fast and work well in a wide
> variety of network environments. You may be able to do better with a
> custom transport protocol in some specific environments, but it’s hard to
> do better than TCP in general.
>
> If you go down this path it’s a good idea to start the transfer with a
> header (including, at a minimum, the expected length) and end the transfer
> with a checksum.
>
> IMPORTANT: You need an end-to-end checksum because, when transferring
> /large/ amounts of data, the probability of an error not being detected by
> the TCP checksum starts to rise.
>
> The header will also allow you to support resumable transfers, which is
> always a good idea on iOS.
>
> The specific API you use for this doesn’t really matter than much. If you
> had a minimum deployment target of iOS 12 I’d recommend `NWConnection` but,
> as you have to support older systems, using `NSStream` is fine.
>
> If you have multiple files to transfer then things get substantially more
> complex. Ideally you’d want to transfer all the files over the same TCP
> connection. The thing you want to avoid is an archive-transfer-unarchive
> approach, because the time taken for the [un]archiving could be
> significant. That means the sender needs to stream off the file system and
> on to the network, and the receiver needs to do the reverse. This isn’t
> too hard but the devil is in the details. For example, supporting
> resumable transfers with multiple files is going to be tricky.
>
> You could probably find an industry-standard protocol that meets your
> needs, but that’s not always a win. A lot of the time standard protocols
> tend to be more complex than necessary, and they’re only an advantage if
> you can find a library that implements the protocol, and that brings its
> own complexities.
>
> Share and Enjoy
> --
> Quinn "The Eskimo!" <http://www.apple.com/developer/>
> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Macnetworkprog mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
>
> This email sent to email@hidden
>
>
> *Howard Shere* | Software Sculptor
>
> Desk: +1 CAL.LMO.BILE | Mobile: +1 901.359.4200
> email@hidden
> www.synchronoss.com
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Macnetworkprog mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden