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
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
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
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.
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
Retroshare-devel mailing list