Open GoogleCodeExporter opened 9 years ago
Getting the same issue on Centos 6.5 32bit
*INFO: WebSocket Peer accepted/connected with fd = 15
*INFO: *** Stream Peer destroyed ***
*INFO: #0 peers in the 'SIP transport' transport
*INFO: #1 peers in the 'SIP transport' transport
***ERROR: function: "tsip_transport_layer_ws_cb()"
file: "src/transports/tsip_transport_layer.c"
line: "397"
MSG: WS handshaking not done yet
*INFO: Removing socket 15
*INFO: Socket to remove: fd=15, index=2, tail.count=3
*INFO: RemoveSocket(fd=15) has been requested but we are poll()ing the socket.
ShutdownSocket(fd) called on the socket and we deferred the request.
*INFO: ShutdownSocket(fd=15)
*INFO: WebSocket Peer closed with fd = 15
*INFO: #0 peers in the 'SIP transport' transport
*INFO: *** Stream Peer destroyed ***
*INFO: PipeR event = 1
*INFO: NETWORK EVENT FOR SERVER [SIP transport] -- TNET_POLLHUP(15)
*INFO: Removing socket 15
*INFO: Socket to remove: fd=15, index=2, tail.count=3
*INFO: CloseSocket(15)
*INFO: PipeR event = 1
*INFO: WebSocket Peer closed with fd = 15
*INFO: WebSocket Peer closed with fd = 15
Original comment by android....@gmail.com
on 1 Jan 2014 at 4:36
Same problem on Ubuntu 12.04 64bit, Firefox 26 and doubango version 2.6.0. With
Chrome 31 all works fine.
Original comment by pburlov
on 14 Jan 2014 at 1:01
Attachments:
It happens sometimes also on Chrome :(
Original comment by patrik.t...@gmail.com
on 25 Mar 2014 at 10:59
After searching and trying I have found that it has something to do with ssl
certicates
Original comment by patrik.t...@gmail.com
on 29 Mar 2014 at 12:07
So now what?
Same problem here!!
Original comment by diogo...@gmail.com
on 26 Jun 2014 at 3:03
Nothing?
Original comment by di...@fluxoti.com
on 7 Jul 2014 at 1:07
Can you explain the reasoning behind why you believe it has something to do
with SSL certificates?
Original comment by jtho...@silvervue.com
on 9 Jul 2014 at 8:38
So, I'm tracking it to something strange happening with the peer->ws structure
for the currently connected peer.
I put a LOG print inside tsip_transport_layer_ws_cb(const
tnet_transport_event_t* e) to print
the current status of the peer->ws.handshaking_done variable.
It seems like the socket connects, it detects the GET, everything checks out
and handshaking_done is set, and then for the next packet that comes in,
suddenly handshaking_done is '0' again. I print the address of the peer to
prove it is the same structure both times.
Either it's some kind of race condition, or some condition happens in the
middle that resets the structure:
This is the part of interest:
"*INFO: SETTING HANDSHAKING DONE on dc007830 0
*INFO: SET HANDSHAKING DONE on dc007830 1
*INFO: WebSocket Peer accepted/connected with fd = 18
*INFO: *** Stream Peer destroyed ***
*INFO: #0 peers in the 'SIP transport' transport
*INFO: #1 peers in the 'SIP transport' transport
*INFO: FIRST BYTES OF WEBSOCKET PACKET: � �
*INFO: CHECKING HANDSHAKING DONE on dc007830 0
"
*INFO: NETWORK EVENT FOR SERVER [SIP transport] -- FD_ACCEPT(fd=18)
*INFO: Socket added[SIP transport]: fd=18, tail.count=3
*INFO: NETWORK EVENT FOR SERVER [SIP transport] -- TNET_POLLOUT
*INFO: WebSocket Peer accepted/connected with fd = 18
*INFO: #1 peers in the 'SIP transport' transport
*INFO: FIRST BYTES OF WEBSOCKET PACKET: G E T
*INFO: CHECKING HANDSHAKING DONE on dc007830 0
*INFO: WebSocket handshake message: GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: 204.236.130.239:20060
Origin: http://192.168.1.72:3000
Sec-WebSocket-Protocol: sip
Pragma: no-cache
Cache-Control: no-cache
Sec-WebSocket-Key: GZ08ej3U8xLrnlkTt368/Q==
Sec-WebSocket-Version: 13
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits,
x-webkit-deflate-frame
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
*INFO: IS WEBSOCKET PROTOCOL
*INFO: FOUND SIP
*INFO: SENDING SWITCH PROTOCOL RESPONSE
*INFO: SENDING RESPONSE
*INFO: SETTING HANDSHAKING DONE on dc007830 0
*INFO: SET HANDSHAKING DONE on dc007830 1
*INFO: WebSocket Peer accepted/connected with fd = 18
*INFO: *** Stream Peer destroyed ***
*INFO: #0 peers in the 'SIP transport' transport
*INFO: #1 peers in the 'SIP transport' transport
*INFO: FIRST BYTES OF WEBSOCKET PACKET: � �
*INFO: CHECKING HANDSHAKING DONE on dc007830 0
***ERROR: function: "tsip_transport_layer_ws_cb()"
file: "src/transports/tsip_transport_layer.c"
line: "410"
MSG: WS handshaking not done yet
Original comment by jtho...@silvervue.com
on 9 Jul 2014 at 9:44
So, I noticed the non-blocking versus blocking state machine handles the
'accepted/connected' condition differently.
Maybe this is an error where a fix in one didn't quite make it to the other?
I've modified tsip_transport_layer.c in doubango with the following change:
Line 367:
{{{
case event_accepted:
case event_connected:
{
tsip_transport_stream_peer_t* peer;
// find peer
if((peer = tsip_transport_find_stream_peer_by_local_fd(transport, e->local_fd))){
// If peer already exists.. do nothing :0
return 0;
}
else {
TSK_DEBUG_INFO("WebSocket Peer accepted/connected with fd = %d", e->local_fd);
return tsip_transport_add_stream_peer(transport, e->local_fd, transport->type, tsk_true);
}
}
}}}
And now I don't get the intermittent connection failures because the
handshaking_done flag now stays consistent to the overall state of the
websocket.
If you look at line 175, it seems to perform some similar functionality where
it searches for the peer, and if it finds it it doesn't create a new stream...
but instead strangely frees the memory behind the peer.
Original comment by jtho...@silvervue.com
on 9 Jul 2014 at 10:37
Original issue reported on code.google.com by
cklorin...@gmail.com
on 19 Dec 2013 at 10:03