Thank you so much for the reply i did not expect such a rapid response !

Yes the thread method sounds terrific.
I only need to read a couple lines of stdout at a time so a very small
ammount of feedback,... i'm not sure what subsystem is and whether libssh2
has it. But I probably will not need it then. If i can get at most 100
bytes/sec it's enough, but I'd like to have it at least updated 5 times a
second so maybe 20 bytes per input stream.

So If I understand right, this one is only using select():

"You watch the socket for incoming data by calling select() and then
call libssh2 to read when appropriate."


And this one is just threads and libssh2:

"A thread that loops on reading a non-blocking socket and updating
your UI is also fine."

Which one would you prefer ? I'm more bent on the second one since i never
used select() before.

Thanks !

Alian


On Mon, Nov 16, 2009 at 7:13 PM, Peter Stuge <[email protected]> wrote:

> salsa lover wrote:
> > I'm writing an application (app1) that remotely executes another
> > application (app2) on a server via ssh2.
>
> Depending on your situation, you may want to investigate using an SSH
> subsystem. With subsystems you have an 8-bit clean, authenticated and
> encrypted two-way transport between two programs. Unless you need to
> explicitly depend on some aspects of a particular shell program on the
> server, a subsystem is much simpler. However, subsystems must be
> configured explicitly on the server.
>
>
> > App2 on the server needs to report a bunch of status messages and status
> data back to app1 while it's processing. I'd like
> > to have a pretty good time resolution like 10 - 3 times per second
> feedback
> > at least.
>
> How much is "a bunch" in bytes? SSH isn't very thick on the wire, but
> there is some windowing (on top of TCP) and there is a known problem
> at least with SFTP when using buffers > 1024 bytes.
>
> These things will limit the maximum bandwidth you can reach, but
> unless you need to send a lot of data for each update I think you'll
> be OK.
>
> Note that neither TCP and so nor SSH are isochronous protocols. I.e.
> there is no guarantee for timely delivery, and factors outside of
> your (and libssh2's) control can lead to no updates being received
> for a very long time, followed by all the updates arriving in bulk
> at once.
>
>
> > I was thinking of a couple of ways to achieve it.
> > First execute app2 via libssh2_channel_exec() by app1, then:
> >
> > 1) have app2 write all status data to a file on the server then have
> > app1 read the file from a timer function via sftp periodically.
> > (It's cumbersome)
>
> It's also neither robust nor efficient. I strongly discourage this.
>
>
> > 2) have app2 write to stdout normally and have app1 just read the
> > channel via libssh2_channel_read().
>
> This is simple, robust and efficient. This is what I would do, via
> subsystem if circumstances permit.
>
>
> > (problem is how do i know what to read and when, and I want to be
> > able to display the status data asyncronously, or maybe i can use
> > channel read from a thread or timer function?)
>
> You watch the socket for incoming data by calling select() and then
> call libssh2 to read when appropriate.
>
> Never ever use timers!
>
> A thread that loops on reading a non-blocking socket and updating
> your UI is also fine.
>
>
> > 3) or maybe is there a way to redirect the channel read in some way
> > where it will trigger a function if there's a new line written by
> > app2 or something like that ?
>
> Nothing like this exists, but an libssh2-internal data pump with
> callbacks on received data is an interesting idea, and one that
> Daniel will recognize since libcurl offers that exact API.
>
> SSH is not line oriented however, so callbacks on lines would
> require some extra buffering in libssh2.
>
> In short, this option requires "a bunch" of work and I personally
> think it would be a nice feature, but not a must-have-top-priority.
>
>
> //Peter
> _______________________________________________
> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
>
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

Reply via email to