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)
Core
Networking
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
Reporter | ||
Updated•8 years ago
|
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)
Assignee | ||
Comment 3•8 years ago
|
||
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.
Assignee | ||
Comment 4•8 years ago
|
||
I'll take care to get the information needed or close this.
Assignee: nobody → honzab.moz
Status: NEW → UNCONFIRMED
Ever confirmed: false
Assignee | ||
Updated•8 years ago
|
Whiteboard: [necko-active]
Reporter | ||
Comment 5•8 years ago
|
||
(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)
Assignee | ||
Comment 6•8 years ago
|
||
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.
Description
•