On 31.10.13 10:59, Johan Maasing wrote:
> This was a while back so it was version 2.3.3. When I tried to send
> using the connection I collected during the filter chain I got errors
> from buffers that wasn't in the right state.
>
> The reason I'm asking is that I plan on taking another stab at this in
> a few weeks with the current version of Grizzly. I just wanted to
> check if it seemed reasonable to have a filter chain handling the
> sign-in process to the server, extract the connection from the
> FilterChainContext and keep it around for use later. It seems to be
> the right approach if I understand correctly.
> I'll let the list know if I run into troubles with this.
Yes, it's correct approach, if you find any problems - pls. let us know.
WBR,
Alexey.
>
> Thanks for your time,
> Johan
>
>
>
> 2013/10/31 Oleksiy Stashok <oleksiy.stashok_at_oracle.com
> <mailto:oleksiy.stashok_at_oracle.com>>
>
> Hi Johan,
>
>
>
> On 31.10.13 01:36, Johan Maasing wrote:
>
> A while back I played around with grizzly for a hobby project,
> a small TCP based game server.
> I could get the filter approach working fine between clients
> and server. A client sent a message and a filter chain on the
> server responded. I used this to handle the sign-in flow where
> a client logged in to the game server.
>
> But I got sort of stuck when I wanted the server to send game
> update messages to one or more clients. Now there was no
> FilterChainContext I could use to write to the client since
> the server was the one initiating sending messages.
> I tried to extract the Connection from the FilterChainContext
> during the sign-in and keep around to send messages to clients
> later on but that never worked.
>
> What type of design should I use for this scenario? Are the
> filter chains still appropriate? How do I get a Connection (or
> similar) to the client?
>
> It should work with Connections, strange it didn't work for you.
> Which Grizzly version are you using?
>
> Thanks.
>
> WBR,
> Alexey.
>
>