search

pixelspark / rethink-swift

A RethinkDB client driver for Swift
https://pixelspark.nl/2015/rethink-swift-a-swift-driver-for-rethinkdb
76 stars 11 forks source link

Swift on Linux support #5

Open demom opened 8 years ago

demom commented 8 years ago

Hi,

I've just come across your project, searching for RethinkDB drivers for Swift on Linux.

Is that in the pipe, or something I could contribute with?

/Tommy

pixelspark commented 8 years ago

Hi @demom! I am not currently working on Linux support, but this certainly would be interesting to have. I think the main issue is porting the network code (the driver currently uses GCDAsyncSocket, but there should be a Linux alternative available for that).

So feel free to give it a try and let me know if there's anything I can do.

/Tommy :)

johnbona commented 8 years ago

Hi @pixelspark!

Now that SPM support is in #7, I'm currently working on Linux support but going to have to switch GCDAsyncSocket and SCRAM to Swift-based implementations.

Do you prefer having two separate smaller PR's (one for networking and one for SCRAM) instead of one larger PR? Almost completed converting the network code over to vapor/socks.

pixelspark commented 8 years ago

Great to hear you're working on Linux support, @johnbona! Smaller PR's are preferred as they are a bit easier for me to test/review. Not sure what you had in mind re/ SCRAM, I guess it shouldn't be too difficult to rewrite in Swift and remove any Objective C code altogether (assuming vapor/socks works on macOS too?)

johnbona commented 8 years ago

Vapor/socks works on macOS as well.

Wanted to get your thoughts on crypto. CryptoSwift is all Swift but requires, on average, 130.55 ms to generate the HMACs when performing SCRAM auth. Vapor's crypto library does have a C dependency (LibreSSL) but on average only takes 32.54 ms for the same test.

Have SCRAM auth working using vapor/crypto at the moment but if you prefer not having C dependencies, I can switch over. 👍

krzyzanowskim/CryptoSwift vapor/crypto
112.425982952118 ms 39.5439863204956 ms
138.751983642578 ms 29.2920470237732 ms
133.029997348785 ms 29.2499661445618 ms
125.846982002258 ms 29.9699902534485 ms
142.695963382721 ms 34.6269607543945 ms
pixelspark commented 8 years ago

@johnbona that's quite a difference in performance! Did you compile CryptoSwift in release mode with all optimizations turned on?

Ideally speaking we'd be fully Swift native - as the SCRAM authentication is only performed once when a connection is established, I don't think the lower performance is an issue. If we can be sure that libressl (or equivalent) is available on all platforms we compile on, then on the other hand I don't think we should use a separate implementation. So for now, feel free to stick with your libressl based solution if that gets the Linux port out of the door faster - we can always still switch to CryptoSwift afterwards.

jrahaim commented 7 years ago

What is the status of getting this working on Linux? Package manager seems to be working fine, but what about the Crypto and GCD Stuff? is there anything I can help with?

pixelspark commented 7 years ago

@jrahaim no news from my side but perhaps @johnbona has made some progress?

matthijs2704 commented 7 years ago

Any news regarding this @johnbona, @pixelspark ?

pixelspark commented 7 years ago

@matthijs2704 sorry, no news from my side. Haven't heard from @johnbona either. His last work on this is from september last year (see https://github.com/johnbona/rethink-swift). Now assuming this contains the SCRAM stuff, I think the only other thing to do is to start using a portable sockets layer (could be vapor/socks or IBM-Swift/BlueSocket). Shouldn't be too difficult - anyone wants to step up?

matthijs2704 commented 7 years ago

@pixelspark I just noticed that that fork already got merged into this one! I thought I'd give it a shot to move to Vapor/Sockets. I'll create a PR for that, so you can check what I've done.

matthijs2704 commented 7 years ago

For Linux support also the SCRAM stuff needs to be rewritten in Swift (Swift on linux does not support Obj-C code). I've started doing this on matthijs2704/rethink-swift on the linux-travis branch. If you have a little spare time, could you take a look at it, as I'm not able to rewrite the xor function (in Utils.swift) in a way it matches the obj-c version, therefore the authentication doesn't work...

pixelspark commented 7 years ago

@matthijs2704 have you seen this? https://github.com/CryptoKitten/SCRAM

matthijs2704 commented 7 years ago

Yes I have and I have used that. But CryptoKitten is deprecated and the source pretty outdated, so I had to update it. But for some reason the xor from the current SCRAM givs a different output from the CryptoKitten varient

pixelspark commented 7 years ago

Hm. Might be some endianness issue then?

matthijs2704 commented 7 years ago

@pixelspark fixed it! Now I 'only' need to figure out why the data isn't being sent on Linux...