Hi, The mission of async is to avoid having threads at all, or at least O(1).
As you have underline internal/private low level channels for socket processing, and public high level channels to communicate with application, there should be a mechanism for library to request wake up for these low level channels. Another option is to avoid using sockets at all within the implementation and require application to manage the sockets and pipe socket data into the library. I understand this is conceptional change than what we have now, but this what will enable scale without abusing system threads or have nondeterministic behaviour in high load. Regards, Alon On Sat, Apr 19, 2014 at 9:58 AM, Guillaume Nodet <[email protected]> wrote: > The asynchronous interface is an interesting idea. > Though I'm not sure the using selectors is the best and I'd rather try to > change the input/output streams ChannelInput/OutputStream so that > ClientChannel returns AsynchronousByteChannel instead. > I think we need both sync and async interfaces for the client, depending on > the use case. > > > > > 2014-04-18 1:26 GMT+02:00 Alon Bar-Lev <[email protected]>: > >> Hi, >> >> Are there any plans to support async interface for the sshd package? >> >> Enable single/multi threaded implementation based on nio, in which >> selector is left within the program main? >> >> The library can return a set of events to wait for including timeout, >> so that main program can wait for these among other events it >> requires. >> >> The interaction between channel and program can be based on selectable >> channel as well, so that program may send/receive data via ssh >> protocol being completely async. >> >> Regards, >> Alon Bar-Lev >>
