Add SSL (wss) support

[ocram]

The Autobahn library doesn't have support for the wss protocol so either switch to another library or wait until the feature is added

[ocram]

Thank you very much!

My issue with that library is that it isn't as extensively tested as the original Autobahn library. So I don't really want to switch to it here in the main repository.

But we'll leave the link to your fork here as the reference for all developers who need WSS (TLS) support today. Thank you!

By the way, Autobahn even has a TLS branch. But that one does not pass their extensive test suite yet, and unfortunately it hasn't been updated in the past three years.

We may also switch to TubeSock instead, which is based on the old Weberknecht library.

[elbow]

Happy to find this thread, just to note that I also need TLS support for my application.

Many thanks for your effort on this library.

[vlasky]

Hiyas, I have successfully added SSL support to Android-DDP by replacing Autobahn with Takahiko Kawasaki's nv-websocket-client.

It has been tested successfully in Android 4.4 and upwards. It may work in earlier versions, but I haven't needed to use any Android devices with those old versions. I will share my code with Marco and see what he thinks.

[isdzulqor]

how to sett up server for this library, I made an android native app with this library and I use meteor for my web service. I dont remove insecure package and autopublish package. so I can Insert, delete and update without subscribe or call the method in client. but my problem is I can not connect to my localhost. I use genymotion for the android emulator. Any one can Help me, please,,, Thank you for this amazing library here is my code https://ideone.com/pXzJW8

[vlasky]

isdzulqor - I see one obvious error in your code. Your URL is missing "/websocket".

Instead of:

mMeteor = new Meteor(getApplicationContext(), "ws://192.168.56.1:3000");

It should be:

mMeteor = new Meteor(getApplicationContext(), "ws://192.168.56.1:3000/websocket");

[isdzulqor]

@vlasky Thank you man, it works.. I've tried many times, i've tried restivus too, but it's still not working,, now you save my live :D but I am still wondering about, is it possible to upload file through ddp with this library,. like picture, video etc.. any way thank you so much for this amazing library too :) ,,

[ocram]

Experimental support for WSS (WebSocket over SSL/TLS) is now available on a separate branch :)

Please get the latest JAR there and test WSS support with your app. Do not use it in production yet.

You'll have to remove the two parameters from your onDisconnect(...) callbacks and the minimum API level has been raised from 8 (Android 2.2) to 9 (Android 2.3).

As soon as everything has been tested and bugs have been fixed, we'll integrate this into the main branch.

Thanks for your patience, @elbow and @vlasky!

@vlasky I've taken a look at your code -- it's good and we really appreciate your work. But we feel that TubeSock is a superior WebSocket library so we'll use that instead of nv-websocket-client.

[vlasky]

OK, but I wouldn't poo-poo nv-websocket-client just yet - the author is actively and enthusiastically maintaining that package.

Also, I recently asked him to add support for websocket compression using permessage deflate and his response was encouraging:

https://github.com/TakahikoKawasaki/nv-websocket-client/issues/15

I presume you are aware that Meteor 1.2 recently introduced support for this. If it were supported in the DDP client, it would greatly reduce the amount of data transferred over the internet connection - very useful when clients are communicating over cellular data networks that have data usage quotas.

TubeSock doesn't appear to support this and there is no roadmap on TubeSock's page that would indicate plans for future support.

[ocram]

@vlasky Thanks for your thoughts!

We've worked with seven of the major WebSocket libraries that are available for Java/Android in the past. Judging stability, ease of use and overall quality, we would definitely rank those as follows:

1. TubeSock (based on weberknecht by Roderick Baier)
2. okhttp-ws
3. nv-websocket-client
4. autobahn-android
5. Java-WebSocket
6. AndroidAsync
7. android-websockets

In fact, we've even built this WSS implementation with all of (1), (3), (4) and (5). TubeSock turned out to be the best library, mainly because it's super stable, with nv-websocket-client being a close contender.

What also speaks for TubeSock is:

• The company behind it, Firebase, has build their complete product portfolio around WebSockets. This is how they make their money, thus they definitely have an incentive to continue to invest into their WebSocket library for Android.
• Without most people knowing, TubeSock is the library that has been deployed to the most devices, by far, because it's in Firebase's SDKs. It's definitely well-tested.
• The library has not been built from scratch, but instead it's based on the excellent work by Roderick Baier. His library used to be one of the top choices as well.

So TubeSock is definitely what this library will be based on, starting with the next release.

But this may change again in the future, and we'll watch nv-websocket-client and the others closely.

Until then, you can of course keep using your forked version of this library that uses nv-websocket-client.

[ocram]

Implemented in https://github.com/delight-im/Android-DDP/commit/61109f1522f74b11a61bac48b40376ec18df6885 and 8 parent commits, and merged into the main branch :)

[vlasky]

Takahiko Kawasaki, the author of the websocket library nv-websocket-client, has just announced that he has implemented support for permessage deflate. I will be testing it out in my forked version of Android-DDP.

https://github.com/TakahikoKawasaki/nv-websocket-client/issues/15

[ocram]

@vlasky Thanks, impressive speed! As I said, we'll definitely watch that WebSocket library closely. In the meantime, developers who need support for "permessage-deflate" can probably get good support with your forked version, as soon as it's ready.

[TakahikoKawasaki]

@mwaclawek @vlasky

Comments from the author of nv-websocket-client (me) after reading the source code of TubeSock.

WebSocket class

• It does not provide any means to set extensions (Sec-WebSocket-Extensions). Before implementing permessage-deflate, TubeSock has to implement a base mechanism to handle extensions.
• It does not provide a method to send a ping frame.
• The data type for extra headers is Map<String, String>. This means headers having the same name cannot be specified multiple times. It should be Map<String, List<String>>.
• closeSocket() closes socket without waiting for receiver to finish its task. It will cause IOException in receiver. So, in most cases, a close operation will end with an error.
• It lacks flexibility for SSL settings. There is no means to use a custom SSLSocketFactory or SSLContext.
• It does not support HTTP proxy. See How HTML5 Web Sockets Interact With Proxy Servers about what a WebSocket client library has to do to support "HTTP proxy" and "wss over HTTP proxy".
• It stores HTTP headers contained in a response from a WebSocket server in an instance of HashMap<String, String>(). But it should be TreeMap<String, List<String>>(String.CASE_INSENSITIVE_ORDER).
• There is no means to specify a timeout value for socket connect operation.
• It does not wrap socket.getInputStream() with BufferedInputStream. This will cause a performance issue.
• It does not wrap socket.getOutputStream() with BufferedOutputStream. This will cause a performance issue.
• If socket.close() in closeSocket() throws an IOException, WebSocketEventHandler.onClose() is not called.
• The number of event listeners that a WebSocket instance can hold is only one.
• There is no means to send continuation frames manually.
• Close frames never contain payload. Therefore, the counterpart WebSocket server cannot know the reason of the close operation triggered by the client. It is optional but a close frame should contain a reason code and reason message. See 7.4. Status Codes for details.

WebSocketHandshake class

• Its verification on Upgrade header is too simple. To be extact, its implementation is wrong. It does not take into account the possibility that multiple elements may be listed in Upgrade header.
• Its verification on Connection header has the same problem as above.
• It does not verify Sec-WebSocket-Accept header. This is a violation against RFC 6455. See Page .19 of RFC 6455 for details.
• It does not verify Sec-WebSocket-Extensions header.
• It does not verify Sec-WebSocket-Protocol header.

WebSocketReceiver class

• stopit() just executes stop = true without any synchronization. Also, there is no interrupt() call for itself. So, read operation will block forever. But, it stops blocking thanks to the wrong implementation of WebSocket.closeSocket().
• It does not parse the payload of a close frame from the counterpart WebSocket server. Therefore, a client application cannot know the reason of the close operation triggered by the server.

WebSocketEventHandler interface

• Too simple. At least every callback method should be able to receive a WebSocket instance which the event handler is registered into.
• onClose() cannot know the reason code and the reason message of the close event.
• onError() cannot know the context of the error.

MessageBuilderFactory

• TextBuilder implementation is wrong. Although its comment refers to a possibility that bytes of multi-byte UTF-8 characters may be split across websocket frames, TextBuilder.appendBytes(bytes[]) tries to construct a UTF-8 string per frame. This is a big bug.

[TakahikoKawasaki]

Whether a library is used by many people, maintained by a big company, already deployed in many commercial environments, does not necessarily assure its quality. For example, Adobe Flash.

From my viewpoint, the quality of TubeSock is beginners' level. Don't believe rumors about software naively, but compare source codes when you select one from among multiple choices.

See also "Which WebSocket library to use in Android app?" (StackOverflow).

[ocram]

@TakahikoKawasaki Thank you very much for taking the time to look at TubeSock's source code and advertising your library. Just as rumors (whatsoever) are no good indicator of a library's quality, simply adding large quantities of features at a rapid pace is not an indicator of quality, either. But as I said, we're watching your library, which has emerged as an interesting contender, closely, and may very well do the switch in the near future.