My application uses a custom binary protocol which is implemented with Netty. Recently I changed it to use Netty's websocket implementation. It works quite well.
My application also has a Jetty web server included and it offers websockets, too. Now I want to reduce the opened ports my server needs and handle all http traffic with one port.
I see three options:
Use either Netty or Jetty to proxy the traffic which belongs to the other implementation.
Reimplement the custom protocol on Jetty without the use of Netty's channels and piplines.
Create a custom implementation of Netty's channels that sends and receives it's data not over a socket but the methods Jetty's WebSocketListener offers.
Since Netty provides such a good api for writing binary protocols and a proxy sounds like extra problems to me I tend using the third approach. It shouldn't be too difficult to implement even though I don't know how to do it, yet.
Any thoughts what would be the best option and how I should implement it?
Related
We have service which mostly use gRPC. So we just use netty+io.grpc and need no extra frameworks here.
But we also need to support some HTTP requests for our infrastructure team.
And I think it will be better to reuse Netty (EventLoopGroup, ChannelFactory, etc) which we already configured.
So basically I need small HTTP routing library for already configured Netty.
But most of HTTP over Netty frameworks like Vert.x, Jooby, Ratpack or Armeria, manage Netty by their-self and just too complex for my case.
It will be simpler to me just use HttpServer from JDK and doesn't care about a bit of context switches because of over creating event loops.
But I really want to get clean solution.
I'm open to any suggestions.
Grpc Server seems to be implemented using netty. Is there a way to use other implementations ?
Netty is the only supported server. You can either have two separate ports (one for your other server, one for gRPC) or could reverse proxy from your other server to the Netty server.
There is work underway (tracking issue) to allow serving using the Servlet API, so then any Servlet Container could be used. But there are restrictions, like the needing to be the root ('/') webapp. It is far enough along to test it and provide feedback, but there also may be some gaps in the implementation.
I'm looking at the Java API for MarkLogic, which I assume leverages the HTTP protocol for database connections. Is it possible to establish a connection over TCP? If not with the Java API, is it possible to interrogate the database by any means over TCP?
Our current architecture is based on a Microservice architecture concept, and includes a number of stages in any given process flow through the system, including Queueing, Message-brokering, etc. Given the number of steps, I'd like to optimise traffic-speed insofar as possible by leveraging TCP connections.
The Java API uses the REST Application services on MarkLogic which is fully HTTP 1.1 compliant and TCP/IP.
Not sure what else you are asking for.
For programs written in Java the Java API is the recommended API for most uses
http://developer.marklogic.com/products/java
You can also use the REST services directly, but the Java API adds a lot of Best Practice and exposes a higher level of abstraction to make coding simplier.
You can use the REST API from any application that can do HTTP
http://docs.marklogic.com/guide/rest-dev/intro
But its a bit more work as you have to construct your HTTP messages directly.
You can also create your own HTTP interface and access it through TCP/IP (HTTP) by making an HTTP App Server (written in XQuery).
Finally if you want very low level but effecient access, using Java or .NET you can use the XCC interface which is more tedious to use but provides a lower level feature for advanced users. This requires the Java or .NET library as the protocol is not documented.
https://developer.marklogic.com/products/xcc
What language are you going to be using and what kinds of operations ? That can help focus on which API is best for you.
-David Lee
HTTP is built on TCP. So by definition all HTTP connections are over TCP.
If you'd like a proprietary protocol instead of HTTP, one option is to forget the fact you learned that the Java API uses HTTP and imagine it uses TCP directly. :)
If you really want a proprietary protocol over TCP, you can use the XDBC protocol in combination with the XCC client. By default XDBC uses a wire protocol on TCP that isn't published.
Hi I am working with java and thrift. I see that there are 2 parts to the thrift Async system one is the Service.AsyncIface and another is Service.AsyncClient. From the thrift implementations for AsyncClient, I see that the non blocking interface is wired up and ready to go on the library side. I just made a simple client using TNonBlockingSocket and it works
1) Do we care if the existing thrift server for the Service is blocking or non blocking? Why?
2) If we want to wrap a nonblocking client framework in things like retry logic, host discovery, policy management etc what would be the ideal framework?
From client's point of view there's no difference in communication with sync or async server given that protocols and transports are compatible. That's because the client should receive the same serialized response from both sync/async servers. For example, if you do JSON over HTTP request, you don't really care if the server is sync or async.
Finagle is a good choice if you're interested only in JVM languages (and it's the only framework I'm aware of that has required feature set).
I am new to WebSockets with jetty, before I have used node.js together with socket.io to create a WebSocket Server. But due to different requirements I will have to use a java WebSocketServlet/WebSocket and was doing well so far using maven, jetty and the jetty-websocket plugin. My problem is, that I don´t found anything what was comparable to socket.io's socket.on(event, fn) implementation for the java solution. I would like to have the same possibility to react on different events fired from the client like "new", "addthis", "jointhat", ... send with some data as json or as POST param in the body. Is there any possibility or WebSocket Implementation which could do the same as socket.io?
Doing this "channel" stuff where I can implement the eventhandling on server side?
There is no custom event in WebSocket spec, and socket.io just follows their own protocol supporting custom event - https://github.com/LearnBoost/socket.io-spec
As far as I know, there is no Java implementation supporting custom event listening.
However, with Atmosphere, you can use socket.io client with Java web server, but I have not tested. https://github.com/Atmosphere/atmosphere/wiki/Getting-Started-with-Socket.IO
You might want to use other library in the client side like the jQuery Socket, if you want to control Jetty's WebSocketServlet directly. - https://github.com/flowersinthesand/jquery-socket/tree/master/samples/jetty-ws
Jetty's websocket implementation is only concerned with handling the basics of websocket.
Binary Messages (with fragmenting)
Text Messages (with fragmenting)
Ping / Pong
Close
There's been some brief discussion on supporting various new websocket subprotocols (odd name), such as WAMP (websocket application messaging protocol). But those would just be built on top of the basic websocket layer.
Another choice is to use something with a full channel api like CometD and just configure it to use websocket and not fallback into older communication formats.