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
> 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:
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.
Received on 2013-04-11