It depends on what you mean with "How it works" and what the "client" is.
My Vert.x application runs on a Raspberry Pi, the clients are mobile phones, tablets, and desktop computers running a web browser.
1. If the server goes down and a client tries to connect, it receives a "service down"-page that are provided by the Nginx reverse proxy that sits in front of my Raspberry Pi server.
2. If the client has downloaded the application and are running it in the web browser when the server goes down, it work as I haved described before with the client trying to reestablish the connection to the server endlessly.
Visually for the user I flip a icon between connected and disconnected depending on if "onopen" or "onclose" was executed last, so the user can see if he/she are connected or not.
In case #1, I have plans to cache the client code in a "service worker"(
https://developers.google.com/web/fundamentals/getting-started/primers/service-workers) that would allow the user to start the webapp and use old cached data even if the server is down, and then receive fresh data when the server comes up. The next best thing it to host all static files (HTML, Javascript, CSS) on a separate web server, that would allow the client to load the webapp while the Vert.x API-service is down, old data could be cached and used from LocalStorage.
// Henrik