On Sat, Nov 8, 2025 at 7:39 AM Palaash Jain <[email protected]> wrote:
> Hi, > > In Guacamole’s architecture — why do we have an intermediary Java servlet > between the client and the server instead of letting the client communicate > directly with the server. > There are a couple of reasons for this: * guacd only speaks the Guacamole protocol, and does it over a simple TCP socket. Browsers have a very limited set of protocols that they natively speak. To allow the Guacamole web application, running in the browser, to communicate with guacd, you have to tunnel that Guacamole protocol inside of a protocol that the browser understands - HTTP(S) and/or WebSockets (WS(S)). Probably the most core aspect of the Java servlet is that core functionality of tunneling the Guacamole protocol within HTTP(S)/WS(S) so that the browser can talk to guacd. * guacd implements very few of the security measures you'd want implemented in an Internet-based application, like authentication and authorization. The Java servlet performs these tasks, providing a layer of security between the Internet-based clients and the back-end guacd system. It handles creation of users and groups, interaction with various external authentication mechanisms, and authorizing users to create tunnels. * guacd also doesn't do anything in the way of storing connections persistently. The Java Servlet handles the connection storage mechanisms, interfacing with databases, LDAP, and/or JSON endpoints to create connections, store the parameters of those connections, etc., and then pass that information back to guacd when a user initiates a connection. I think that tackles most of the "what" the Java servlet does, but the next question - and probably what you really want to know - is the "why." > What factors influenced the decision to include the servlet, and why was > Java chosen for it? Was it mainly for robustness or reliability? > I can try to answer this, however Mike may be able to provide some more historical context as to why he made the decision to go with the Java servlet. Most of the items above can be - and are in many other pieces of software - written in C/C++ or other C-like languages. That said, I see a few reasons why Java is better-suited for this: * Java was designed by Sun with the Internet in mind, and continues that heritage to the present. Many of the items that are mentioned above are much more easily accomplished in Java than they would be in similar C code. The HTTP tunnel and all of the REST API functionality that drives the items I mentioned above (tunneling Guacamole protocol, user and connection management, etc.) are almost native to Java, particularly Java Servlet environments like Tomcat. While doing the equivalent in C/C++ is certainly possible, and there are libraries that others have written to handle it, I would imagine the amount of code required to accomplish it would be substantial and complex as compared to the Java code. * Related to that, the ability to easily extend that Java Servlet to do other things - interact with various authentication or auditing mechanisms, adjust the user interface, etc. - is made possible by the wide range of Java libraries that already exist to interface with other things. The Maven build system and repositories contain a vast number of freely-available Java libraries that provide interfaces or other functionality - databases, LDAP, RADIUS, Duo, SAML, OpenID, etc. Again, while C/C++ libraries do exist for many of these items, using and implementing that same functionality with those libraries is more complex than doing the same with Java code. -Nick >
