gRPC C++: Which is the method to be used for notifying the grpc client about server disconnect - client-server

I'm writing a client which communicates with multiple server via gRPC. The data transfer works absolutely fine but I'm getting an exception on client side when one of the server stops abruptly. I would like to know if there is any error handling in gRPC library which can handle this server disconnection and do a clean exit from client side.
I can see methods like bool IsCancelled() const which could be used on server side to get status about client disconnection.
I need a similar method to be used on client to get notified about server disconnection.

Related

In a Web API call, if the server's reply didn't get to the client, will the server know?

A client, such as a C# program, invokes a server via its web API. The server process that is invoked does some database changes, then returns some data to the client, and the web API call finishes.
Suppose the response fails on its way to the client - for example the client dies and therefore the response can't be transmitted to the client.
In this case, will the server process get an exception from the operating system, so that it can rollback the database changes, or will the server happpily assume that the client has received the response, and commit the database changes?
The reason I am asking this, is that I don't want the server's database to be in a state that believes that the client has got the response, but the client hasn't. This will result in lost of sync between the client devices and the server.

Client could not find service in gRPC server

https://pastebin.com/7vqdrHyg greet.proto
https://pastebin.com/4PYDYZ6Q greet_grpc.pb.go
https://pastebin.com/2n6n8JjS greet_pb.go
https://pastebin.com/FPpCJEGR main.go
https://pastebin.com/CXuxG5fB handler/greet.go
I have implemented a simple grpc server using Golang. The server accepts a connection from a client and returns a simple response message.
I have a Python client that is trying to connect to the server through localhost:8080.
The gRPC code for the client and server are created with the same IDL interface.
https://pastebin.com/RLp3QUWX client.py
However, the connection is unsuccessful and I got the following error.
https://pastebin.com/Cji9Pkhj
I don't know how GreetService is called at the server side, but I assumed that the interface is defined somewhere in greet_grpc.pb.go
UPDATE: I have pushed the code to this repo for better readability.

Push data from websocket server to client

Websockets are hailed as a bi-directional process. However, whilst there are hundreds of websocket code examples on the web, they all require a request from the client(browser) to the server to get the data (like an echo server or chat).
So far, I have not found any code which will send new data (originating at the server end) to the client via an open websocket. Ideally, I would like to use a node.js server but I'm open to alternatives. Any ideas?

What happens if UI makes a rest call and the server stops?

Suppose, UI is making calls to rest service and the server stops.
Does UI come to know about the server's state?
Does UI get any response back from the server?
What difference does it make if the rest call was POST or PUT?
When REST Api is stopped,the UI/Browser/Client will show "Could not get any response
There was an error connecting to " error, irrespective of request type: PUT /POST.
To answer your questions :
Does UI come to know about the server's state?
If Server stops, you will get an error like : error connecting server. Which can be traced to multiple rootcauses. One of them can be : Server has stopped.
In case of error, Server's state can be sent to client using various error codes like:
500 Internal Server Error The 500 status code, or Internal Server Error, means that server cannot process the request for an unknown reason. Here is list of status codes for REST APis: https://www.w3.org/Protocols/HTTP/HTRESP.html
Does UI get any response back from the server?
If server is stopped, UI/Client will receive no response.
What difference does it make if the rest call was POST or PUT?
If the server has stopped, it doesn't make any difference.
You can run this scenario using a browser and running any app/REST service in your local machine.
(For this test you need not have any REST application running in your local, as you only want to test when it is stopped)
For instance, if your REST application server is up and available at port 8080, you can send request to this server by sending request form your browser : http://localhost:8080
For testing with POST/PUT collections, you can use any API Development tools like : Postman.
Let's assue your REST Api , exposes following urls :
/myPostRequest POST
/myPutRequest PUT
When you hit these urls from POSTMAN you get the same response :
POST http://localhost:8080/myPostRequest :
Could not get any response
There was an error connecting to http://localhost:8080/transition-order.
PUT http://localhost:8080/myPutRequest :
Could not get any response
There was an error connecting to http://localhost:8080/transition-order.
Client(could be UI) and Server are two dumb applications. They do and say what they are told to.
So whenever a client tries to call a server on a socket and there is no server listening to it, there is no response returned to the client. The client can interpret it in whatever way it wants. Most of the browsers show <host> refused to connect.
But if a server is listening to a socket, it responds to the client whichever way it was programmed to do. The server sends an appropriate status code and expects that the client knows how to interpret it. A server can send any random number it wants... the catch is, the client must know how to interpret it. otherwise, it's just one-way communication.
In order to provide smooth client-server communication, section 10 of RFC 2616 defines various codes with specific meaning as shown here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
These status codes are the same for all the types of Http methods.

How to structure Socket.io Authentication

I am creating an application using Flask-SocketIO at the server side and a javascript Socket.IO client. (There will also be a Python client later). I want to ensure users are authenticated before they connect to the web socket server.
I have created a PHP login form to check the username and password. If these are valid then a unique token is returned and the token is also inserted into a table on the server. The token is passed to the client side javascript, where it is submitted with the request to create a web socket connection.
As I understand it Flask-SocketIO will simply accept the connection and I need to put my validation code under the #socketio.on('connect') decorator. (I assume a server based implementation of Socket.IO works in a similar way). Therefore my code checks the submitted token against the database table and if it is valid the web socket connection is simply allowed to happen. However if the token is not valid I issue a disconnect() command. The javascript client does not try the connection again, which is what I want in this scenario.
Here is where it gets tricky...
I would like to write a disconnect handler on the client side using socket.on('disconnect', function() { //do something }); to allow the user to reconnect when the socket is broken due to a poor mobile connection for example. How can I distinguish an accidental disconnection from an intentional one due to failed validation?
Conversely, I would like to alert the user to the fact that their validation process failed. But how to distinguish that from a scenario where the the socket is broken due to a poor mobile connection?
I would like to write a disconnect handler on the client side using socket.on('disconnect', function() { //do something }); to allow the user to reconnect when the socket is broken due to a poor mobile connection for example.
There is no need for you to worry about reconnection. The Socket.IO client protocol includes reconnection support and will always try to reconnect when the connection is lost. To verify this, start your server, connect with a client, and then kill your server. A little bit later restart the server and you will see that in a matter of seconds the connection is reestablished.

Resources