AsynchrronousByteChannel vs AsynchronousFileChannel and AsynchronousTransmitter

[Alan Bateman]

Alexander Libman wrote:
> Hi Alan, hi all
>
> Thinking about AsynchronousTransmitter with draft  prototype:
>
> AsynchronousTransmitter {
>
> private AsynchrnousTransmitter (....);
>
> public static <A>
>      Future<AsynchronousTransmitter>
>           transmit(AsynchronousChannel inChannel,
>                    AsynchronousChannel outChannel,
> 		       A attachment,
> 	             CompletionHandler<AsynchronousTransmitter, ? super A> handler)
>
> /* The AsynchrnousTransmitter instance is accessible via returned Future<>
> */
> public long getTotalBytesRead ();
> public long getTotalBytesWritten ();
> }
>
> where inChannel and outChannel can be any combination of
> AsynchrnousByteChannel/AsynchronousFileChannel(s).
>
> Seems it would be helpful, if the AsynchronousFileChannel was derived from
> AsynchrnonousByteChannel. Otherwise, we have to provide four similar
> prototypes and implementations for Transmitter.
>   
AsynchronousFileChannel is intended for concurrent access and so does 
not maintain a global file position (and so intentionally does not 
implement AsynchrnonousByteChannel). AsynchronousFileChannel isn't 
really intended for sequential access but it would be relatively simple 
to wrap an AsynchronousFileChannel, returning a 
AsynchrnonousByteChannel. The resulting AsynchrnonousByteChannel would 
maintain the file position. It probably needs experimentation to see if 
one position for reading and another for writing, or simple one global 
position if better (having independent positions for read and write 
might be a bit strange but easier than trying to coordinate concurrent 
read/write operations). This solution would avoid needing to add the 
additional methods to AsynchronousTransmitter that you are concerned with.

I'm trying to understand your class from the above skeleton. Who 
executes the completion handler? Is the Transmitter created with its own 
thread pool or is the a thread associated with the source or target 
channel's thread pool?

> As an example, we developed a draft of "AsynchronousByteFileChannel" which
> works like a filter and implements AsynchrnousByteChannel inteface.
> The only one difference with the filter is : the "inner" channel is
> AsynchnornousFileChannel instead of AsynchronousByteChannel.
> The source can be found:
> http://jproactor.svn.sourceforge.net/viewvc/jproactor/trunk/nio2/src/au/com/
> terabit/nio2/filter/AsynchronousByteFileChannel.java
>
> BTW, during prototyping of  AsynchronousByteFileChannel, we found that
> simple filters can be easily developed
> using only AsynchronousFuture and no AsynchronousFilter is required.
> http://jproactor.svn.sourceforge.net/viewvc/jproactor/trunk/nio2/src/au/com/
> terabit/nio2/filter/AsynchronousFuture.java
>
> With term "simple" filter it is assumed filter with mapping 1:1 for "outer"
> and "inner" operations. Such filter
> acts as  small interceptor on operation starts and completions.
>
> For complicated filters (stateful engines like SSL), the base class
> AsynchrnousFilter is still preferred solution.
>
> And finanally coming back to the beginning - AsynchronousTransmitter.
> Having AsynchronousByteFileChannel AsynchtronousTransmitter becomes a very
> small class, which
> can transmit both files and sockets:
> http://jproactor.svn.sourceforge.net/viewvc/jproactor/trunk/nio2/src/au/com/
> terabit/nio2/filter/AsynchronousTransmitter.java
> and small test example
> http://jproactor.svn.sourceforge.net/viewvc/jproactor/trunk/nio2/src/au/com/
> terabit/nio2/testfilter/TestTransmitter.java?view=log
>   
Indeed, it doesn't require a lot of code.

 From an initial glance it looks like you might need to result's 
completed rather than failed method for the case that there is an I/O 
failure after some bytes have been transferred.

> Definetely, real AsynchrnousTransmitter should use
> TransmitFile()/TransmitPackets() API for Windows and
> sendfile() for POSIX whenever it is possible. But in cases when API does not
> exist or does not support pair source/destination,
> the current solution can be used.
>   
This FileChannel transfer methods also work this way so that the best 
mechanism is used. We don't have transfer methods in the asynchronous 
I/O API yet but I would like to add some support one day. A possible 
candidate is AsynchronousSocketChannel#transferFrom(FileChannel, 
position, count) that works like the write method. This can use the best 
underlying mechanism for the case that the respective providers are the 
default providers.

-Alan.