Re: Non blocking write

[Aris Adamantiadis <aris@xxxxxxxxxxxx>]

Hi Aviv,

It's not sure we will do this, because of the expected behaviour of the
function when the nonblocking write "fails" (write would block):
should we report the number of bytes correctly sent through send(2),
SSH_AGAIN. Should we buffer that data or ignore data that couldn't be
sent (like send(2)). All of this is not obvious to define and the latter
is not obvious to implement either.
We may wrap the current behaviour (bufferize data to be sent and
returning SSH_AGAIN if buffer not empty), but don't hold your breath on
this, current libssh development is slow.

Kr,

Aris

Le 24/05/12 13:44, Aviv Zilberman a écrit :
> Does libssh plan to wrap it in a simple API (like ssh_channel_read_nonblocking) ?
> 
> -----Original Message-----
> From: Aris Adamantiadis [mailto:aris@xxxxxxxxxxxx] 
> Sent: Thursday, May 24, 2012 2:40 PM
> To: libssh@xxxxxxxxxx
> Subject: Re: Non blocking write
> 
> Hello,
> 
> ssh_set_fd_towrite() is a misnamed function that tells libssh the write
> won't block of the file descriptor. It may have the opposite action as
> you'd expect.
> The best way of doing nonblocking write is to use
> ssh_channel_set_blocking + ssh_channel_write, then use
> ssh_handle_packets to have libssh flush the socket when it's possible
> (however this function is currently private, we'll export it later), and
> use ssh_blocking_flush with a timeout to flush the buffer.
> A return code of SSH_AGAIN means there's still data to be flushed out.
> 
> Kr,
> 
> Aris
> 
> Le 21/05/12 09:13, Aviv Zilberman a écrit :
>> *Hi ,*
>>
>> * *
>>
>> *Does ssh_channel_write become non-blocking already ? *
>>
>> *if yes, in which version ?*
>>
>> *If not, does calling to “ssh_set_fd_towrite” or
>> “ssh_set_blocking(session, 0)” or “ssh_channel_set_blocking(channel, 0)”
>> will help ?*
>>
>> * *
>>
>> *Thanks in advance,*
>>
>> *Zilberman Aviv.*
>>
>> This e-mail message is intended for the recipient only and contains
>> information which is CONFIDENTIAL and which may be proprietary to ECI
>> Telecom. If you have received this transmission in error, please inform
>> us by e-mail, phone or fax, and then delete the original and all copies
>> thereof.
>>
> 
> 
> This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
>