Using https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ on Firefox 102.6.0 ESR and gathering the wireshark traces shows that for each STUN server configured, there are 2 outgoing requests per network interface. The same behavior is observed in my app using WebRTC.
Is there a specific point to why Firefox does it twice everytime?
Related
Find below logs from about webrtc while checking with trickle ICE.
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
ICE(PC:{f8be271e-a104-46d0-9666-1f5c4804b8e3} 1673540416421000 (id=6442450948 url=https://webrtc.github.io/samples/src/content/peercon): failed to resolve candidate relay(IP4:192.168.14.18:58951/UDP|IP4:0.0.0.0:3478/UDP).
Tried with other browsers on the same machine but did not face any issues. Cannot generate relay candidates in firefox browser alone. Even tried after reinstalling the browser.
In wireshark packet trace, I can see that there is not STUN request from the browser to the TURN server.
Currently working with Socket.IO using websockets. I have a couple of questions regarding how to interpret websockets in the chrome devtools:
When we have the following output in chrome:
Questions:
The method still is specified with the HTTP get method verb. Is this because this HTTP protocol is used to initiate the handshake?
If we have 4 type = websocket like in this example. Do we actually have 4 websocket connections?
One websockets was completed and the other 3 were still pending, what does this mean?
Yes, that's because the WebSocket handshake is an HTTP GET request. As you can see in the Status column, the server responded with "101 Switching Protocols", after which the protocol changed to the WebSocket protocol.
You seem to have one closed connection and three ongoing connections. Maybe whatever library you're using likes to create multiple connections?
The "pending" connections are active connections. The developer tools shows each connection that hasn't been closed yet as "pending". Not the most clear representation, but the dev tools were made to primarily deal with HTTP where individual requests don't last forever.
Free ProTip in case you didn't know: If you click on any of the requests and then click on the Frames tab, you can see all the WebSocket messages in real-time.
I have written a few dissectors in Lua for Wireshark, for example. I would like to know if Devtools can be extended to achieve similar effects. There are a few reasons this is desirable:
Installing and using Wireshark often mandates privileged access.
Capturing traffic from the loopback NIC on Windows remains problematic.
websocket traffic is included in saved HAR files, suitable for later dissection.
Devtools can inspect SSL secured websocket frames with zero user effort.
It's possible with Firefox.
There is an addon already that hooks into the WebSocket data. It can do some additional parsing of protocols on top of WebSockets like MQTT.
https://addons.mozilla.org/en-GB/firefox/addon/websocket-monitor/
It appears to hook into nsIWebSocketEventService to get the data. I haven't found any documentation for it.
https://github.com/firebug/websocket-monitor/blob/master/lib/wsm-actor.js#L80
Chrome does not appear to allow access to WebSocket frame data through an API.
You may be able to modify the WebSocket constructor to allow you to intercept the events from your plugin.
https://groups.google.com/forum/#!topic/google-chrome-developer-tools/7_a0W8Y92O4
I have tried every conceivable haproxy configuration posted in blogs and stackoverflow, but I still cannot get haproxy and socket.io to work 100% of the time. In the majority of browsers that "support" web sockets it fails and falls back on long polling after missed heart beats. The browser appears to make the initial connection (nodejs debugging), but I cannot get the clients to receive the connection response. Is anyone else having similar problems? Below are the software version numbers and a couple of the configs I have tried.
haproxy 1.4.18
node 0.6.5
socket.io 0.8.7
Haproxy configurations (I have tried many more and numerous options):
http://engineering.bistri.com/post/14307969768/socket-io-haproxy-http-authentication
HAProxy + WebSocket Disconnection
http://pastebin.com/H3XNv0TQ
http://www.darkcoding.net/software/proxy-socket-io-and-nginx-on-the-same-port-over-ssl/ (minus ssl stuff)
Web sockets working in:
Safari 5 (Windows)
Chrome 11 (Linux)
Websockets cannot be reverse proxy'd because the 8 bytes of data the client must send after the headers is not advertised in a Content-Length header, so the intermediates won't forward that data until the handshake completes. And since the handshake needs those 8 bytes to complete, the handshake never completes and deadlocks, http://www.enotes.com/topic/WebSockets#Proxy_traversal. This is not the only source. Many more sources verify that they cannot be reverse proxy'd.
I use node.js and socket.io.
I have a problem with the connection speed with socket.io.
In Internet Explorer and Opera I have a problem with the connection speed. - When I use flashsocket or websocket.
When I use the mode of transport-polling XHR connection is fast - in all browsers (IE, FF, Chrome, Opera).
What is the difference between the mode of transport - XHR-polling and flash / websocket?
What is the best mode of transportation? How to optimize the connection speed is socket.io?
Thanks for the advice!
I'd be surprised if the general speed of the connection over time was different between web browsers, but the reason you'll see a delay in the initial connection in Internet Explorer and in Opera is that native WebSocket support is not available as it's been disabled by default. So, if you choose FlashSocket then an additional Flash object (SWF file) will need to be downloaded before a connection is established.
WebSockets are being introduced in IE10 and in Opera they are available, but disabled by default.
What is the difference between the mode of transport - XHR-polling and flash / websocket?
XHR-polling - see http://en.wikipedia.org/wiki/Push_technology#Long_polling
FlashSocket connection - uses a Flash Socket object to establish a connection to the WebSocket server and communicates using the WebSocket protocol. This means there is interaction between Flash and JavaScript and also means an additional Flash object (SWF files) will need to be downloaded.
What is the best mode of transportation?
WebSockets for any Web Browser that natively supports it (Chrome, Firefox, Safari). If the Flash object (SWF file) is in the browser cache then connection should be fast. If it's not then there will be a delay. XHR Long-Polling is a good solution and will work cross browser but there are negatives:
between poll requests the data on display could be out of date (stale).
It's a less efficient connection method than a single TCP connection used by WebSockets since HTTP Long-Polling uses multiple connection to simulate bi-directional functionality
HTTP has an overhead which means additional header information is sent upon request and each subsequent request.
How to optimize the connection speed is socket.io?
(I'm pretty new to socket.io to this is just a suggestion)
I'd look at the configuring Socket.io docs and see if you can conditionally set the transports based on the browser that is connecting. Based on your experiences this could be:
Chrome, Firefox, Safari - WebSockets
IE, Opera - XHR-Polling
To reduce the time of connection, you can try to reduce the connect timeout (which is 10 seconds by default) using the "connect timeout" parameter.
For example, to reduce the connect timeout to 1 second:
socket = io.connect('http://your-site.com',{'connect timeout': 1000});