Hello,
I am still fixing some details of the reference implementation, it is not yet ready.
When it will be ready to publish, it will only be an alpha version, so .. if you want to use it for a big project, it is better to not use it immediatly.
About the mapping of class names -> int IDs, I think it's nice to have the possibility to explicitly specify the mapping in the code. That will work better with obfuscation for example and the mapping never has to be sent over the network. If an ID is not found for a class a runtime exception would be thrown. Of course, dynamic mapping can also be implemented.
I found out that such a table don't need to be specified at all, even when the programmer is using obfuscation.
I am using something dynamic for the mapping, with the possibility to block the call of some specified methods of the exported object on the connection. It can make the receiver of the calls more robust and easier to implement with this feature.
About serialization: it would be nice if serialization code was generated automatically and dynamically for a class. It would of course take into account transient fields. It would also be nice if you can override the write and read methods for a class (similar to Serializable).
For now, the compiler only handle the primitive types of Java + the enumations + some reference handling. It doesn't support yet the serialization issue, I am waiting to have something working well first, then I will deal with the serialization.
I am actually working on the sent of a reference (local or remote) as an argument of a remote call.
exemple of a Remote interface in JNAG :
1
2
3
4
5
6
7
8
9
10
11
| public interface ServerGameLogic
extends Remote
{
public void login(String login, String password);
public void insertCoins(int nbCoins);
public void play(CaracterType caracterType);
public void logout();
public void takeMyClientPlayerRef(@CallerSide ClientPlayer clientPlayer);
public void invitPlayerToJoinParty(@ReceiverSide ServerPlayer ServerPlayer);
} |
"@CallerSide" means that the instance that we are giving is a local instance, a stub will be created on the receiver side if it doesn't exists yet.
"@ReceiverSide" means that the instance that we are giving is a stub representing a remote instance, so on the server side, the method will be called with a local instance in argument.
About method calling: if you can make it similar to RMI that would be great. Otherwise a simple method ID -> Runnable mapping would probably work for me. I think both the client and server should be able to run single threaded, so asynchronous method calls is a must.
For now, the remote calls are made via stubs (I call them "encoders" in my API, since I am using some "decoders" on the receiver side). The calls of the remote instances are made exactly like a local call.
JNAG only (and probably "will only") support asynchorized method calls.
In the actual Framework of JNAG, the client is using 1 threat with the non-blocking io API. The server is using 2 threats : 1 to accept the connections, and 1 to process the requests and execute the tasks of the server (the actions that the game logic is doing on a time basis rather than on a message-from-client basis, like to update the NPCs, trigger the event of the end of a game, etc ...)
This requires some smart buffer handling to store the method calls until they can be put on the socket buffer. If you have 1000 clients you can't allocate a 1MB buffer for each client
.
work in progress ....
Yes, I need to improve this also. For now, I use a basic 10kb output buffer per client, I fix details and I pray to have my tests running like I want
Also, buffering can cause some latency problems, so message priorities would be nice (for example player positions have high priority, world data low).
This is where UDP will join the lib
Synchronous method calls are nice, but not necessary for games I believe.
now that I am thinking .. it is really easy to implement synchronous method calls on the top of JNAG. Even if it is inneficient, it may be needed sometime (for easy debug ?). If I see that people need it, I may add it as a auxiliairy util later, but it won't be a part of the core of JNAG.
