Hi, I'm evaluating grizzly for the first time by attempting
to port over a small and simple TCP based server project
that manages persistent client sessions which share a dynamic "world" state.
I guess sort of like a simple sub/pub MQ, or perhaps a MUD server :P
The world's state changes fairly rapidly (= order of 10ms, maybe less..)
but these updates need to be broadcast to only <50 clients on a very fast LAN...
not a big deal, and straightforward to do in regular Java or C (actually I also
did a prototype in erlang for kicks) --- but I am intrigued by both grizzly
and mina(?) and like to experiment. :D
Anyway, I'm just tracing through the sample standalone app and would
like to know if it's possible to somehow have a designated thread
outside of the whole workerthread/callback hierarchy
push data to arbitrary clients/sockets?
Right now in the sample program, it's basically pinging req/acks... now,
if I wanted to send out some random message from the main thread, to
for example, the second client while it's doing its own thing, what is the best
way to get a handle to its outputstream?
Can I hold on to Context references outside the scope of execute's and other
callback methods if I do incrementRefCount? Is this the proper way to keep
a global directory of client sessions?
While the server will constantly stream new data to the clients, it's possible
that the clients will at times make requests that the server needs to
acknowledge. My concern is, if I maintain this ref to Context outside its
initial point of reference, what is the proper thread safe way to use it so
that writing a binary chunk won't interfere with the existing event handlers?
Also, at which point is it recommended that I grab hold of the client's IP
address? I see the info is buried somewhere down from Context... I forget
right now, but somewhere around SelectionKeyImpl.
Regards,
-Emit