Re: Buffering issue when echoing user input

[Alan Gardner <gardner@xxxxxxxxxxx>]

Well, I'm replying to myself again, partially to document my findings and
partially to confirm I'm going about this in a sane way:

Once I handle authentication and accept the PTY and shell messages, I go
into a loop like this:

- Select on the fd on which I listen for the client
- When the select fires, use ssh_set_fd_toread on the client session (not
sure if this is necessary)
- Try ssh_channel_poll on the the client channel
- If the poll returns 0, we've received a session message, use
ssh_message_get on the client session
- If the poll is greater than 0, we've received user input on the channel,
read it normally with ssh_channel_read

To echo characters back:
- Use ssh_fd_towrite on the client session
- Use ssh_channel_write

This seems to work, I can handle re sizing the PTY and echo characters back
no problem. The only thing that concerns me is the possible race condition
if select() fired once, but there was channel data and an SSH message
simultaneously. I'm not 100% sure this is possible, it certainly doesn't
seem likely.

- Alan

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

> 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
>>
>
>

-- 


--