I am using grpc for client/server communication since it supports bidirectional streaming. I have read some doc relates to that: https://grpc.io/docs/what-is-grpc/introduction/
It supports:
A simple RPC where the client request to server to receive a response
A server-side streaming RPC where the client sends a request to the server and gets a stream to read a sequence of messages back.
A client-side streaming RPC where the client writes a sequence of messages and sends them to the server, again using a provided stream
I have a case that to let server to send a query request to client to receive a response. The bi-directional is only used in streaming case not request-response case.
I couldn't find any way to support that pattern. Is this supported by grpc?
The initiator of a request is by definition the client.
To address your need:
the code currently functioning only as a gRPC server must also implement a gRPC client; and
the code currently functioning only as a gRPC client must also implement a gRPC server.
Related
When speaking from a conceptual point of view, is it standard practice to mix WebSockets and HTTP requests when making a chat application (or any application that requires real-time communication between devices)?
Imagine a scenario with a client and a server in a chat app. What would be the best approach for connecting and sending data between the client and the server? Would it be using sockets for both sending and receiving or HTTP requests for sending (so the client would get a response and then know if the message was received), and then using WebSocket for only receiving new messages?
No this is not standard practice.
If you need real-time communication between client and server you normally just use a websocket connection and keep that one open. The client can send messages to the server and receive messages through the same connection.
Using HTTP requests for sending messages to the server and receiving new messages via websocket seems odd and just adds unnecessary complexity.
Now if your server has some endpoints to subscribe for real-time data e.g. a chat room and endpoints for getting information you don't necessary want to subscribe to e.g. information about a certain user, than you can use the appropriate protocol for each endpoint
I need to implement a tcp/ip client which connects to existing tcp server with a permanent connection. the client has to send multiple requests and response arrives asynchronously. I have use netty to do the integration part. I have to ensure that the response is done for the relevant request. How to implement this using apache camel.
rest()
.consumes("application/json").produces("application/json")
.post("/tcp")
.type(RequestBean.class)
.route()
.process(this::transformTcpMessage)
.to("netty://tcp://127.0.0.1:9898")
.endRest();
This is What I need to achieve. this TCP client need to have a permeant connection and server may response asynchronously. So I need to make sure that the relevant response has been send to the relevant request.
While I'm writing a service with grpc, I'm trying to compare http/2 with websocket by server side pushing mechanism.
I know for websocket, the client will send a request with Upgrade: WebSocket and Connection: Upgrade headers to server and establish the long-lived connection. Then server will send the data freely after the connection is established.
But for grpc, as it is routed upon http/2, from the wiki page, https://en.wikipedia.org/wiki/HTTP/2_Server_Push, it says the server would need to predict the potential requests the client would send, and send a PUSH_PROMISE frame as early as possible.
Here are my two questions:
Does it mean that the server would also need to receive a corresponding response(request) from client in response to this PUSH_PROMISE header to decide if client wants to receive or decline the certain push?
In Grpc, if I have a sever side streaming, say send a message every 1 second from server. Does it mean the server need to send a PUSH_PROMISE to client every 1 second or at least before every data frame that server pushes to client?
gRPC does not currently support/use PUSH_PROMISE.
Streaming RPCs in gRPC use HTTP/2 streams; the entire RPC is contained in a request/response in HTTP. The main difference is that HTTP/2 implementations generally allow such streams to be streaming and bidirectional (the client can send more in the request after reading part of the response), while in HTTP/1 that was hit-or-miss.
In gRPC the client will always initiate the RPC. But for server-streaming the server can then reply with multiple messages over time via the stream. This would be similar to the scenario you described with websockets.
In the GPRC Concept document
http://www.grpc.io/docs/guides/concepts.html
The gRPC programming surface concept is mentioned without a definition. Anyone knows exactly what is gRPC programming surface?
Quoting their documentation:
Starting from a service definition in a .proto file, gRPC provides protocol buffer compiler plugins that generate client- and server-side code. gRPC users typically call these APIs on the client side and implement the corresponding API on the server side.
On the server side, the server implements the methods declared by the service and runs a gRPC server to handle client calls. The gRPC infrastructure decodes incoming requests, executes service methods, and encodes service responses.
On the client side, the client has a local object known as stub (for some languages, the preferred term is client) that implements the same methods as the service. The client can then just call those methods on the local object, wrapping the parameters for the call in the appropriate protocol buffer message type - gRPC looks after sending the request(s) to the server and returning the server’s protocol buffer response(s).
In short, the surface is the contract between the client and the service and its realization as the clientside layer (the stub) and the serverside implementation.
RPC protocol uses TCP as an underlying protocol and HTTP again uses TCP as an underlying protocol. So why is HTTP is widely accepted?
Why does SOAP use HTTP as an underlying protocol - why not RPC?
Remote Procedure Calls (RPC) is not a protocol, it's a principle that is also used in SOAP.
SOAP is an application protocol that uses HTTP for transport (so it won't have to think about encoding, message boundaries and so on). One of the reasons to use SOAP over HTTP is that for HTTP you usually don't need firewall rules and that the HTTP infrastructure is mature and commonly rolled out.
RPC does not require HTTP. Basically, RPC describes any mechanism that is suitable to invoke some piece of code remotely. The transport mechanism used to perform the RPC could be SOAP over HTTP. It could also be a REST call returning some JSON data over HTTP.
SOAP can also be used via Mails, and AFAIK (not sure here) the BizTalk Server should support this scenario. But even something exotical like trying SOAP over Avian Carriers can also be considered an RPC, although the latency of the latter may not be sufficient for real-world applications.
Think of an RPC as sending somehow some kind of message to a destination, in order to initiate a specific action and (optionally) getting some information back after the action has been completed. What prticular technology you choose to transmit these messages does not really matter.