Re: asynchronous channel write

[Torsten Kuehnel <tdkuehnel@xxxxxxxxxxxxxxxxxxxxx>]

On Wed, 15 Jan 2020 00:53:51 +0100
g4-lisz@xxxxxxxxxxxx wrote:

> On 13.01.20 22:54, Torsten Kuehnel wrote:
> 
> > Looks to me your loop does not cope with partial writes correctly as
> > you pass the initial (channel, buf, len) parameters unmodified in
> > subsequent calls to ssh_channel_write, shall your innermost do {...}
> > loop iterate more than once.
> >
> > Shouldn't you increment your buf pointer by the bytes already sent, or
> > does libssh keep track of the write progress and does this for you ?
> 
> Hi Torsten,
> 
> yes you are right! After reading the source of ssh_channel_write() I
> totally agree. The buf argument is a const char* so it can't be modified
> through ssh_channel_write()...
> 
> I'm really suprised that we never had an issue with this... We tested
> the code extensively.

Hi,
when you are feeding sockets and there is no network/interface load, every
os (as far as i know of) tries to send/write the amount requested in whole.

The task of the underlaying kernel is to avoid, when you request non
blocking i/o, that the kernel *itself* does not has to wait. So when
the kernel sees there is a small amount of room in the underlaying
ethernet driver buffers, for example, he fills this space with (part)
of your data and returns immediately, telling you how much could be send.

Thats my assumption how the underlaying stuff works. Feel free to add
any knowledge.

The hard thing is to test such edge cases in your test suite. For my
packet code for example i have tests which *simulate* low bandwidth
by sending single or a few, half of a logical packet for example to cover
at least the reading end dealing with partial stuff.

On the writing end one could use a proxy pipe for example with a small
buffer size, which size has not a plain modulo of your packet size. Just
don't read on its other end, the buffer fills up and you *should* get
partial writes to test your code against. Then read some bytes and so
on ...


Currently i still stuck on non blocking writing at all using libssh, as
i have still no clue on how libssh poll code decides to take the POLLOUT
event out of the session poll ctx handle ?

When i call ssh_event_add_fd with my socket and POLLOUT and a callback,
is it save to call ssh_event_remove_fd afterwards to take it out and not
break the underlaying rekeying and session/channel working stuff ?

Will try this out next ...

> 
> Maybe the implementation changed? I wrote it for V0.8.90...
> 
> I will check this.
> 
> Thanks!
> Till
> 


-- 
Torsten Kuehnel <tdkuehnel@xxxxxxxxxxxxxxxxxxxxx>