Thrift provides several different non-blocking server models, like TNonblockingServer, THsHaServer, and TThreadedSelectorServer. But, I'd like to enable SSL on the server. It seems SSL only works on blocking servers in Thrift.
Anyone has any clues of a non-blocking SSL server in Thrift? Java example would be highly appreciated.
One alternative to worrying about SSL in your Java App is to stand up something like nginx (http://wiki.nginx.org/SSL-Offloader) as a reverse proxy.
This has the upside of your application not needing to care about SSL but does require one more layer in your stack.
Clients will connect to the nginx server instead of directly to your client and nginx will forward those connections to your Thrift server.
You don't necessarily need two different servers for this approach, just configure your Thrift server to only listen on localhost (127.0.0.1 for ipv4) and have nginx listen on your external interfaces and forward to localhost.
Edit: client -> server in last paragraph
Related
I would like to know if with RMI a server can remotely invoke a method from any of his clients, or just the clients can do this with their server.
Regardless of any implications of such a design decision, it is possible to use RMI between two JVMs that are accessible through the network. This means that if the server can access its clients through the network, and the clients have a JVM available and can act as RMI servers, then it is possible to make a client or each of the clients an RMI server and have the "server" communicate with each one of them.
Assuming the server is an application server i advise you to use the Java Messaging Service (JMS) to allow the server communicate with the client systems.
Yes, firewalls permitting. The client has to export its callbacks as remote objects and supply them to the server, typically via some registerCallback() API. Then the server just calls the methods.
However firewalls to the Internet typically don't permit callbacks, and if they do there may be issues with port numbers: you will probably need the clients to export their remote objects on a specific port which is opened in the firewall, typically 1099.
Besides the solution provided by melc, it is also possible to achieve a full duplex communication between the client and server by using WebSockets. They are now part of the Java EE 7 specification, you can read something more about them here: http://docs.oracle.com/javaee/7/tutorial/doc/websocket.htm. There are also other solutions, like Comet, or JMS (which is used like webosckets in RichFaces).
I intend to have .NET thick clients running inside a Windows domain connect to a Java server via a straight TCP connection (protocol will be custom Google Protocol Buffer messages). I'm looking at how I can authenticate these clients without requiring further credentials be entered by the users (in other words, support single sign-on).
My initial thinking was to use Kerberos, but I'm not even certain that it's possible or ultimately secure over straight TCP. Can anyone comment on this? Is it possible? Are there any examples out there of how to achieve this, both client-side and server-side?
Kerberos doesn't run over 'straight TCP'. It uses an encryption protocol. See the JGSS-API, built into the JRE.
I'm trying to set up an Apache Mina FTP server in my continuously-deployed Java application. I'd like to be able to update and deploy it without users experiencing FTP downtime. I suspect this involves some sort of proxy (ProxyConnector?) to handle requests and delegate them between two copies of my FTP server. When a change is made, one copy should be updated and restarted before the other in order to maintain uptime.
I haven't been able to find any examples of this with Apache's Mina FTP server. Is this possible? Where can I find examples? Thanks.
You need a standard proxy server which listens to the two FTP ports and passes the connection to one of two FTP servers, you could even implement fail over or load balancing the proxy. The simplest TCP proxy just copies what ever it gets from one socket to the other in both directions.
The code is the same, regardless of what TCP server you are proxying or what software it uses.
I'm currently trying to implement a Http Tunnel between a Java Client(That Includes Netty) to a server, so I would like to know if there's any server that is also based on Netty to support this Tunnel or should I build the server side my self?
I recently came upon this: http://www.jcraft.com/jhttptunnel/. Perhaps helps you...
Now netty includes an example of an HTTP Tunnel. The server must be aware (in some way) of it to work. The documentation of the API for HTTP tunneling (client and server) is available at org.jboss.netty.channel.socket.http
I have a web-service endpoint and a http connector on port X.
At some point this endpoint needs to switch to https, but on the same port!
(I know this is not the normal way of doing things, but this is what my clients expect from an old server they are using...)
Is there a way to do it in tomcat?
This is not possible with Tomcat.The HTTPS connector will accept SSL connection only.
We have such a proxy developed in house. It's not that hard to do. You just need to check the first incoming packet. Looking for the pattern of SSL handshake. We only look for CLIENT_HELLO. Once you figure out the protocol, you can forward the request accordingly.
This is really ugly. You shouldn't do it if all possible. We have to do it because the legacy clients do this and it's impossible to upgrade them all.
There is such a thing as HTTPS upgrade, whereby a plaintext HTTP connection is upgraded to HTTP by mutual agreement after it has been formed. Is that what you mean? If so, Tomcat doesn't seem to support it out of the box, and neither does Java out of the box either. You can probably write yourself a Tomcat Connector that will do it; on the client end you have a more interesting problem ;-)
But I would ask why? Ports aren't so expensive that you can't use two.
You don't need to run the HTTP & HTTPS on same port, Configure the Tomcat to redirect requests to HTTPS in server.xml file.
well I wonder why they are NOT usually on the same port! wouldn't that be easier?
the reason is probably that related Java APIS (javax.net.ssl) don't allow that; you must have different server sockets. are there any alternative SSL impls for Java? I'm not aware of any.