CommonCrypto good enough , iOS/macOS have hardware accelerate. yarshure
On Thu, Jan 17, 2019 at 4:32 AM Howard Shere <howard.sh...@synchronoss.com> 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! <eski...@apple.com> wrote: > > > > On 10 Jan 2019, at 15:42, Howard Shere <howard.sh...@synchronoss.com> > 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 (Macnetworkprog@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > > https://lists.apple.com/mailman/options/macnetworkprog/howard.shere%40synchronoss.com > > This email sent to howard.sh...@synchronoss.com > > > *Howard Shere* | Software Sculptor > > Desk: +1 CAL.LMO.BILE | Mobile: +1 901.359.4200 > howard.sh...@synchronoss.com > www.synchronoss.com > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Macnetworkprog mailing list (Macnetworkprog@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/macnetworkprog/yarshure%40gmail.com > > This email sent to yarsh...@gmail.com >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Macnetworkprog mailing list (Macnetworkprog@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/macnetworkprog/archive%40mail-archive.com This email sent to arch...@mail-archive.com
