m├ąn 2014-06-23 klockan 19:30 -0600 skrev Eduardo Silva:
> On Mon, Jun 23, 2014 at 6:39 PM, Henrik Nordstr├Âm
> <henrik_at_henriknordstrom.net> wrote:
> > tis 2014-06-24 klockan 02:21 +0200 skrev Henrik Nordstr├Âm:
> >> Not that I can see. You need to try to perform read/write on each active
> >> channel & stream to see if there is anything to perform whenever the
> >> session fd is active in epoll.
> > Thinking on this. Would it make sense to have an API to query what the
> > next packet in the receive queue is about? This would allow
> > multi-channel applications to scale better with number of channels by
> > avoiding to repeatedly loop over all channels (&streams) whenever there
> > is any activity.
> in response to last two emails (there is one missing in my inbox):
Don't know what happened with my first response. I never got it back via
the list, but is available in the list archives.
> - if we could determinate the type of packet would be awesome.
It would be very easy to add an API that tells you which is the next
channel / stream that have activity in the packet queue. Question is if
it's the right thing or not, and if it is, what should such API look
like? How much detail need to be exposed to the application for it to
know what libssh2 operation(s) is need to continue with?
> - the number of channels to handle may vary between 10 and 20. I do
> not worry too much about performance at this point.
So for you simple polling of all your channels is not really a problem.
> just to clarify, whats the real difference between a channel and a
> stream in libssh2 ?
Each channel can be divided into N streams. Each stream is processed
individually by libssh_channel_read_ex() (without _ex is only a wrapper
to process stream #0), but windowing is performed on the channel as a
whole if I am not mistaken.
Received on 2014-06-24