On Fri, Mar 2, 2012 at 11:01 AM, Peter Stuge <peter_at_stuge.se> wrote:
> Mitchell Hashimoto wrote:
> > I'd like to stay away from callbacks now. It complicates many details.
>
> It's not so bad, libssh2 is not thread safe anyway, so there would
> not be many problems.
>
>
> > If libssh2 were to return a list of ready channels, would it buffer these
> > all somewhere? Does libssh2 already do this internally (which would make
> > this easy)?
>
> It does already. If you're in blocking mode and call _channel_read()
> on one channel, but a packet for another channel comes in, libssh2
> has to deal.
>
Ah perfect.
>
> I'm with Daniel about supporting multiple channels. Taking it a
> little bit further I think it might not be a bad idea to model the
> API after select() and poll(), meaning that the caller provides a
> list of currently interesting channels, and libssh2 returns saying
> what action there is to take.
>
>
I agree that a `select()` would be nice but of course it can't be modeled
like the `select` syscall since I think channel IDs increase monotonically,
correct? Because of that, marking a bitmap of the ready channels would
quickly grow out of control for SSH sessions that are held open for a long
amount of time.
Perhaps instead a kqueue-like interface would be appropriate where you
constuct an opaque `channel_group` like structure that contains the
channels you care about. Channel IDs are simply numbers, so libssh2 can do
some sort of efficient search/sort in order to quickly check if channel X
(which it has received a packet for) is in the channel group. This could be
efficiently implemented, although of course now the complexity is rising.
Or, perhaps simpler, the API can be something like the following:
int libssh2_session_channel_ready(LIBSSH2_SESSION *, LIBSSH2_CHANNEL
**buffer, int size)
Where `size` is the maximum size of the `buffer`, and the API would return
the number of channels that are ready to be read, and the `buffer` would be
an array of ready channels. This would be pretty easy to implement from an
API perspective, but puts more of a burden of performance onto the client.
Mitchell
>
> //Peter
> _______________________________________________
> 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 2012-03-03