I have gotten a basic implementation of this working though for the time being I had to avoid idiomatic Play/Akka implementations as I think the appropriate approach is beyond the scope of what I’m looking into at this stage. Because of this it does highly resemble GuacamoleHTTPTunnelServlet.
At first I think I misinterpreted the HTTP implementation and expected the XMLHTTPRequests to be long-lived (2 requests, one for read and one for write) while data is streamed between client/server. Are the HTTP connections long-lived or is it expected that there will be thousands of requests while connected/using a tunnel? I understand there is a web socket implementation which I’ve also been looking into but similarly would require an approach using Akka graphs which I’m only beginning to learn and for the moment I’m only looking into prototyping or proof-of-concept work. Thanks Christopher > On Dec 28, 2020, at 11:13 PM, Christopher Speck <[email protected]> wrote: > > Hi Mike thank you for the response, > >> On the other hand, if there is a clean way to extract just the request >> handling core of GuacamoleHTTPTunnelServlet such that it can be reused by >> any HTTP request handling API, including the provided >> GuacamoleHTTPTunnelServlet, I think that would be a good approach. > > I was playing around with this a little bit and in my situation there is > unfortunately not much that could be pulled into utility methods for use with > the Play framework — the HTTP servlet is pretty well focused in scope which > made it straightforward for the port I’m working on. The use of the Play > framework is unfortunately beyond my control or I would have avoided it in > favor of standard servlets. The Play API handles all requests in an async > manner (a la Akka Streams > <https://doc.akka.io/docs/akka/current/stream/index.html>) and required > significantly different implementation of the read/write streaming which does > not lend itself for reuse with the servlet. Beyond read/write the servlet’s > only other primary responsibility is this tunnel map to handle clearing out > tunnels that have not been recently accessed. > > I think my other option is to also implement a duplicate of > GuacamoleHTTPTunnel that is accessible. I was originally afraid the class was > used elsewhere internally so stopped with the duplicating approach. Looking > at that class again it appears to only be used by the tunnel map so this > should be trivial. > > Thanks again > > Christopher
