Re: Buffering issue when echoing user input

[Alan Gardner <gardner@xxxxxxxxxxx>]

I solved issue #1, I needed to use set_wontblock on the sockets. Then the
flush actually happens. Out of curiosity, how is this going to come back to
bite me? It doesn't seem to do anything bad, but I'm assuming the flag
itself means something or else it wouldn't be necessary.

Issue #2 still stands. I realize I wouldn't have these problems if I used
the ssh_channel_select, etc., but that's not really acceptable in my
application.

Cheers,
Alan

On Wed, Jan 2, 2013 at 3:24 PM, Alan Gardner <gardner@xxxxxxxxxxx> wrote:

> Hey Guys,
>
> Back with a few more questions. I've got the client connected, with a PTY
> and a shell opened. I can read on the channel and see what the user types,
> and I can write to the channel and have it displayed in the client. However:
>
> - Writes to the client seem to be buffered or somehow delayed until I read
> from the client. If I echo back user input, they only receive my response
> after a second keypress. For example, if the user types 'abc', they'll see
> 'ab'. If they then press enter, they'll get the c as well. With logging on
> it looks like the data has been written, but I noticed that the code to
> flush the socket doesn't have any logging, so I suppose it might be hung up
> there.
>
> - Is there a non-callback way to handle protocol messages once I've got a
> channel open? I'm using a vanilla select() on the client socket, so it
> fires even when non-channel data comes in - for example, if the client
> resizes the PTY. Is there a way I can read the data into a buffer, and use
> libssh to determine whether it's a protocol message or just input on the
> channel?
>
> Thanks,
> Alan
>

-- 


--