Hi, Thank you for adding this, I can understand how it works, and it will provide a service for async that is written from scratch. I tried to evaluate the amount of changes that required in my simple case to use this interface and currently it is much too large, so I will not be able to actually use it in the near future.
Thanks! Alon On Fri, Jun 6, 2014 at 9:48 AM, Guillaume Nodet <[email protected]> wrote: > I've enhanced SSHD to be able to provide fully non-blocking io on both > client channels and server commands. > A client side example is shown at > > https://github.com/apache/mina-sshd/blob/master/sshd-core/src/test/java/org/apache/sshd/ClientTest.java#L171 > A server side example: > > https://github.com/apache/mina-sshd/blob/master/sshd-core/src/test/java/org/apache/sshd/util/AsyncEchoShellFactory.java > > I would appreciate any input ... > > > 2014-04-20 0:33 GMT+02:00 Alon Bar-Lev <[email protected]>: > >> On Sun, Apr 20, 2014 at 1:19 AM, Guillaume Nodet <[email protected]> >> wrote: >> > 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. >> >> Thank you for the discussion, I truly appreciate that. >> >> Having a method for async input/output of data stream will be a good >> start within current implementation. >> >> Other than that it is a programming pattern discussion. I got the >> information I needed, thank you! >> >> >> >> >> 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? >> >> >> > > >> >> >> >> >> >>
