Hi everyone, First, let me thank all of you for giving us Retroshare. Works beautifully :) Thanks.
I am one of the developers of the open source project eBrainPool (http://ebrain.in) and for this project I have been toying with a RS plugin that will allow me to tunnel SSH traffic between RS users. The idea is to SSH forward X clients tunneled via RS. I have extended the EmtyPluginRS and taken inspiration from the VOIP plugin to extend Retroshare 0.6.0. I have managed to successfully create a tunnel between two end points - it's a very dirty hack - but I can essentially do a ssh login and work within a console session without any problem. SSH forwarding of simpler X clients such as xclock, xcalc,etc work without any issues either. With more sophisticated X clients such as gnome-calculator, gedit,etc somewhere along as I use it, my ssh client with the entire X environment freezes up. This usually happens when huge amounts of data need to be sent together by the SSH client. For e.g. if a button is pressed in gnome-calculator then at times it is liable to freeze up. On further investigation I have realized that the button press translates to a huge number of messages coming in from the SSH client of 170 bytes or so and a final message of approx 3556 bytes or so before things freeze up. I then have to kill my ssh client in console to regain access to my X environment. I have tried both approaches in my plugin - with a separate thread to accept input to / from the client, and also without a separate thread. The issue and point of failure is the same. Granted I definitely do not understand the RS architecture well enough and I fear that it is this lack of understanding that is causing this problem. I am not using any sort of message queue and as data is being received from the client or server I am simply pushing it down the pipe (via sendItem). I have noticed that extremely large blocks of data (say 100k or such) simply disappear and are not received at the other end. Therefore I chunk data from ssh server or client into blocks of 16384. I have tried different block sizes but it doesn't help the bug I have above. I realize that the above information is not sufficient for anyone to help me debug my problem. The code I have is an ugly and dirty hack that started off as an experiment to see if this is even feasible and therefore could be hiding a myriad of bugs contributing to this. However my hope is that someone here more well versed with the core Retroshare architecture will be able to point me in a direction I should look at. Am at wits end therefore any kind of direction would be appreciated. Thank you for your time. Regards, Jeetu ebrain.in - Discover and use software from devices around you (an open source GPLv3 project) ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ Retroshare-devel mailing list Retroshare-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/retroshare-devel
