Manoj, Guacamole will not send image data if the connection is idle. Images are sent only when content on the screen is changing and only for the part of the screen that changed.
Earlier in this conversation, you described 90 Kbps. This has now become 1.8 Mbps. I assume you are now measuring something completely different, and the connection is extremely active? I'm still not seeing what problem you're trying to solve. The fact that this doesn't match our own measurements notwithstanding, slightly higher idle bandwidth usage is unlikely to be the cause of any actual problem. Framing overhead could easily cause Guacamole's bandwidth usage to be higher than RDP when things are idle, but would be become negligible when things are actually in use, at which point Guacamole's bandwidth usage would be expected to be lower than the underlying RDP connection. Perhaps you could configure the Guacamole connection in question to capture a screen recording? If you capture a screen recording via Guacamole and send it our way, that will essentially be a raw protocol dump and should allow us to see exactly what's happening behind the scenes, including what data is transferred and when. - Mike On Sat, Feb 22, 2020, 10:47 Manoj Patil <[email protected]> wrote: > Hi nick, > > Yes , I am seeing encoded images at idle connection and frequently packet > send recive ACK and SYN through server to client and vice versa . > > I am seeing high resource utilization for the Guacamole components on the > web browser. > > I am also cross check bandwidth utilization RDP with using MSTSC ActiveX > control its too less (1.3 kbps) in running mode . in idle mode they can not > utilized network . > > > On Sun, 23 Feb 2020, 00:00 Nick Couchman, <[email protected]> wrote: > >> On Sat, Feb 22, 2020 at 12:35 PM Sean Reid <[email protected]> wrote: >> >>> Hi Manoj, >>> >>> Guacd has a few formats at its disposal to send images: PNG, JPEG, and >>> optionally webp. PNG is lossless, JPEG and webp are lossy. Guacd chooses >>> heuristically which it will use based on things like the current framerate, >>> the size of the image, and whether or not PNG is just better at accurately >>> representing the frame content. These heuristics are not user-controllable, >>> so the fact that guacd is choosing PNG means that it is the optimal choice >>> given the current state of the remote display. >>> >>> Sean >>> >>> On Sat, Feb 22, 2020 at 11:56 AM Manoj Patil <[email protected]> >>> wrote: >>> >>>> The only thing that I noticed is that there is no compression between >>>> the server and the client. Meaning that full sized base64 encoded PNG >>>> images are send to the client, which causes a high network load (~1.8mb/s) >>>> >>> >> Well, 1.8 Mb/s may be a high network load on a 5 Mb/s shared MPLS >> connection, but it isn't all that high on a 100 Mb/s network link. Also, >> what are you doing when you see this utilization and base64-encoded PNG >> images? Is this when the connection is idle? Or are you watching a >> YouTube video on the remote system? It matters. And it seems like you've >> jumped back and forth between talking about idle connections and now >> talking about...?? There's very little context to your assertion, here. >> >> Sean makes a really good point, and, really, it brings us back to one of >> Mike's questions, Manoj: what problem are you trying to solve? Are you >> seeing congestion on the network when you use Guacamole? Is the Guacamole >> connection unreliable or slow or choppy? Are you seeing high resource >> utilization for the Guacamole components or the web browser? >> >> -Nick >> >>>
