On Sat, Apr 19, 2014 at 9:15 PM, Guillaume Nodet <[email protected]> wrote: > Sshd internally uses nio2 by default, which is not based on selectors, but > non blocking operations. > > On the client part of SSHD, things are mostly asynchronous already: > #1 SshClient#connect returns a future on which you can set a callback > and that you can use to retrieve the ClientSession asynchronously > #2 You need to use ClientSession#addXxxIdentity and then > ClientSession#auth which is also asynchronous > #3 You then create a channel, and actually operning the channel is also > asynchronous > #4 Closing channels is also asynchronous > > I think the only missing part is really the streams on the ClientChannel > which are using InputStream and OutputStream. > If we replace them with an AsynchronousByteChannel, I think we would be > fully async.
Thank you for your response, Our definition of async is very different... :) I do not think this module is sufficient to what I target. I see the number of threads created within the library core and the logic that is out of reach. This ssh library is great, splitting it into two logic only and communication layers will enable to go fully async. The logic layer should not have any thread. A default implementation of communication layer can be provided, but is optional. The difference from the world I coming for is that Future handling is much more complex than having control queue. Was just an idea, thank you for addressing. > > 2014-04-19 15:57 GMT+02:00 Alon Bar-Lev <[email protected]>: > >> On Sat, Apr 19, 2014 at 3:52 PM, Jon V. <[email protected]> wrote: >> > >> > NIO controls and deals with the selectors. Async IO is a part of that but >> > is not the same thing. Async io means that if a write cannot be fully >> > flushed. It will not block until it can be. NIO provides us the events to >> > tell us that data is available in the socket. >> >> Async IO is the ability for a single thread to perform (multiplex) IO >> (connect, read, write, close etc..) for multiple file descriptors. >> >> As far as I know, without NIO you cannot achieve that in Java. >> >> There is no sense in read or write without blocking if you cannot wait >> (vs actively poll) for an event. >> >> > On Apr 19, 2014 4:56 AM, "Alon Bar-Lev" <[email protected]> wrote: >> > >> > > On Sat, Apr 19, 2014 at 10:58 AM, Emmanuel Lécharny < >> [email protected]> >> > > wrote: >> > > > Le 4/19/14 9:45 AM, Alon Bar-Lev a écrit : >> > > >> On Sat, Apr 19, 2014 at 10:38 AM, Emmanuel Lécharny < >> > > [email protected]> wrote: >> > > >>> Le 4/19/14 9:13 AM, Alon Bar-Lev a écrit : >> > > >>>> 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. >> > > >>> There are a few important things you have to know about async and >> > > threads : >> > > >>> - the extra cost for dealing with async connection is around 30%. >> That >> > > >>> all but free >> > > >>> - a standard system can easily deal with a few thousands of threads >> > > >>> >> > > >>> Now, unless you define what is "high load", I don't really see what >> > > kind >> > > >>> of advantage we can get with an async implementation. >> > > >>> >> > > >>> FTR, when MINA was initially created, it was because there was a >> need >> > > >>> for a system supporting potentially ten of thousands of >> connections. Is >> > > >>> that what you are targetting ? >> > > >> Yes, using work threads that are derived per # of CPUs, no more. >> > > >> I am far from the pure "Java" world... but if async IO is 30% >> > > >> insufficient, maybe it worth to use libssh (C) and communicate with >> it >> > > >> using single socket from java, delegating IO outside of java. >> > > > IO are already delegated outside on Java. Eveything IO related is >> > > > written in C and wrapped into Java class. >> > > > >> > > > The extra cost when using NIO is due to the management of SelectorKey >> > > > lists (with the various steps involved when dealing with those >> lists). >> > > > >> > > > All in all, when it comes to process IO, Java does not really add >> some >> > > > extra cost over a plain C implementation. It's not the same story >> when >> > > > using NIO, especially when dealing with many concurrent connections. >> > > > >> > > >> > > So I am confused... Java does not add cost to async IO, but NIO does? >> > > While NIO is the only interface to Java async IO? >> > > >>
