I have one websocket server running in java application written using https://github.com/TooTallNate/Java-WebSocket and trying to connect to it
from browser. The browser is sending request to connect every second till the websocket server initializes. Chrome connects blazingly fast as soon the websocket is initialized. Firefox takes atleast 10-15 seconds to connect. Is there any way firefox to connect as chrome connects. I have checked the headers in both browser "keep-alive" header is sent in firefox and chrome doesnot send. Will it be affecting the connection ?
First test with this..
http://demos.kaazing.com/echo/
so that you will be able to know which side is the problem.
Issue resolved. It was becuase i was using the old version which was created in 2013. The spec and implementation changed a lot. Thanks #Nitish Dhapodkar i used that website to check connectivity.
Related
I'm writing an application that first tries to open a WebSocket connection (to make sure no others are open; address collision checking) before firing off a custom protocol that will launch a one-time WebSocket server with the address that the browser tells it. All communication is done over localhost and some arbitrary port number, say 3000. I'm not doing anything special, just attempting to open a WebSocket:
var socket = new WebSocket("ws://localhost:3000/MyApp/");
socket.onclose = function(e) { console.error(e); }
When testing in Chrome, the WebSocket will actually stay in the CONNECTING state for a little bit, which is ideal, since it gives us some time to actually launch the app through the custom protocol. But in Firefox, the WebSocket immediately closes with code 1006 and I can't figure out why.
I've tried changing the about:config network.websocket.timeout.open setting to be 1000 (from 20), but that doesn't help. I've also found this related post: Websockets - chrome and firefox differences?. That hasn't lead me to finding an answer, either.
What am I missing?
Update 11/16/21
I'm using the Dev Tools in Chrome and FF to check out the requests. The weird thing is that Chrome is actually sending a request header as you'd expect, but in FF, the request is completely empty (0 Bytes). Maybe this is a problem with FF not supporting debugging native WebSockets (no wrapper libraries in use)? Is there some FF setting that nixes the request? But even more confusing is that the browser would hit the close event without ever hitting the open event.
Update 11/17/21
I realize that maybe this has something to do with launching a Custom Protocol Handler? I noticed that it will wait a second to try and connect to a web server if no CPH is launched, but then when I do launch a CPH, that is when it immediately closes the WebSocket. The CPH is launched via a link targeting "_parent".
It looks like the custom protocol is causing FF to stop trying to connect early. I created an anchor element, <a>, in the JS code and called "click()" on it after constructing it. No matter what target I gave it (e.g. _self), it would cause the connection attempt to stop.
So long story short, initiating a link, whether it be a a.click, window.open, or location.replace, will cause Firefox to nix any currently polling WebSockets!
The workaround is to just use an iframe to launch the custom protocol.
I have a problem with socket.io application for nodejs. I have several browser windows in my application, all of them are connected to nodejs. Application is not a heavy loaded one yet. Sometimes something hapens to socket.io, so that .emit() command on browser is not executed (i.e. server doesn't see it). nodejs console/logs shows no crashes/exceptions. Application stays in this blocked state for ~30 seconds and then resumes correct work. Browser console log shows 400 error for one of socketio request.
Any ideas why this happens and how to cure/diagnose it?
I have found a root cause for this problem. Chrome has a limit of 6 open HTTP requrests. So you can't have more then 6 tabs doing socketio XHR poll exchange with the server. 7th tab would behave as if server is not available.
Reduce number of connections, or may be use websocket mode, it works fine.
I was hoping google chrome socket connections from a chrome extension would go through the proxy settings of the browser but it does not seem to be the case.
Any idea of how could I automagically connect to a server and let chrome bothering with the proxy ?
Currently you can't, but we expect that this will be possible using a network proxy API when the bug http://crbug.com/172285 gets implemented.
If you want, star the issue to follow the development.
I have successfully implemented socket.io, node.js and express to server realtime json data to all browsers except IE (testing on 9) using a secure connection. This worked fine everywhere until I moved it behind https. From the server console output, it shows that an event is received when called from IE:
xhr-polling received data packet 5:::{"name":"lookup_place","args":
[{"place":"Berlin"}]}
However, no response is given and the next 4 lines shown in the console are:
clearing poll timeout
xhr-polling writing 8::
set close timeout for client 27081179790885432
xhr-polling closed due to exceeded duration
When the same is done from FF or Chrome, the line "xhr-polling writing 8::" is appended with the correct response, for example:
xhr-polling writing 5:::{"name":"place_results","args":[{"a":
[{"identifier":"52156","value":"Monschau, 52156"},
{"identifier":"67590","value":"Monsheim, 67590"},
{"identifier":"04617","value":"Monstab, 04617"}]}]}
I am using node.js version 0.4.10, socket.io version 0.7.7 and express version 2.4.3. The same scripts worked perfectly fine in IE 7-9 without an https/ssl/secure connection.
Any help would be greatly appreciated in discovering why no response is delivered in IE but works fine in all others.
Might be a bug. I would advice you to fill an issue at Socket.io's github issue page. Then the authors will also receive an email and probably respond pretty fast.
I am experiencing a problem with accessing an application from the Android-browser.
The application uses DWR to persist connections to the clients that are connected with it.
Everything works fine for me, except that if the application does not send any data to the client on the Android-phone for 2 minutes, the connection seems to be lost and no data arrive at the client. The same scenario works just fine on Firefox, Opera and Chrome. If the pause between two data transfers is less than 2 minutes, it works just fine.
So, now my question:
Is there some timeout setting for the android browser that I am missing? Or is this some built-in bug/feature/whatever that I cannot circumvent?
I know that I could prevent this from happening with some sort of heartbeat, I would just like to why this is happening.
Thanks in advance, Max
btw: Everything (server, clients) runs on my machine and I am testing this on the android emulator with Windows XP
Android emulator version 1.10 (build_id CUPCAKE-150240)
Could it be that the Android system is garbage collecting your activity and thus loosing your web browser and closing the persistent connection?
Perhaps you could check this by looking in you logcat (on android end) or webserver logs (on remote end)?
if this is the case, you would need to add reconnect code into the onresume/onstart method in android.