Closed Bug 869922 Opened 12 years ago Closed 12 years ago

Push open multiple WebSocket connections

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: willyaranda, Assigned: nsm)

References

Details

We are testing battery usage and signaling of SimplePush, and sometimes we are finding that WebSocket connections are not tracked correctly. Using |adb shell netstat|, we can see different behaviours, all under 3G + WebSocket (no UDP): root@android:/ # netstat Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:2828 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:666 0.0.0.0:* LISTEN tcp 0 0 172.40.5.133:46198 81.45.59.238:443 ESTABLISHED This when turned on the device. The 81.45.59.238:443 is our preproduction SimplePush server. Leaving the device alone, USB unplugged, screen locked…  root@android:/ # netstat Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:2828 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:666 0.0.0.0:* LISTEN tcp 0 0 172.40.5.133:46214 81.45.59.238:443 TIME_WAIT tcp 1 0 172.40.5.133:38296 192.168.1.48:9999 SYN_SENT tcp 0 0 172.40.5.133:46211 81.45.59.238:443 ESTABLISHED tcp 0 0 172.40.5.133:46215 81.45.59.238:443 ESTABLISHED tcp 1 0 172.40.5.133:38297 192.168.1.48:9999 SYN_SENT tcp 0 0 172.40.5.133:46213 81.45.59.238:443 TIME_WAIT when unlocking, we are seeing a data sending, and using wireshark we can see (after around 60), that: 1) Connection 46198 is dropped [FIN,ACK] 2) A new connection is being opened [SYN] 3) The new connection is [SYN, ACK] 4) But another one is opened with [SYN] and then [SYN, ACK] Some connections are dropped in a (I think) randomly fashion. We are using what is on b2g-18 right now, and not using the patch in bug 863732, which maybe fixes this problem.
The only entry point to creating websockets is beginWSSetup() which has guards to prevent this. In any case, could you try a run with 863732 and 867913 (patch coming up, simplifies interface change logic) both applied.
Guillermo, any updates on this?
I need to test with your patches tomorrow. Sorry for the delay :(
Reporting back here: first tests under 3G (first priority), no WS disconnection and no more WS opened. I will test under wifi during this evening.
And on 3G (with Movistar SIM), this does work correctly. I'm closing this, and reopen if something shouts again. Could you please ask for uplift your patch in bug 867913 for b2g-18 once it get reviewed. Thaks Nikhil!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
And of course, I meant under wifi, not 3G :)
Not technically a dupe. Not invalid since the bug was a valid bug, it just didn't need fixing. Fixed by the changes in bug 863732 and bug 867913.
Resolution: INVALID → FIXED
You need to log in before you can comment on or make changes to this bug.