chrome.sockets.tcp is not available

[Naethyn]

chrome.socket is available in mobile-chrome-apps, but chrome.socket is deprecated in favor of the sockets.udp, sockets.tcp and sockets.tcpServer APIs.

Writing code using a depreciated API is not ideal. Libraries using the newer sockets APIs do not work with mobile-chrome-apps. It is not likely they will be ported to a depreciated API.

[kzahel]

I wish I knew why the changed the API, so soon after it went stable. It hardly seems to be a large enough improvement to warrant the change. I wonder when they will actually start doing a console.warn on e.g. chrome.socket.create

[mmocny]

Just wanted to chime in: the benefits of the new API make a lot more sense on desktop, where the lifetime of the chrome runtime outlives the lifetime of your applications.

The v2 structure of chrome.sockets was supposed to address two problems (at least):

1. Support killing an idle app while still persisting its running server socket waiting for incoming network connections.
2. Support iterating the list of existing sockets.

Basically, the v1 structure was a pain to manage resource/app lifetime. For mobile chrome apps on cordova, where the runtime lifetime is your app lifetime, and your app is the only app, the v2 structure I think buys us little benefit aside from desktop parity and perhaps preference for api structure.

Its absolutely on our radar to implement these new apis (and we would be happy to accept submissions), but it isn't on our task list for the coming weeks because of other more pressing issues (like APIs that don't exist at all, and workflow bugs). Sorry for the unsatisfying answer.

[kzahel]

Thanks for the clarification. That's actually exactly the explanation I was looking for.

[mmocny]

Looking over old design docs (sorry, they seem internal only, but I'll ask if they can be shared publicly, there is no reason to not be) another motivation was to more prominently split the tcp/udp interfaces, since both behaved subtly different and had a different api surface area, and the only way to differentiate was with the options which they were created. Looks like tcpServer was thrown into that in the end as well, which is great in my opinion.

I do think they did not need to change the API so radically, but they needed to change it at least a little and I guess they decided to fix other API lessons-learned while they were at it.

[Naethyn]

My primary goal is to find a way to get the redirect url for a cross domain xhr request in mobile-chrome-apps. https://github.com/codeinchaos/chrome.sockets.tcp.xhr Provides a solutIon that I have tested as working in a Chrome App, but it is for the newer chrome.sockets.tcp library that is not supported by mobile-chrome-apps.

[ahmadnassri]

@Naethyn pointed me to this thread. I've already started working on a Polyfill, will publish and post back here. would love some support/assistance.

[mmocny]

Well thanks for taking this on.

I'd say a polyfill over the existing js api is a great start. The bigger project is redoing the native bits, but that has less to do with API structure and more to do with code cleanup (chrome.socket was a quick early attempt to get an API ported and has some tech debt).

@ahmadnassri FYI The team working on Chrome Apps for Mobile is entirely in Waterloo. I also see you're also connected to @pearlchen who works with us. Maybe thats how you heard about the project?

What was the motivation for chrome.socket.tcp.xhr?

[ahmadnassri]

@mmocny agreed. code clean up is the answer. JS Polyfill might be useful for some beyond this scope as well (seen lots of chrome.socket implementations apps/extensions using the old chrome.socket API out there) will help with the transition...

chrome.sockets.tcp.xhr started as part of REST Console updates to add more flexibility beyond the standard XMLHttpRequest

unrelated: @pearlchen and I are setting up the first Yeoman Toronto workshop!

[mmocny]

@ahmadnassri There are other chrome.socket implementations out there?

[ahmadnassri]

@mmocny corrected. (was typing on mobile)

[mmocny]

Ah thanks.

[ahmadnassri]

@mmocny @Naethyn I started looking into building the polyfill, but quickly changed my mind after coming to a couple of important conclusions:

• deprecated chrome.socket (Chrome 24) in favour of chrome.sockets (Chrome 33)
  • given that Chrome is an evergreen browser, this is already too far back to support (at least for desktop)
• this still leaves Chrome Mobile (Android + iOS) and Mobile Chrome Apps.
  • Chrome Mobile does not support apps on its own.
  • this leaves Mobile Chrome Apps, which the team here is willing to support, and per @mmocny note, the best approach is to simply update the code base here and add proper support.

[mmocny]

@oahziur Is working on this!

[ahmadnassri]

@mmocny awesome. glad to hear there's progress.

[Naethyn]

Thanks!

[felixhammerl]

awesome! we just integrated chrome.sockets.tcp in our TCPSocket polyfill https://github.com/whiteout-io/tcp-socket/ here's the code: https://github.com/whiteout-io/tcp-socket/blob/dev/WO-593/src/tcp-socket.js#L182

for now, we're running TLS via forge in a worker, but we're looking forward to when https://github.com/MobileChromeApps/mobile-chrome-apps/issues/269 is integrated :)

[felixhammerl]

@mmocny as promised, some data to work with ...

i created a rudimentary test project that connects to the smtp.wmail.io on 587 (TCP) and 465 (TLS) to check out some of the socket's corner cases, feel free to mess around with it: https://github.com/felixhammerl/foo

airplane mode on android

Steps:

• fire up the app on a nexus 7
• connect with tcp (works nicely)
• send EHLO (works nicely)
• enter airplane mode
• socket explodes

Error in Error callbackId: ChromeSocketsTcp370329377 : TypeError: Cannot read property 'length' of undefined cordova.js:299
processMessage failed: Error: TypeError: Cannot read property 'length' of undefined cordova.js:1073
processMessage failed: Stack: TypeError: Cannot read property 'length' of undefined
    at Event.fire (file:///android_asset/www/plugins/org.chromium.common/events.js:42:37)
    at callbackWithError (file:///android_asset/www/plugins/org.chromium.common/errors.js:23:14)
    at fail (file:///android_asset/www/plugins/org.chromium.sockets.tcp/sockets.tcp.js:150:9)
    at Object.cordova.callbackFromNative (file:///android_asset/www/cordova.js:288:52)
    at processMessage (file:///android_asset/www/cordova.js:1068:21)
    at Function.androidExec.processMessages (file:///android_asset/www/cordova.js:1105:13)
    at pollOnce (file:///android_asset/www/cordova.js:956:17)
    at pollOnceFromOnlineEvent (file:///android_asset/www/cordova.js:946:5) cordova.js:1074
processMessage failed: Message: F19 ChromeSocketsTcp370329377 {"resultCode":-2,"message":"recvfrom failed: ETIMEDOUT (Connection timed out)","socketId":1} 

Would be nice to actually receive a callback that the socket just errored/closed. When the network is back up, it does tell me that the socket is (obviously) closed, so the sockets seems to know that it is broken, but fails to inform me about it.

airplane mode on ios

same steps as android, same error...

[Error] The operation couldn’t be completed. Socket is not connected
    callbackWithError (errors.js, line 14)
    fail (sockets.tcp.js, line 150)
    callbackFromNative (cordova.js, line 294)
    (anonymous function) (cordova.js, line 1086)
    nativeEvalAndFetch (cordova.js, line 1094)
    nativeCallback (cordova.js, line 1083)
    global code (index.html, line 1)
[Error] TypeError: undefined is not an object (evaluating 'this.listeners.length')
    nativeEvalAndFetch (cordova.js, line 1097)
    nativeCallback (cordova.js, line 1083)
    global code (index.html, line 1)

Also no notification that my stuff is closed...

Is this how the chrome.sockets.tcp was designed?

[felixhammerl]

i don't know if this is related to the way that chrome.sockets.tcp works on chromium. hence this post on net-dev: https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/i7izmk0_l7U