2014-04-19 20:43 GMT+02:00 Alon Bar-Lev <[email protected]>: > 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. > Not sure exactly what you're talking about here. Afaik, the only place where the ssh layer actually create a thread in when creating a client ChannelSession giving an InputStream which has to be read. This thread creation can be easily avoided by using ClientChannel#getInvertedIn() and writing to it. All other threads are communication threads only and are fully controlled by the IoService layer which is pluggable. Both mina and nio2 implementations use a fixed number of threads. But you can rewrite it if you need. I'm all for improving sshd, but I fear i'm not really seeing your points clearly. > > 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? > >> > > > >> >
