This is the recent thread where I had similar issues:
http://www.libssh2.org/mail/libssh2-devel-archive-2013-02/0022.shtml
I only thought about/debugged it a bit, but it seemed pretty clear to me
that the only real fix is an internal queue and changing EAGAIN
semantics slightly, as discussed in that thread.
I'm only using libssh2 for loadtesting stuff right now, not production
code, so I can just restart when I run into problems, but somebody
should fix this at some point if the library is going to be production
quality, in my opinion. If I ever end up using it for production code
I'll fix it, but no time right now.
Chris
On 4/10/2013 3:30 PM, Eric Frias wrote:
> On 4/10/2013 5:28 PM, Daniel Stenberg wrote:
>> On Wed, 10 Apr 2013, Eric Frias wrote:
>>
>>> The main problem I'm battling is what happens when I need to do a
>>> read on a channel, and I don't know if there's going to be any data
>>> there to read. If there is, I want to read it. If there's no data, I
>>> want to be able to do other stuff like write to the channel or read
>>> or write to another channel. Seems pretty normal.
>>
>> But stuff you'd do on another channel isn't the problem here, right?
>> Just trying to check that I follow you properly.
>>From the rest of your email, I'm pretty sure you understand the problem
> I'm running into. I wish I hadn't mentioned a second channel now,
> because this is going to be messy to explain clearly.
>
> I can easily get myself into trouble reading and writing with only one
> channel. So in that sense, the separate channel isn't exactly my
> problem. But this problem seems to stem from state data stored in the
> session object, so the problem isn't confined to any one channel. If I
> get an LIBSSH2_ERROR_EAGAIN from a read on one channel and then I
> proceed to do write on a second channel, send_existing() might complain
> at me.
>> Yes. EAGAIN is a bit restrictive in that it only says libssh2 couldn't
>> deliver any data to you and you need to call
>> libssh2_session_block_directions() to figure out which direction of
>> the communication that caused EAGAIN.
> That seems perfectly fair to me.
>> This is a flaw in the current implementation and I would really like
>> us to fix it. I believe someone else also mentioned this limitation a
>> short while ago. I guess you're being hit by a check in the transport
>> layer like in send_existing() ?
> That's exactly the error I've been hitting. I just started looking at
> trac, and this ticket from a few months ago seems to be related:
> http://trac.libssh2.org/ticket/256
> Like that ticket's owner, my problem is easier to produce on slower VPN
> links than on a fast local network connection.
>
>> I think the proper way to implement this would be sure that the queue
>> for outgoing messages on the channel is still being drained properly
>> and in the right order even if you try another function that would
>> send data.
> That sounds about right to me. In my specific case, I'd want the
> library to queue up the window adjust packet to be sent the next time
> any libssh2 function gets called. If that weren't possible, I'd settle
> for some indication (maybe a different return code) that only part of
> the data was sent and I was required to call this same function again as
> soon as there was room in the send buffer.
>> Personally I've been backlogged badly recently so I haven't been able
>> to do much libssh2 hacking and I don't think there's much improvement
>> for me in the near future either.
>>
>> I think creating a good test case that repeats the situation in a
>> fairly good way could be a first step, then work on fixing code to
>> work with it.
> I know how that goes... I'll see if I can cook up a simple test.
>
> _______________________________________________
> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
>
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2013-04-11