Closed Bug 1282390 Opened 8 years ago Closed 8 years ago

nsISocketTransport.isAlive() returns true and onInputStreamReady isn't fired when TLS connection is suddenly closed

Categories

(Core :: Networking, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: chunmin, Assigned: mayhemer)

References

Details

(Whiteboard: [necko-active])

Devices ----------------------- TLS Server: FxOS TV 2.6 on nexus player TLS Client: Fennec with remote-control service add-on[0] on SONY Z3C Testing Steps ----------------------- 0. Build TLS connection between Fennec and TV(nexus player) (onInputStreamReady callback is registered in nsISocketTransport.setEventSink) 1. Unplug TV(nexus player) 2. Call nsISocketTransport.isAlive() Expected Results ----------------------- * nsISocketTransport.isAlive returns false * onInputStreamReady callback is fired Actual result ----------------------- * nsISocketTransport.isAlive returns true * onInputStreamReady callback isn't fired [0] https://github.com/ChunMinChang/fennec-fxos-tv
Blocks: 1282344
No longer blocks: 1282344
my bad
Blocks: 1282344
Summary: nsISocketTransport.isAlive() returns true and onInputStreamReady isn't fired when TLS connection is closed() → nsISocketTransport.isAlive() returns true and onInputStreamReady isn't fired when TLS connection is suddenly closed
Chun-Min - is there any traffic sent over the socket other than TLS setup? Is it possible to reproduce this *without* having a TV available for testing? What is the problem caused by the perceived mismatch between isAlive and onInputStreamReady? This bug is difficult to triage without more information.
Flags: needinfo?(cchang)
Also some pointer to a concrete code that is troubling for you would be good. The description is too wage. Also "onInputStreamReady callback is registered in nsISocketTransport.setEventSink" sounds pretty odd. onInputStreamReady is only passed to asyncWait method on nsIAsyncInputStream.
I'll take care to get the information needed or close this.
Assignee: nobody → honzab.moz
Status: NEW → UNCONFIRMED
Ever confirmed: false
Whiteboard: [necko-active]
(In reply to Nicholas Hurley [:nwgh][:hurley] from comment #2) > Chun-Min - is there any traffic sent over the socket other than TLS setup? > Is it possible to reproduce this *without* having a TV available for > testing? Hi Nicholas, Thank you for your attention. I plan to re-produce it on browser itself as a server on my PC, and use Fennec as a client to connect it. Then unplug the power of my PC and see what happen. However, I have some urgent tasks for smart TV. I will try this scenario after finishing TV's last features. > What is the problem caused by the perceived mismatch between > isAlive and onInputStreamReady? It's an edge case for remote-control service. We write a Fennec add-on as a remote controller for FxOS TV. It will launch a control page for users to control TV by sending touch events, keyboard events, ...etc. When the TV is power-off, we hope the control page can be killed by Fennec itself, so we need a socket-closed notification/callback to do it. Currently, we use onInputStreamReady as the callback. In the normal case, if TV is rebooted/shutdown by clicking the POWER key, then onInputStreamReady will be fired. However, in the edge case, if TV is suddenly unplugged(maybe it's is similar to the crash case?), then onInputStreamReady won't be called and isAlive will return true. The current workaround for this edge case is to use a heartbeat protocol to check whether the TV is alive. The Fennec will send a |ping| to TV, and TV will reply a |pong| to Fennec in time. (In reply to Honza Bambas (:mayhemer) from comment #3) > Also "onInputStreamReady callback is registered in > nsISocketTransport.setEventSink" sounds pretty odd. onInputStreamReady is > only passed to asyncWait method on nsIAsyncInputStream. Hi Honza, Thanks for your reminder. I wrote the wrong description. It's actually registered in nsIAsyncInputStream.asyncWait().
Flags: needinfo?(cchang)
Aha! Got it. Then this is INVALID then. The heartbeat or short time keep-alive checking is the only way. This is a common mistaken assumption about a socket that when the other side is suddenly gone, you immediately know. Wish it worked that way :) But it doesn't. So, your workaround is an actual and correct solution.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.