I have constructed a multiplayer lobby (well, pspeed has constructed one, I just copy pasted). Using RMI. I’m not super familiar with RMI. This is just a small wondering type of question. I want to get the list of players, I don’t need it to be send to other players, just init the client who just entered. My client can query them with List getPlayers(). Synchronously.
com.jme3.network.service.rmi.MethodInfo.java pretty much tells me that you can’t have Async methods that have return values other than void. Now I was wondering, that well, Future<List>? Obviously not with current JME, but would it make sense at all in the future?
Or is the preferred design to construct a thread in the client for this if I want it not block the client?
You can use a call back method and get player list asynchronously.
as an example
and callback listeners
So in your case, client will first ask for the list of players with void getPlayerList(), then after server processed the list it will call the callback method (which is shared from client side) onPlayerList(List players); to send player list.
Yes, thank you. But that’ll be also notified to all players? And that is the thing I want to avoid. It doesn’t really matter that much. But I’m just asking it for the principle.
It maybe due to odd design, but I’m not able to set the listener there for the currently joining client to get the updated list with itself on board. So that means that other players get the update that this guy is joining up before the guy has loaded up his screens and he needs to ask separately for the players.
No… only if you wrote it that way. You can call back to one client’s listener or all of them. It’s up to you. You can even find the loop in the chat service that loops over them all to send the messages out.
Anyway, RMI in this case is really meant for the straight-forward stuff where writing messages is just needless boilerplate. At some point, it’s easier just to drop back to sending messages.
And @Asynchronous is specifically for the case where you want to send it out and not wait for a response… thus no return types. If you want a response then don’t use Asynchronous or use a callback mechanism… or just drop back to regular messages.
Ah oh yes, a bit of a brain fart on my side. I’m still quite not so familiar with this stuff, easily get my brains in a knot. We switched from the message based solution to RMI one, just now. It seems better for the chat, lobby and authentication, really copied from your code.
Also thought to mention it, if you want to target Android devices you may not want to use RMI stuff because Android does not support it as far as I know.
Good point. Eventually maybe yes. But we have a lot that doesn’t work on Android currently. And primary target is desktop. And we are a years away from that perhaps too. Rewriting the lobby is not a major deal, hopefully. It is all interfaces anyway to the outside,
