EJP wrote:
The attachment is generally used as a Session object. It can contain the
SocketChannel state (what state would that be?), information about the
user, information about the current transaction.
Alternatively you can use the SelectionKey as a key into a
Map<SelectionKey,Session>, but this seems contrived to me compared to
using the key attachment.
I keep track of things like what state the server thinks the client is
in, in a SocketChannelState object. For instance, my clients have a
protocol to login. They cannot perform any meaningful commands until
they have performed the login protocol. So, the best quick solution I
could come up with is to maintain state for each SelectionKey via the
attach() method. At first I thought this might be problematic because I
was worried that the key's state would also get removed on the
iterator.remove() call, but I have found this technique workable.
However, for multiple logical flows (encryption to different endpoints
for instance) over the same physical flow, I am quickly realising this
requires some heavier-duty stateful objects. The Map is worth
considering as I will ultimately have to build more state into my
program.
Anyways, for all the hurrahs about NIO I am finding it rather
cumbersome. If you have any good strategies for these kinds of issues,
feel free to let me know! :-)
Thanks for your reply,
Mearvk
especially troublesome.
'Session' object. This will allow you to store other required values