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
