Hi Emit,
I know Grizzly 2.0 is still under development, but think it will be
easier to do what you need with 2.0.
I'll try to give you some hints regarding 2.0, but if you prefer
Grizzly 1.x, let me know.
> 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
ok.
> 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?
You mean, you'll push some data from time to time from some custom
channel?
> 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?
Think this could be done following way:
1) You can implement own LifeCycleFilter similar to [1], which will
track client connections, and keep the collection of active clients.
2) In any other thread you can retrieve client Connection, from
LifeCycleFilter and call Connection.write(...). It's really easy. If
client is in non-blocking mode (default) - the message will be added
to asynchronous write queue, so you don't need to care about possible
simultaneous writes.
> 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?
You can use Connections in Grizzly 2.0 to reference client connection.
> 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?
As I told Connections will use async write queue, so you dont need to
care.
> 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.
I just added support for:
Connection.getRemoteAddress();
You can use it like:
SocketAddress address = ((TCPNIOConnection)
connection).getRemoteAddress();
Thanks.
And let me know if you have questions.
WBR,
Alexey.
[1]
https://grizzly.dev.java.net/source/browse/grizzly/branches/2dot0/samples/framework-samples/src/main/java/org/glassfish/grizzly/samples/lifecycle/
>
>
>
> Regards,
> -Emit
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>