Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  JNAG(Java Network API for Games) Project Approved!  (Read 7262 times)
0 Members and 1 Guest are viewing this topic.
Offline karmaGfa

Junior Member




Miaow


« Reply #30 - Posted 2004-11-25 16:53:06 »

btw, from the notice about the "project proposal", I saw that people have to say why they vote a "no", so I would like to know the reasons why there is 2 other persons who votes a "no".

I feel a little depressed ... Cry

I would also like to know when the project will be approved or disapproved. Are the administrators waiting for the first sources ? They might come around the beginning of next week since I am working on them at full time now. Should I post them on the CVS repository of the JNAG project ? Can programers access it before the project is approved/disapproved ?

<a href="http://www.le-moulin-studio.com">Le Moulin Studio</a> - MMO Technologies and Services.
Offline karmaGfa

Junior Member




Miaow


« Reply #31 - Posted 2004-11-30 13:14:24 »

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.

Quote

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.

Quote

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.

Quote

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 ...)

Quote

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 Smiley.


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 Smiley

Quote

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 Cool

Quote

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.

<a href="http://www.le-moulin-studio.com">Le Moulin Studio</a> - MMO Technologies and Services.
Offline phazer

Junior Member




Come get some


« Reply #32 - Posted 2004-11-30 14:37:28 »

Quote
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.


Ok, cool. I'm willing to do some beta testing.

Quote

I found out that such a table don't need to be specified at all, even when the programmer is using obfuscation.


Ok, it would be interesting to hear how you solved this. Will this work even if the client and server have different names for the same class (which could happen with obfuscation)?

Quote

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 hope you plan to implement something that is a lot faster than normal serialization.

Quote

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.


Hmmm, is this really necessary? Isn't it better to do something similar to RMI, that is always to reference objects which implements Remote and serialize all other objects?

Quote

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.


Ok, similar to RMI I think it's a good idea that remote methods must be declared to throw some checked exception like IOException or similar. Otherwise it's easy to miss disconnect errors etc.

Quote

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 ...)


Great.

Quote

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 Smiley


Buffer handling is big problem, trust me Smiley Some kind of dynamic buffer handling is probably needed. Typically you want a small socket send buffer to minimize latency. With small socket buffers you can implement message priorities where a message with higher priority is sent before a buffered message with lower priority.

Quote

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.


Sure, synchronous messaging is easy to implement over asynchronous messaging.

Looking forward to testing your code.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline karmaGfa

Junior Member




Miaow


« Reply #33 - Posted 2004-11-30 15:33:41 »

Quote

Ok, it would be interesting to hear how you solved this. Will this work even if the client and server have different names for the same class (which could happen with obfuscation)?


Gosh .. this could happen ? Shocked I didn't know.
I assumed that the same class are obfusced to the same name. Usually, the programmers are able to obfuscate all at the same time, aren't they ?

Quote

I hope you plan to implement something that is a lot faster than normal serialization.


I will do the best that I can, or find the better compromise, or leave the choice to the user with some parameters to specify .. I will see this later.

Quote

Hmmm, is this really necessary? Isn't it better to do something similar to RMI, that is always to reference objects which implements Remote and serialize all other objects?


In my example, the annotations are annotating some Remote interfaces only. "CaracterType" is an enumeration type.

Quote

Ok, similar to RMI I think it's a good idea that remote methods must be declared to throw some checked exception like IOException or similar. Otherwise it's easy to miss disconnect errors etc.


For now I am not sure where JNAG should notify the user. Since the calls are asynchronous, it makes less sense to throw an IOException right after the call (since it doesn't reflect the precise position of the problem in the stream of the messages : nothing can certify the programmer that the remote host received the previous calls). I am thinking to let the user know the status of the connection explicitly by calling a function. Usually, the programmers don't need to check it after each call. Instead, they check once a frame or once a main loop.

Quote

Buffer handling is big problem, trust me Smiley Some kind of dynamic buffer handling is probably needed. Typically you want a small socket send buffer to minimize latency. With small socket buffers you can implement message priorities where a message with higher priority is sent before a buffered message with lower priority.


oky doky

<a href="http://www.le-moulin-studio.com">Le Moulin Studio</a> - MMO Technologies and Services.
Offline phazer

Junior Member




Come get some


« Reply #34 - Posted 2004-11-30 16:50:52 »

Quote


Gosh .. this could happen ? Shocked I didn't know.
I assumed that the same class are obfusced to the same name. Usually, the programmers are able to obfuscate all at the same time, aren't they ?


You might obfuscate just the client and not the server, or have different versions of the clients running against the same server. Then you need to supply a class file mapping to the obfuscator to get the same class names.

Quote

In my example, the annotations are annotating some Remote interfaces only. "CaracterType" is an enumeration type.


I don't understand why you need @CallerSide and @ReceiverSide. Isn't ClientPlayer and ServerPlayer implementations of Remote? The only way a peer can call methods on a remote object is if he got a reference to the object through a method call from the other peer. Then you would already know in which peer the object is stored. Or am I missing something?

Btw, do you have any plans to implement an automatic distributed GC (could be done using weak references) or will you leave that to the user?

Quote

For now I am not sure where JNAG should notify the user. Since the calls are asynchronous, it makes less sense to throw an IOException right after the call (since it doesn't reflect the precise position of the problem in the stream of the messages : nothing can certify the programmer that the remote host received the previous calls). I am thinking to let the user know the status of the connection explicitly by calling a function. Usually, the programmers don't need to check it after each call. Instead, they check once a frame or once a main loop.


Yes, that's an alternative, but I don't think it's better. Isn't it natural to throw an exception when you know that the message can't be delivered (for example when disconnected)? It forces the programmer to take some action.

Offline karmaGfa

Junior Member




Miaow


« Reply #35 - Posted 2004-12-01 00:36:40 »

Quote

I don't understand why you need @CallerSide and @ReceiverSide. Isn't ClientPlayer and ServerPlayer implementations of Remote? The only way a peer can call methods on a remote object is if he got a reference to the object through a method call from the other peer. Then you would already know in which peer the object is stored. Or am I missing something?


ClientPlayer and ServerPlayer are implementing Remote. JNAG doesn't cover the general case like RMI does. In the kind of program targeted by JNAG, the method have to be used only with a kind of instance extending Remote in parameter : local (caller side) or remote (receiver side). Now of course we can check at the runtime if the parameter is an encoder or not, but there is 2 disadvantages :
- the encoder use more CPU to do a check that is supposed to give the same result all the time for a bugless program.
- the programmer don't explicitly see on what side the remote object in parameter should be when he is implementing since it is not specified in the remote interface.

.. it is a little like using generics or not ..
Vector or Vector<MyType> ?

We can use Vector with MyType objects as elements, but it is more convenient to use Vector<MyType> .. it is more clear, and it allows some optimisations on the type check casts in future JVMs.

Quote

Btw, do you have any plans to implement an automatic distributed GC (could be done using weak references) or will you leave that to the user?


I will let this to the user until I am conviced that he really need it. JNAG is for a well specified kind of program .. the client and the server needto think the same so I assumed that they both know exactly when to let the GC recycle a instance and an its stub on the remote host.

Quote

Yes, that's an alternative, but I don't think it's better. Isn't it natural to throw an exception when you know that the message can't be delivered (for example when disconnected)? It forces the programmer to take some action.


hum .. I guess you don't see the subtile difference between synchronized and asynchronized for this precise case :
If the implementation decides to send the message later (in order to group messages) and can only detect the problem later ? for example after a kind of flush() called sometime ? The programmer that is using JNAG should not rely on a "fail fast" behavior.

<a href="http://www.le-moulin-studio.com">Le Moulin Studio</a> - MMO Technologies and Services.
Offline phazer

Junior Member




Come get some


« Reply #36 - Posted 2004-12-01 06:49:29 »

Quote


ClientPlayer and ServerPlayer are implementing Remote. JNAG doesn't cover the general case like RMI does. In the kind of program targeted by JNAG, the method have to be used only with a kind of instance extending Remote in parameter : local (caller side) or remote (receiver side). Now of course we can check at the runtime if the parameter is an encoder or not, but there is 2 disadvantages :
- the encoder use more CPU to do a check that is supposed to give the same result all the time for a bugless program.


The CPU time used to check this is negligible. Your solution restricts the programmer to use only remote or local objects as argument to a method. In some cases you want to pass both types to the same parameter of a method.

Quote

I will let this to the user until I am conviced that he really need it. JNAG is for a well specified kind of program .. the client and the server needto think the same so I assumed that they both know exactly when to let the GC recycle a instance and an its stub on the remote host.


That will work for most games I think. A distributed GC can always be added later.

Quote

hum .. I guess you don't see the subtile difference between synchronized and asynchronized for this precise case :
If the implementation decides to send the message later (in order to group messages) and can only detect the problem later ? for example after a kind of flush() called sometime ? The programmer that is using JNAG should not rely on a "fail fast" behavior.


I understand the difference. But what will you do if the program tries to send data over a disconnected socket? Throw a runtime exception or just ignore it? For example:

1  
2  
3  
4  
remoteObject.doSomething();
// Socket disconnected
remoteObject.doSomethingElse(); // What will happen here?
remoteObject.doSomethingStupid();


I think a checked exception is the best solution for this situation.

Offline karmaGfa

Junior Member




Miaow


« Reply #37 - Posted 2004-12-02 04:43:36 »

Quote

The CPU time used to check this is negligible.


Yes, depending the context, it can be negligible.

Quote

Your solution restricts the programmer to use only remote or local objects as argument to a method.
In some cases you want to pass both types to the same parameter of a method.


That's right. They might be some cases where the user wants to pass both. Rare, but it may happens ..

I think I will enable the user to specify nothing and put the tests into the encoder/decoder. But the users will win clarity to use the annotations .. and also the compiler of the encoder/decoder might have later a debug option to test if the parameter is really on the caller side or on the receiver side in order to have a fail fast behavior.


Quote

I understand the difference. But what will you do if the program tries to send data over a disconnected socket? Throw a runtime exception or just ignore it?


I will just ignore it.

I don't think the exception will help the programmer more, since he will have to finish what he is doing (probably he doesn't need to change his execution flow since the other instructions don't get any return values from the remote calls), and since he will have to remember that there was an exception thrown until the place where he effectively react to this event. That's why I am think to quietly ignore it and let's the user call a method on the connection that will tell him if it is still connected and if there is no problems.


Quote

For example:

1  
2  
3  
4  
remoteObject.doSomething();
// Socket disconnected
remoteObject.doSomethingElse(); // What will happen here?
remoteObject.doSomethingStupid();



the function remoteObject.doSomethingStupid() doesn't depend of the fact that the server received or not the call of the function remoteObject.doSomethingElse() or remoteObject.doSomething() .

<a href="http://www.le-moulin-studio.com">Le Moulin Studio</a> - MMO Technologies and Services.
Offline phazer

Junior Member




Come get some


« Reply #38 - Posted 2004-12-02 07:00:15 »

Quote

I think I will enable the user to specify nothing and put the tests into the encoder/decoder. But the users will win clarity to use the annotations .. and also the compiler of the encoder/decoder might have later a debug option to test if the parameter is really on the caller side or on the receiver side in order to have a fail fast behavior.


That will work well I think.

Quote

I will just ignore it.

I don't think the exception will help the programmer more, since he will have to finish what he is doing (probably he doesn't need to change his execution flow since the other instructions don't get any return values from the remote calls), and since he will have to remember that there was an exception thrown until the place where he effectively react to this event. That's why I am think to quietly ignore it and let's the user call a method on the connection that will tell him if it is still connected and if there is no problems.


One potential problem that can occur by just ignoring the connection error is that unnecessary work will be performed, for example calculating stuff to be sent to the disconnected client. However, unless you have very frequent connections/disconnections this might not be a big issue.

Offline karmaGfa

Junior Member




Miaow


« Reply #39 - Posted 2004-12-04 01:57:08 »

This page describes how the enumerations are serialized in Tiger :
http://java.sun.com/j2se/1.5.0/docs/guide/serialization/relnotes15.html

Now it is clear that if RMI covers the general case, almost no game programmer would like to stay in the general case.  :-/

JNAG is serializing an enumation by sending the index of the element in the declaration of the enum, and doesn't need to send the type since it is implicit.  Smiley

---------  d(0_o)b  --------


Some news : I encountered some problems with the reference handling. I found a solution, but it may ask me too much time to do it immediatly (I am in an hurry, I have to implement a game by using the working features of JNAG only .. only 2 weeks before the first deadline).

I prefer to wait a little before I release a preview, because for now it is too much experimental .. still a lot of details to fix.

<a href="http://www.le-moulin-studio.com">Le Moulin Studio</a> - MMO Technologies and Services.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline karmaGfa

Junior Member




Miaow


« Reply #40 - Posted 2005-01-03 15:44:37 »

I wish you a Bugless and Happy new year 2005.

Some news about JNAG :
  • The project I was doing in Java was cancelled, and I will quit my job in the end of this month to take a rest in my own country for a while Tongue. JNAG won't be stoped : I will continue it, but perhaps slowly.
  • Since I won't have a job for a non-determined duration, I decided to release JNAG under GPL instead of LGPL just in case I could get something from companies who wish to use it for a closed source commercial purpose (I like the open source spirit, but hey .. I need to eat also Roll Eyes).
  • The JNAG project, even with a lot of vote "yes", is still not approved and I don't know why. I got no answer at all for my emails to the moderator of this forum.


<a href="http://www.le-moulin-studio.com">Le Moulin Studio</a> - MMO Technologies and Services.
Offline phazer

Junior Member




Come get some


« Reply #41 - Posted 2005-01-04 10:13:50 »

Your project has been approved now. Smiley

I've implemented my own light-weight serialization and async RMI framework in my project. I would be interested in looking at your code to see if the two implementations can be merged.

Offline karmaGfa

Junior Member




Miaow


« Reply #42 - Posted 2005-01-05 00:25:30 »

Hi,

Yes, the project has been approved.
I opened a forum on the site of jnag, let's move to it.

I am still a little shy to show my code for now .. it is still in dev, not robust ..

<a href="http://www.le-moulin-studio.com">Le Moulin Studio</a> - MMO Technologies and Services.
Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Dwinin (3 views)
2014-07-29 10:59:34

E.R. Fleming (20 views)
2014-07-29 03:07:13

E.R. Fleming (8 views)
2014-07-29 03:06:25

pw (39 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (50 views)
2014-07-17 23:47:54

danieldean (42 views)
2014-07-17 23:41:23
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!