|
I thought to do IoSessionMap an hashMap container, so we can have put-get-remove methods, considering that put and remove has just to be done 1 time for each IoSession (usually), and get() has to be invoked many more times.
Is that right? whatcan I use as key for that map? Use the socket address is not a good task for VMPIPE, but what else? I've been thinking a bit about this issue but I can't see why it has to be a Map. Couldn't it just be a Collection? And as Federico points out what would be the key if it's supposed to be a Map?
Federico, are you working on this issue? I was planning to start working on this and Yes, I planned to work it out because I need to resolve
Well, I'd like to work at this, but I'm new to team-development tecnique (I always worked alone), so I need a large amount of tips, i'd like to discuss every single choice. I was thinking about that, about the hashMap vs Collection, and I don't know. I have many structure that need of a unique identifier that match every single connection, in my applications, but for every application my key is different. I'm thinking about an ftp server that need of couple nick-ipaddr, about a chat server that need only ipaddr before login, then the nick after login, the neededs of every application is protocol specified... For mina purpouse only ( So the key problem is worse then I thougth. What do you think about it? I have inserted the first stub of classes and interfaces to resolve
There are many parts of the code that need to be discussed, that's just a stub. Speaking for my application, I think MINA needs a Map but that it doesn't need an application specific key.
I would like to use MINA to build a MUD server, which is basically an extended chat server that exists in a coordinate space. I implemented a simple chat server with MINA for experimenting. Imagine a user shouts, and you want that to write output to every other user's session, but you don't want it to write output to users that are executing a character creation workflow and are not actually in the game yet. Image a user says something that should only be output to the users that are standing in the room with him. I'm thinking that all the contexts that a user's commands will execute under will be game specific contexts that have their own lists of users associated with them, like a room or a set of rooms. An executing command will navigate the object model from the point of the user it is executing under to some collection of users that it wants to write output to. In my case these collections will be the result of database queries so I think what I actually need is just to be able to store a handle to a session in the database along with the users object, so that when I need to output to a set of users, I can fetch the session that goes with the user data in the result of my query. Since there isn't any data associated with the handle I don't think there are any database specific issues related to the key. You are using UDP right? The session handle in the database is the remote host+port of the client? You would use that handle as a key when querying your DatagramConnector for a previously connected session (from its IoSessionMap)?
No, the connection is over TCP.
Ok. I guess all I'm trying to find out is what the key should be in the Map. That would be what your'e storing in the db (your session handle), right?
I think so. This is all new territory for me, but I think you would fetch a room from the db or the cash, iterate over the other users in the room, possibly filtering the list because some are hidden or invisible or whatever. So... it seems like I just need to get from the database object that my game logic produced back to the session that mina is holding for me.
I've been taking a look at Federico's patch and it looks very promising. As he pointed out it only solves this issue for SocketAcceptors. But it shouldn't be to hard to add this support to VmPipeAcceptors. For DatagramAcceptors I don't think this issue applies?
Then come the IoConnectors. They are IoSessionManagers as well. I think it will be trivial to extend Federico's approach to include SocketConnector. One thing I still can't figure out though is what the key should be in the IoSessionMap. In the SocketAcceptor case it should probably be the remote address. But that won't work in the SocketConnector case (it's very likely that sessions will be connected to the same remote address). Then it would have to be the local address instead. For the VMPIPE transport neither will work without some refactoring. As pointed out by Federico previously the key is, in most cases, probably protocol specific. Because of that the user will have to maintain some kind of app specific key to socket address string mapping anyway. In Ryan's case he's using a database to maintain this kind of mapping. I don't think it would be too hard on the user if he would have to maintain the mapping to IoSession himself. What I'm trying to say is that I think it would suffice with a Collection instead of a Map. That would be enough to solve Collection getManagedSessions(SocketAddress) is added to IoSessionManager (or at least IoAcceptor to solve Creating unmodifiable collection will get very tricky because we'll not be able to iterate it if we wrapped the original collection simply; iteration loop will definitely throw a ConcurrentModificationException. So we need to compromise here.
1. Create a special data structure which can be iterated without synchronization 2. MINA returns a copy of the collection I think the first one is the best. We'll also have to provide a way to synchronize with MINA in case users don't want to see that ghost sessions(which is already closed) are returned. There was an interesting conversation among MINA users that it would be great if MINA provide session grouping.
We could rename IoSessionMap to IoSessionGroup and provide more advance features like that. Yes, I can see that an IoSessionGroup could be useful as a kind of broadcast/multicast interface.
But, as I argued in a previous comment I don't think IoAcceptors should return an IoSessionMap when asking for the managed sessions. Why don't we create a new issue for the IoSessionGroup feature? I'm still working on this issue. It's almost finished and the patch will also solve Collection getManagedSessions(SocketAddress) to IoAcceptor and Collection getManagedSessions() to IoConnector. For now I'm thinking of just copying the internal Set of sessions to a new Set instead of creating some smart collection impl. WDYT? Note that I haven't done anything for Datagram transport yet. I'm not sure if this issue and My idea is to provide IoSessionGroup which implements Collection. I think it is basically same with you.
You're right. BTW you don't need to create a patch; you have karma, why don't you create a branch? :-) I know that I can branch and I will. Was waiting for the repository reorg to be completed. The correct way is to create a personal branch in /directory/sandbox/niklas, right?
Collection getManagedSessions(SocketAddress) has been added to IoAcceptor. SocketAcceptorDelegate as well as VmPipeAcceptor will return the currently connected sessions on the specified local address. DatagramAcceptorDelegate doesn't support this method. It will throw an UnsupportedOperationException.
Note that no support for retrieving the currently connected sessions on an IoConnector has been added. But if needed it should not be that hard to add that kind of support. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Closed
Major
SessionManagers should manage list of sessions being managed.
DIRMINA-93.