[Gabel-guys] Re: Dispatcher
Status: Alpha
Brought to you by:
alllee
|
From: Allen L. <al...@cs...> - 2004-06-04 00:03:53
|
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...
> +++++++++++++++++++++++++
>
|