I have two desktop apps on the same machine, let's call them Client and Server. When Windows goes into shutdown I would like to have the Client do some short housecleaning with the Server. Client knows it's closing time because in OnFormClosing the FormClosingEventArgs.CloseReason is CloseReason.WindowsShutDown. But in the mean time the Server may be forcefully killed by the OS. Is it possible to have the Server alive for as long as possible, so that all the Clients can finish their jobs, but not halt the shutdown entirely?
The Server does not know which Clients are alive and in need of housecleaning.
Both Client and Server should not cause the Windows to show the message saying that the app is preventing the Windows from shutting down.
I guess I'm asking for some Windows API calls that can negotiate with Windows to kill the process last if possible, but any working solution is welcome. The Client is written in C# and the Server is written in C++.
The Server should be keeping track of the Clients that are connected to it. So, if your apps are busy performing housecleaning, they ARE blocking shutdown, even if just momentarily. So what is wrong with letting Windows show a message to the user saying that?
When the Server gets notified of an imminent shutdown, have it call ShutdownBlockReasonCreate() if there are any Clients connected. Regardless of whether the Clients perform housecleaning or not, when the last Client disconnects then the Server can call ShutdownBlockReasonDestroy().
The obvious solution is to make the server a Windows service.
As a stop-gap solution you can try SetProcessShutdownParameters.
This function sets a shutdown order for a process relative to the other processes in the system.
Related
We have a node instance that has about 2500 client socket connections, everything runs fine except occasionally then something happens to the service (restart or failover event in azure), when the node instances comes back up and all socket connections try to reconnect the service comes to a halt and the log just shows repeated socket connect/disconnects. Even if we stop the service and start it the same thing happens, we currently send out a package to our on premise servers to kill the users chrome sessions then everything works fine as users begin logging in again. We have the clients currently connecting with 'forceNew' and force web sockets only and not the default long polling than upgrade. Any one ever see this or have ideas?
In your socket.io client code, you can force the reconnects to be spread out in time more. The two configuration variables that appear to be most relevant here are:
reconnectionDelay
Determines how long socket.io will initially wait before attempting a reconnect (it should back off from there if the server is down awhile). You can increase this to make it less likely they are all trying to reconnect at the same time.
randomizationFactor
This is a number between 0 and 1.0 and defaults to 0.5. It determines how much the above delay is randomly modified to try to make client reconnects be more random and not all at the same time. You can increase this value to increase the randomness of the reconnect timing.
See client doc here for more details.
You may also want to explore your server configuration to see if it is as scalable as possible with moderate numbers of incoming socket requests. While nobody expects a server to be able to handle 2500 simultaneous connections all at once, the server should be able to queue up these connection requests and serve them as it gets time without immediately failing any incoming connection that can't immediately be handled. There is a desirable middle ground of some number of connections held in a queue (usually controllable by server-side TCP configuration parameters) and then when the queue gets too large connections are failed immediately and then socket.io should back-off and try again a little later. Adjusting the above variables will tell it to wait longer before retrying.
Also, I'm curious why you are using forceNew. That does not seem like it would help you. Forcing webSockets only (no initial polling) is a good thing.
I have a high performance client server system programmed from the scratch. i am still improving my system. the server using io overlapping to handle connections. the server correctly handles disconnections and resource deallocations. at the client side i used shutdown command with sd_receive to notify the server that the client has no data to receive after final send from the client. this works well. and server detects that as a graceful disconnection. rarely i have observed when the connection is very slow the server doesn't detect this. I feel that the shutdown partial closure doesn't reach the server. how can i handle this. this is important the server shouldn't contain this kind of connections if so the server can not be stopped. and i do not want to close all such connection by force.
at the client side i used shutdown command with sd_receive to notify the server that the client has no data to receive after final send from the client.
It doesn't do that.
this works well
It doesn't work at all. The shutdown command with SD_RECEIVE that you're using is completely pointless. A close, or a shutdown with SD_SEND or SD_BOTH, sends a FIN: shutdown with SD_RECEIVE does exactly nothing on the wire, and specifically it does not 'notify the server' of anything.
I feel that the shutdown partial closure doesn't reach the server.
It never reaches the server. Your code doesn't work the way you think it does. What reaches the server is the FIN, which in turn is the result of the close, not the shutdown SD_RECEIVE.
What you need here is a read timeout at the server end. As you're using select() or whatever is delivering you the events, you will have to implement the timeout manually yourself.
I have looked all over the place and have never seen an example of how to do this, even tho it's alluded to in blogs. But examples are never given.
I have a .Net remoting client that is connected to a server which is published as a well known type over tcp/ip. It holds an object reference to the server and instantiates it via the new operator.
If the server crashes, the easy part is detecting this, just catch the error.
Looping and waiting for the server to come back up will again be no problem.
But how to reset / reboot / unregister then re-register the remoting stack on the client?!?
If the client is restarted after the server comes back up, it works again, but obviously I want to just reconnect within the client application and not have to reboot it.
Windows Communication Foundation does not have the same issue. When the server goes down, the connection can be programatically re-established.
I have observed the following behavior in Firefox 4 and Chrome 7:
If the server running the websocket daemon crashes, reboots, loses network connectivity, etc then the 'onclose' or 'onerror' events are not fired on the client-side. I would expect one of those events to be fired when the connection is broken for any reason.
If however the daemon is shutdown cleanly first, then the 'onclose' event is fired (as expected).
Why do the clients perceive the websocket connection as open when the daemon is not shutdown properly?
I want to rely on the expected behavior to inform the user that the server has become unavailable or that the client's internet connection has suffered a disruption.
TCP is like that. The most recent WebSockets standard draft (v76) has a clean shutdown message mechanism. But without that (or if it doesn't have a chance to be sent) you are relying on normal TCP socket cleanup which make take several minutes (or hours).
I would suggest adding some sort of signal handler/exit trap to the server so that when the server is killed/shutdown, a clean shutdown message is sent to all connected clients.
You could also add a heartbeat mechanism (ala TCP keep alive) to your application to detect when the other side goes away.
This should work if multiple windows are open.
My application is in J2EE.
I already tried some javascript like on window.unloadn but this kind of solution is not solid.
If you mean on the server side, the best way is to implement a heartbeat. If none of the windows from this webapp are open, nothing sends a heartbeat, and a server after some time will know the app is disconnected.
If you mean on the client side, there's no 100% reliable way, since the browser might die from external causes (kill/crash/reboot), but a timed-out cookie that is updated regularly in a heartbeat-like fashion might work
HTTP is a stateless, meaning you can't tell when a browser is closed.
Your attempt to use window.onunload does not always work because the browser could exit before executing your event handler.
The technology used to find out if a user has closed their browser (or a best guess) is to use timeouts. Sessions will automatically timeout (this is configurable) - in asp.net the default is 20 minutes. If there is no activity, the timeout kicks in.