Reimplement uproxy-lib in Java

[bemasc]

Passing every TCP byte through JS is bad for performance. On desktop, this is tolerable, but on mobile it is not (especially on low-end devices that represent the majority of emerging markets) . We should consider cloning this functionality into Java, packaged as a Cordova plugin, so that the Android build can make more efficient use of limited CPU time.

This is arguably blocked by #2094.

[willscott]

Is there an existing java implementation of WebRTC that could be used as a
starting point for this piece of work?

On Wed, Nov 25, 2015 at 11:55 AM, Benjamin M. Schwartz <
[email protected]> wrote:

Passing every TCP byte through JS is bad for performance. On desktop, this
is tolerable, but on mobile it is not (especially on low-end devices that
represent the majority of emerging markets) . We should consider cloning
this functionality into Java, packaged as a Cordova plugin, so that the
Android build can make more efficient use of limited CPU time.

This is arguably blocked by #2094
#2094.

—
Reply to this email directly or view it on GitHub
#2095.

[trevj]

Interesting idea! If I understand correctly, this is re-implementing just churn in Java?

[bemasc]

No, I mean more like reimplementing SocksToRtc and RtcToNet in Java. Churn is currently disabled on mobile for performance, and I don't think we'll be able to do obfuscation until we have a native-code implementation, probably derived from the future UDP pluggable transports work.

[bemasc]

@willscott: Yes, webrtc already has totally solid Java bindings and build support for Android. WebRTC itself would (continue to) run in native code, not Java (or JavaScript).

[bemasc]

I'm not convinced that this is obsolete. Actually, I think it blocks #2800