Does any one know how to close an xsockets socket.
There is no api for server or client side to show how to close a socket.
There is an event one can bind to "close" on client side but it says that "this will get called when server closes the websocket"
How can you close the websocket from the client side or from the serverside.
I extracted the socket object from xsocketcontroller and called close() on it but no luck.
client side close did not get called.
This is not well in the documentation I´m afraid. Will fix that a.s.a.p
You have a few options. The first ones is how to close the connection from the client. However, you will also see in the example code that you can call close from serverside.
Just kill the connection in the client by calling close() on your instance.
Trigger/Publish a serverside event that will disconnect. This would be more controlled, and let you clean up stuff.
Call the disconnect from the server on a client. Forcing a close!
See the examples at pastebin:
HTML: HowTo Close From JavaScript
Controller: HowTo Close From Server (or handle close request from client)
Related
In a Webserver for basic static website non-blocking event-driven, I don't understand the mechanics I should implement for a "new client".
When a browser connects to my socket, I get the clientfd from accept and answer with a HTTP response, but when the browser is reloaded, should it create a new connection and answer, or should it reuse the same connection and just send the new response?
I use poll to handle multiple fds, but when I reload the page its the same connection (for me this makes sense) but then I open a new tab, and it's still the same connection (It only does accept once). I'm not finding any documentation on this, and I don't have a way to test with multiple client's if it reuses the same one every time.
You can't reuse a connection from another client, new connections must always be accepted as new connections. It doesn't matter what kind of server application you're writing.
However, if the client passes the header Connection: keep-alive you should not close the connection once the response is finished, but keep the connection open for future requests from the same client.
I hope i understand correctly,
but anyway, What i personally do is create a map of sockets, each socket is a client.
Every time a socket disconnects, it's being removed from that map... and so on...
Whether to use a new connection is the browser's choice. You don't get much of a choice.
However, you can tell the browser that you don't allow it to reuse a connection, if you send Connection: close in the response. In this case, the browser is forced to open a new connection for the next request. This is the only control you have.
If you want to test several connections at the same time, you could open several different browsers, or you could use a different program, such as some HTTP load testing tool (there are many). You could also send it a web page with many images; browsers should try to download all the images using several connections at the same time.
A web server doesn't create clients. A web server has clients -- new clients trying to connect, and existing clients communicating on the sockets that it has already opened.
To handle new clients, a web server should pretty much be calling accept all the time, unless it's already handling the maximum number of clients that it's configured to handle.
As soon as you get a new connection from accept, hand it off to other threads to process and call accept again.
I would like to do some one way streaming of data and am experimenting with SSE vs Websockets.
Using SSE form a golang server I'm finding it confusing on how to notify the client when sessions are finished. (eg the server has finished sending the events or the server suddenly goes offline or client looses connectivity)
One thing I need is to reliably know when these disconnect situations. Without using timeouts etc.
My experiments so far , when I take the server offline the client gets EOF. But I'm having trouble trying to figure out how to signal from the server to the client that a connection is closed / finished and then how to handle / read it? Is EOF a reliable way to determine a closed / error / finished state?
Many of the examples with SSE fail to show client good client connection handling.
Would this be easier with Websockets?
Any experiences suggestions most appreciated.
Thanks
The SSE standard requires that the browser reconnect, automatically, after N seconds, if the connection is lost or if the server deliberately closes the socket. (N defaults to 5 in Firefox, 3 in Chrome and Safari, last time I checked.) So, if that is desirable, you don't need to do anything. (In WebSockets you would have to implement this kind of reconnect for yourself.)
If that kind of reconnect is not desirable, you should instead send a message back to the client, saying "the show is over, go away". E.g. if you are streaming financial data, you might send that on a Friday evening, when the markets shut. The client should then intercept this message and close the connection from its side. (The socket will then disappear, so the server process will automatically get closed.)
In JavaScript, and assuming you are using JSON to send data, that would look something like:
var es = EventSource("/datasource");
es.addEventListener("message", function(e){
var d = JSON.parse(e.data);
if(d.shutdownRequest){
es.close();
es=null;
//Tell user what just happened.
}
else{
//Normal processing here
}
},false);
UPDATE:
You can find out when the reconnects are happening, by listening for the "close" event, then looking at the e.target.readyState
es.addEventListener("error", handleError, false);
function handleError(e){
if(e.target.readyState == 0)console.log("Reconnecting...");
if(e.target.readyState == 2)console.log("Giving up.");
}
No other information is available, but more importantly it cannot tell the difference between your server process deliberately closing the connection, your web server crashing, or your client's internet connection going down.
One other thing you can customize is the retry time, by having the the server send a retry:NN message. So if you don't want quick reconnections, but instead want at least 60 seconds between any reconnect attempts do this have your server send retry:60.
I have setup an Indy IdFTP Client to a FileZilla FTP Server.The client tries to Connect on startup of my app and, If it fails, keeps retrying every few seconds for the lifetime of the app. In addition, I need to detect if I lose the connection and, again, keep trying to re-establish the connection. This is where I am having a problem.
I have added an OnStatus event handler which seems to fire for all the event types except hsDisconnecting and hsDisconnected.
I also have an OnDisconnected event handler which only fires when I have locked the Server, in this case, when I try to connect, it fires the OnConnected then immediately fires the OnDisconnected. However, if I set the Server as not Active after the initial successful connection, the server tells me it has disconnected me but I do not get an event in my code so I don't know I need to start trying to connect again? Am I wrong in expecting these events in this scenario, is there something else I should be listening for?
Thank you in advance for your help.
I have a webapp, which is running in a browser. That webapp is connected to a server, which uses websockets. So the communication between the server and my client/browser is based on websockets. If some magic event occurs on the server, some webservice sends a new XML / JSON to my webapp and the new data gets displayed.
But how do i, as the client / browser, know if the connection is stil alive? Lets say i do not get any new XML for about 30 seconds. How would i know if the connection is closed/broken/server offline or everything is fine, but on the server himself no new magic event occured.
A websocket connection object has a readyState field which will tell you if the connection is still active (from the dart documentation). The readyState can be either
0 - connection not yet established
1 - conncetion established
2 - in closing handshake
3 - connection closed or could not open
You can also define an event handler for the websocket close event if this is something you'd like to handle (try to reconnect, etc).
3 ways:
rely on TCP to detect loss of connectivity, which will ultimately pop up in JS onclose event
send WebSocket pings from server .. browsers will reply with WS pongs, loss of connectivity is probably more robustly detected also on client side
send app level heartbeats from browser to server, server need to have logic to reply. you can't trigger WS pings from browsers (in JS)
My Co-worker told me that AJAX connection alive until a user closes his/her browser. As far as I know, ajax connection closes its connection when its request has completed. I tested it with Firebug and a HTTP monitoring tool, I noticed that AJAX connection closes itself.
Is he correct????
Ajax is just like any other request, when it completes the connection is closed. Your colleague is wrong.
Note : There are connection types that allow you to keep the connection open indefinitely
Break down what AJAX is -- and XMLHttpRequest. It's a connection to a URI endpoint for some resource (image, text, whatever). Your browser closes the HTTP connection as soon as it's done.
Ajax connections closed after receiving data or if you close tab, then connections will force closed.
Here described Ajax life cycle.
Late to the party here, but this regards an issue I'm actually dealing with right now...
I have a web server running on a severely resource constrained platform (128k Flash, 48k RAM) so it can only handle one connection at a time. Further connections are not handled until the current one is closed. Also, it does not force Connection: close on certain URLs because of a low latency requirement. In general, only one thing talks to the device at a time.
AJAX connections follow whatever rules the browser sets for other connections. In my case, I'm testing a web page that uses AJAX to read one of the keep-alive-allowed URLs once per second, and the browser does not close the connection until several seconds after the window is closed. As a result, other clients wait indefinitely.
So don't assume that XHR connections are closed when complete. They might not be; Firefox 21 sure isn't closing them.
My current problem is that I want to force my AJAX requests to close the socket on completion, and I'm using jQuery's .ajaxSend() pre-send hook to set the Connection: close header. The AJAX seems to be working, but when another client tries to connect, it gets "connection reset by peer", so I'm wondering if Firefox doesn't notice the "Connection: close" header on the XHR request and keeps its end of the socket open (until it times out after approximately three seconds) even after the server has closed its side.
Using JQuery to make AJAX requests, some connections are maintained until the following AJAX call. This can become a real problem when the server holds streams open until the response's close event fires.