I am looking for an approach to enable SSL on demand for gRPC.
Netty doc shows this can be done by adding a custom ByteToMessageDecoder handler, reading through the initial bytes, and making decisions on the fly.
Does grpc-java support port unification? From my initial dig at the code, the server-starter doesn't seem to expose any interface to inject custom handlers.
Related
We have a SpringIntegration workflow with restful HTTP inbound calls and outbound calls. The workflow is mostly expressed with XML declarations of channels, chains, a splitter and an aggregator.
In the Servlet realm, we use the http:inbound-gateway and http:outbound-gateway components for input/output to the internal workflow. This seems to work well using SpringBoot autoconfiguration for Tomcat/Jetty/Undertow.
We've been trying the Reactive realm, using webflux:inbound-gateway and webflux:outbound-gateway components on the same internal workflow. This seems to work OK for tomcat and jetty servers but getting no responses from netty and some errors from undertow. I have yet to discover why we are getting errors from the last two configurations.
What I'm wondering is if the same internal workflow can be hooked up to reactive or servlet components without requiring changes. We do use a splitter/aggregator, and my reading of the SpringIntegration documentation sections on WebFlux hasn't quite cleared up for me if these constructs can be used in both realms. ( https://docs.spring.io/spring-integration/reference/html/reactive-streams.html#splitter-and-aggregator )
Any pointers on this subject?
The webflux:inbound-gateway is a server side of HTTP protocol. Has to be used in the Reactive Streams HTTP server environment. Not sure about Undertow and Jetty, but Tomcat works in the simulating mode. I usually use an io.projectreactor.netty:reactor-netty-http.
The webflux:outbound-gateway is a client side of HTTP protocol. It is fully based on the WebClient and doesn't matter in what environment it is used.
same applies for a splitter and aggregator components: they don't require any server implementation and they don't expose any external ports to worry about some specifics. Can simply be used in the reactive stream definition and in regular flows.
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
For a while now I have been implementing a RESTful API in the design of my project because in my case it is very useful for others to be able to interact with the data in a consistent format (and I find REST to be a clean way of handling requests). I am now trying to not only have my current REST API for my resources, but the ability to expose some pieces of information via a bidirectional websocket connection.
Upon searching for a good .net library to use that implements the websocket protocol, I did find out about SignalR. There was a few problems I had with it (maybe specific to my project?)
I want to be able to initialize a web socket connection through my
existing REST API. (I don't know the proper practice to do this, but
I figured a custom header would work fine) I would like them (the
client) to be able to close the connection and get a http response
back (101?) to signify its completion.
The problem I had with SignalR was:
that there was no clean way outside of a hub instance to get a user's connection id and map it to a external controller where the rest call made affects what piece of data gets broadcasted to the specific client (I don't want to use external memory)
the huge reliance on client side code. I really want to make this process as simple to the client and handle the majority of the work on the server side (which I had hoped modifying my current rest api would accomplish). The only responsibility I see of a client is to disconnect peacefully.
So now the question..
Is there a good server side websocket library for .net that implements the latest web socket protocol? The client can use any client library that adheres to the protocol. What is the best practice to incorporate both web socket connections and a restful api?
ASP.NET supports WebSockets itself if you have IIS8 (only Windows 8/2012 and further). SignalR is just a polyfill,
If you do not have IIS8, you can use external WebSocket frameworks like mine: http://vtortola.github.io/WebSocketListener/
Cheers.
I'd like my Pinocc.io lead scout to make a POST request (e.g. to inform a remote service of an event that has been triggered).
Note that I don't want to listen to a constant stream the results (as detailed here) as I don't want to be constantly connected to the HQ (I'm going to enable the wi-fi connection only when required to minimize battery usage), and the events I'm detecting are infrequent.
I would have thought that this is a very common use case, yet I can find no examples of the lead scout POSTing any messages.
I posted the same message directly on the Pinoccio website and I got this answer from an Admin
Out of the gate, that's not supported via HQ. Mainly because to get as
real-time performance between API/HQ and a Lead Scout, it makes most
sense to leave a TCP socket open continually, and transfer data that
way. HTTP, as you know, requires a connection, setup, transfer, and
teardown upon each request.
However, doesn't mean you can't get it
working. In fact, you can do both if you wanted—leave the main TCP
socket connected to HQ, and have a separate TCP client socket connect
to any site/server you want and send whatever you like. It will
require a custom Bootstrap, but you can then expose any aspect of that
functionality to HQ/ScoutScript directly.
If you take a look at this code, that's the client object you'd use to open an HTTP connection.
So in a nutshell the lead scout cannot make a POST request. To do so you'll need to create a custom bootstrap (e.g. using the Arduino IDE).
Stupid question, but just making sure here:
When should I use TCP over HTTP? Are there any examples where one is better than the other?
TCP is full-duplex 2-way communication. HTTP uses request/response model. Let's see if you are writing a chat or messaging application. TCP will work much better because you can notify the client immediately. While with HTTP, you have to do some tricks like long-polling.
However, TCP is just byte stream. You have to find another protocol over it to define your messages. You can use Google's ProtoBuffer for that.
Use HTTP if you need the services it provides -- e.g., message framing, caching, redirection, content metadata, partial responses, content negotiation -- as well as a large number of well-understood tools, implementations, documentation, etc.
Use TCP if you can't work within those constraints. However, if you use TCP you'll be creating a new application protocol, which has a number of pitfalls.