[Gabel-guys] Re: Dispatcher

[Allen L. <al...@cs...>]

Awesome, Andy, thanks!

Some thoughts, though:

	- What do you think about folding Dispatcher and DispatcherSink 
together - part of the responsibility of the Dispatcher may arguably be 
converting low level input socket I/O into high level events.  So the 
Dispatcher avoids the additional level of indirection and just crams 
out Events directly.
	- I think we should get rid of using ints as identifiers.  Especially 
if you're considering using some of this code for P2P stuff, where 
you'll have to deal with different JVMs generating non-unique 
identifiers across the network and then it becomes unclear what thing 
really generated what other thing.  Before it was the easy-lazy way to 
model identifiers, but now I think we're getting closer to the time 
when this will really be a pain to fix if we don't fix it soon and 
spray dependencies on ints as identifiers all over the codebase.
	- why is stopping the server related to making it non-blocking?  
There's no reason for the server to be registered with a Selector 
unless you really want multiple ServerSocketChannels listening on the 
same machine on different ports.  Stopping the server entails just 
falling out of the while loop and doing a serverSocketChannel.close()
	- Disconnection is not too bad to deal with so long as we don't leak 
the SocketChannel abstraction out of Dispatcher and friends, but the 
Dispatcher is doing a lot of things at the same time right now.  
Perhaps we would benefit from some sort of ConnectionManager class that 
actually maintains the map of client identifiers to client connections 
and provides convenience functionality for removing stale connections, 
etc.
	- I think that SelectorWrapper should go away and be replaced with the 
ReadWorker implementation in ForagerNioServer, though I'm not sure what 
the true intent of SelectorWrapper is.  Right now it doesn't look like 
it does anything other than wrap a Selector in a thread, which is what 
the ReadWorker does already, with the added benefit that it can be used 
in the WorkerPool that I've set up so that we can do poor-man's 
load-balancing and enforced fairness using threads.  Along the same 
vein, what's the purpose of the SelectionKeyAcceptor?  Do we really 
need a whole nother class/object for processing the socket channels 
that have information available?  From the POV of the framework, all we 
really need is a way to convert NIO server I/O (the ByteBuffer, etc., 
crap) into Events or Objects that the rest of a specific 
experiment/application can understand...

Oh yeah, one last question: what did you mean by 'non-connections are 
not detected'?

Your thoughts?

On Jun 3, 2004, at 5:34 PM, Andy Jones wrote:

>   The dispatcher now lives!
>   Here's the quick rundown...
>
> . Starting a server is as easy as pie
>   disp = new Dispatcher();
>   disp.startServer();
> . Making connection is as easy as pie
>   disp = new Dispatcher();
>   id = disp.connect(String host, int port);
>   o Dispatcher makes the connection and return an identifier which 
> should
>     be used in future transactions
>   o Dispatcher manages the Channel for you, will let you know when 
> input
>     comes { via accept(int, byte[]); }
>   o Use write(int id, byte[]); to send data via the connection
> . Any object interested in received dispatcher happenings should 
> implemens
>   the DispatcherSink interface, three methods
>   o accept(int id, byte[] buff); // accept data
>   o acceptConnection(int id); // accept connection
>   o dropConnection(int id); // drop a connection
> . Using this DispatcherSink it would be very easy to write a bridge 
> class
>   that implements the DispatcherSink and produces events which it then
>   pushes into the event pool
> . The other two classes SelectorWrapper.java and 
> SelectionKeyAcceptor.java
>   are really just internal classes, but may be useful if you want to 
> wrap
>   a selector for convience sake in the future
> . Things to do...
>   o Can't really stop the server, need to make the ServerSocketChannel 
> a
>     non-blocking Channel that is registered with the internal selector
>     like anything else, able to stop
>   o Non-connections are not detected
>   o No clean way to disconnect channels yet
>   o Add logger capabilities to error handling (currently println's)
>
>
>   -Andy
>
> Repel them.  Repel them.  Induce them to relinquish the spheroid.
>                 -- Indiana University football cheer
>
> ----------------------------------------------------------------------
>
> THE SMURFS AND THE CUISINART (1986)
>         The lovable little blue Smurfs encounter a lovable little 
> kitchen
>         appliance, which invites them to play.  The Smurfs learn a 
> valuable
>         (if sometimes fatal) lesson.
>
> THE SMURFS AND THE CARBON-DIOXIDE INDUSTRIAL LASER (1987)
>         The inevitable sequel.  The lovable and somewhat mangled 
> surviving
>         Smurfs team up with the Care Bears to encounter a cute, 
> lovable piece
>         of high-tech welding equipment, which teaches them the magic of
>         becoming rather greasy smoke.  Heartwarming fun for the entire 
> family.
>
> +++++++++++++++++++++++++
> '(Andy Jones)
> Home: (812) 337-1438
> Work: (812) 333-3134
> and...@in...
> IU Comp Sci Grad
> web...@co...
> +++++++++++++++++++++++++
>