There's a property called SocketsHttpHandler.EnableMultipleHttp2Connections in ASP.NET's grpc library which enables a channel to create additional http/2 connections when the concurrent stream limit is reached. Is there anything available in Go which could help me achieve the same?
In grpc-go library's documentation, there's no details of how to create grpc channels also.
There's no existing API in gRPC-Go for the same functionality.
The closest you can do is to make a resolver or balancer to create multiple connections. But it won't know about the stream limit.
Documentations and examples are available in the repo:
https://github.com/grpc/grpc-go/tree/master/examples
https://github.com/grpc/grpc-go/tree/master/Documentation
Related
As far as I can tell, Firestore uses protocol buffers when making a connection from an android/ios app. Out of curiosity I want to see what network traffic is going up and down, but I can't seem to make charles proxy show any real decoded info. I can see the open connection, but I'd like to see what's going over the wire.
Firestores sdks are open source it seems. So it should be possible to use it to help decode the output. https://github.com/firebase/firebase-js-sdk/tree/master/packages/firestore/src/protos
A few Google services (like AdMob: https://developers.google.com/admob/android/charles) have documentation on how to read network traffic with Charles Proxy but I think your question is, if it’s possible with Cloud Firestore since Charles has support for protobufs.
The answer is : it is not possible right now. The firestore requests can be seen, but can't actually read any of the data being sent since it's using protocol buffers. There is no documentation on how to use Charles with Firestore requests, there is an open issue(feature request) on this with the product team which has no ETA. In the meanwhile, you can try with the Protocol Buffers Viewer.
Alternatives for viewing Firestore network traffic could be :
From Firestore documentation,
For all app types, Performance Monitoring automatically collects a
trace for each network request issued by your app, called an HTTP/S
network request trace. These traces collect metrics for the time
between when your app issues a request to a service endpoint and when
the response from that endpoint is complete. For any endpoint to which
your app makes a request, Performance Monitoring captures several
metrics:
Response time — Time between when the request is made and when the response is fully received
Response payload size — Byte size of the network payload downloaded by the app
Request payload size — Byte size of the network payload uploaded by the app
Success rate — Percentage of successful responses compared to total responses (to measure network or server failures)
You can view data from these traces in the Network requests subtab of
the traces table, which is at the bottom of the Performance dashboard
(learn more about using the console later on this page).This
out-of-the-box monitoring includes most network requests for your app.
However, some requests might not be reported or you might use a
different library to make network requests. In these cases, you can
use the Performance Monitoring API to manually instrument custom
network request traces. Firebase displays URL patterns and their
aggregated data in the Network tab in the Performance dashboard of the
Firebase console.
From stackoverflow thread,
The wire protocol for Cloud Firestore is based on gRPC, which is
indeed a lot harder to troubleshoot than the websockets that the
Realtime Database uses. One way is to enable debug logging with:
firebase.firestore.setLogLevel('debug');
Once you do that, the debug output will start getting logged.
Firestore use gRPC as their API, and charles not support gRPC now.
In this case you can use Mediator, Mediator is a Cross-platform GUI gRPC debugging proxy like Charles but design for gRPC.
You can dump all gRPC requests without any configuration.
For decode the gRPC/TLS traffic, you need download and install the Mediator Root Certificate to your device follow the document.
For decode the request/response message, you need download proto files which in your description, then configure the proto root in Mediator follow the document.
I am trying to get some metrics using the java-grpc-prometheus library.
I would like to get some metrics like below
gRPC sessions,
no of calls,
respective duration,
no of API calls been made towards internal apis,
timeouts,
interface resets
My question is we are using bi-directional Streaming API and I read that it is setup on a single TCP session which is reused by the clients. How do I know how many client sessions have been initiated?
Get all root channels using Channelz.GetTopChannels() which will give you all client sessions.
A short introduction to Channelz
My backend generates log on processing some data and i would like to show it as a console in my frontend.
How can i implement a method that can listen to multiple response till a certain parameter is true from backend on a single http request in angular 6.
you can make use of WebSocket, i.e. make websocket connection with the your backend and get data, this is kind of push mechanism where server push data to on connection and client get data as new data is available in connection.
it not possible with help of single http request as it follows pull mechanism. so you will get data which are available. to get new data you have to perform another http request.
Unfortunately, an HTTP request cannot remain open listening for multiple responses, once it receives a response it will close the connection.
Fortunately, you can use websockets.
Implementing websockets is not too difficult, and there are many tutorials for implementing with Angular such as this one: https://tutorialedge.net/typescript/angular/angular-websockets-tutorial/
I'm not sure what back end technology you're using, but most modern ones have websocket support.
If you're not familiar with websockets in general, checkout this article: https://medium.com/#dominik.t/what-are-web-sockets-what-about-rest-apis-b9c15fd72aac
“WebSockets” is an advanced technology that allows real-time interactive communication between the client browser and a server. It uses a completely different protocol that allows bidirectional data flow, making it unique against HTTP.
The article also compares/contrasts it to HTTP, so it may give you a better understanding of HTTP as well.
I am currently using PHP / CURL on the back-end to update values in Firebase. We use Firebase primarily as a JavaScript layer so we can show browser and app clients real time status progression of jobs we process.
We've gotten to the point where we're doing quite a bit of status updating using CURL from our back-end and I feel we are close to the threshold where establishing a persistent connection between Firebase and our server would be more efficient than opening and closing dozens of HTTP requests per minute.
Is there anyway to do this with Firebase right now?
Firebase has server-side SDKs for Java and Node.js. If you can't use those, the REST API is your only alternative.
If you'd like to listen for data over REST, you can use Firebase's REST Streaming API, which uses a long-lived HTTP connection to return a stream of events. It is similar to the Firebase SDKs, but it can only attach a single listener per connection, and you'll still need separate requests for write operations.
That last part seems to the crux of your problem. So I'm afraid there really aren't any alternatives from using the SDKs as I mentioned. In my testing using HTTP requests for frequent small (although in my case admittedly read) operations was quite fast.
On the engine.io website it says:
Engine.IO is the implementation of transport-based
cross-browser/cross-device bi-directional communication layer for
Socket.IO.
What does "transport-based" mean? I presume simply that it uses TCP?
It means the ability to use different underlying transports to support the Socket.IO api. The two core transports that it uses are polling: XHR / JSONP polling transport, and websocket: WebSocket.
From the docs:
The main premise of Engine, and the core of its existence, is the
ability to swap transports on the fly. A connection starts as
xhr-polling, but it can switch to WebSocket.
The central problem this poses is: how do we switch transports without
losing messages?
Located here