Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (754)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2
1  Game Development / Networking & Multiplayer / Re: Transactions on: 2007-04-02 20:14:31
Let me know if you have any specific details you want to walk through, but otherwise we should probably wait until you can see the APIs, so we can talk in a little more detail, and so I don't have to be so mysterious Smiley

I can certainly wait. Its not that far in the future and we have a huge sell job here internal to do anyway that will, I am sure, take longer..

Thanks for the info
2  Game Development / Networking & Multiplayer / Re: Question about genericity in the class ManagedReference on: 2007-04-02 17:20:25
Now, how can a ManagedReference could reference an object whose type is incompatible with its generic type?  Smiley

Thats simple. In the multi-stack objects can be created on various servers potentially running various versions of your app (or at least at upgrade time).. And thus one set of code could put one type of object in the store and then another node of the cluster could retrieve that object using say your new code and the type cast would fail or code fail.. There is no garuntee in a distributed system and I think they wanted to imply that in their API..
3  Game Development / Networking & Multiplayer / Re: Transactions on: 2007-03-30 17:03:54

Now, just so you know, the current stack has a limitation that will find if you try to build the Service you described. The currently implemented Transaction Coordinator is a simple, single-node implementation that doesn't work with external coordinators and cannot support more than a single durable participant in a given transaction. Since what you need to implement would have to be a durable participant, the current stack does not support your use case. This is a known limitation of our implementation, and the only reason we haven't addressed it is that we simply haven't had the time and resources. We plan to support the use case you describe. We may try to make the Coordinator pluggable,  so that you could write your own to support this case, or we may wait until we can build a richer implementation ourselves. In the meantime, please let me know if you want to talk in more detail about what's going on here.

Yes I would definately like more info on this. I am currently working on a Manager API for integrating JDO PersistanceManagers into the stack (Of course it is currently constrained by the fact that I have no idea what the stack allows and doesn't allow.).. Part of that will eventually involve connection pooling, thread integration, as well as transaction integration. It sounds as if the transaction integration and thread control may be a bit more difficult or even impossible?

I did some analysis of our requirements and have found only two real use cases. The first is a single transaction for any given user generated event (aka user message).. The second is multiple independant transactions. I figured a child task could allow us to achieve that. I have yet to find a case where we needed inner transactions nor optamistic transactions. However, the transactions will in all cases span a number of objects. Obviously, otherwise we wouldn't really need transactions..

Now my knowledge of your server's internals is limited at this point. But the transaction coordination of JDO is a combination of code level and database level. Obviously transactions are begun, commited, rolled back at the application level. But the interoperability of the transaction within the data sphere is accomplished via the various JDBC isolation levels. My current train of thought suggests that for each task I would get a PersistanceManager from a pool of PersistanceManagers and bind it and its transaction object to the task. When prepare() was called within the stack it would call the transaction begin() method. Likewise, when abort() or comit() where called on the context it would pass those on to rollback() and comit() on the transaction.

As the task executed it would access JDO PersistanceCapable objects as needed by the implementation. Each of these objects would or would not be able to access/change their various properties based on the transaction isolation level of the under lying JDBC connection the PersistanceManager was using?? So in essance wouldn't the coordinator in this case be the database? How does the Sun Game Server effect that? Does it have something to do with the existing DataManager interoperating with this additional PersistanceManager?

I guess I am not sure what you are talking about when you refer to the Coordinator and whether it is the JDO world or the DataManager world the issue applies to..

Now one area of concern for me was what would happen if a ManagedObject held a reference to a PersistanceCapable object? I am not sure at this point. But I do have a solution assuming it becomes an issue. And that is via another Manager called the DelegateManager which provides application custom Delegate implementations to the runtime environment. These Delegates would provide, via JDOQL, access to various top level JDO objects negating any need to maintain references to them. Any particular task could load the objects it needs when it needs them to do the operations it needs to do and release them. And thus our ManagedObjects would simply need to keep reference to the keys necessary to locate the particular object instance. Those keys being simple Serializable objects. Of course JDBC transaction isolation levels would allow synchronization across the various nodes of a cluster as it relates to loading/persisting the state of these JDO objects.

Now JDO implementations do some cache optimization. I am not sure exactly how I might go about dealing with that. I guess maybe the Coordination you speak of may effect how that is managed?
4  Game Development / Networking & Multiplayer / Re: Transactions on: 2007-03-27 20:14:32
Does that help clarify what's going on?

Yes thank you..

With all that said, let me ask a question Smiley What exactly are you trying to use the existing DataManager for in your system?

We have two types of objects in our application. Session oriented (non-shared), and long-term shared. We plan on using the DataManager to handle the session oriented (non-shared) objects such as a user for example. There will be numerous state properties of a user that need to exist for the lifespan of the user's session or for a game session but no longer. On the other hand we have data that is maintained in RDBMs outside of the game server. Our Game Server application will be but one entity that accesses that data. While most of our clients are java, serialized data does not make for good quieries if you know what I mean. And a simple name oriented primary key is insufficient for our data structures.

Examples of applications that share data with our application include data entry, reporting, web applications, database based batch processes that do various things, etc..

It seems the DataPersistance mechanism in the game server is sufficient when all the data is being maintained and handled internal to the game server and nowhere else. But if you have a piece of data that the game server and a web server both need access to for different purposes?? Well it doesn't work real well there.. And well disk is getting cheaper by the day but never-the-less it doesn't make much sense to have multiple copies of your data.. Trying to keep it in synch would not be worth the effort.

Also, can you qualify what you mean by "better ACID guarantees"? I'm curious what's not being provided right now, and whether you think there's something important that we should provide..

I was under the understanding that the Durability requirements of the DataManager were relaxed to improve performance. For state items (ake session oreinted stuff) that is fine and desirable. (Thus the reason we still intend to use it). But when you are commiting a sale of say a $50,000 object with all the associated credit look ups etc you need absolute garuntees of durability plus you need extended control over the transaction.

As for replacing the DataManager I was not aware that could be done. Even so there are a number of very relevant uses for it even if shared data isn't one of them.

Some people might say our application is a game. But it is not in the typical sense. Its real money and real business that is driving it..
5  Game Development / Networking & Multiplayer / Re: Transactions on: 2007-03-26 15:15:40
Another question. JDO has the ability to be single threaded of multithreaded. I know Sun has gone to great pains to try and make the application level appear as a single threaded model. But I am guessing I will have to build the JDOPersistanceManager to be multithread safe? Is that correct? Or can I rely on Sun's single thread model to ensure that the manager will never have concurrent calls made to it?
6  Game Development / Networking & Multiplayer / Transactions on: 2007-03-26 14:31:45
I assume transaction support in the stack will be discussed in more detail with the release of the stack extension guide. However, I was wondering if I could get a few questions answered.

We are looking at building a PersistanceManager which would be fairly similar to the DataManager but with better ACID garuntees. We were thinking of using JDO to do that. (Aka litterly the PersistanceManager).. However, we would like to hide the transactional nature of it from the developer and bury it in the Manager implementation.  Call it DurableManager for lack of a better name..

Will the stack API allow integration of additional transactional contexts. (Aka we want to use both the DataManager's transactional context as well as the JDO transactional context at the same time). Using the DataManager for short lived non-shared state management and the DurableManager for long lived shared data management. (NOTE: This means that when a Task runs we would like to integrate the JDO's transaction.begin() and when it finishes without an exception it would call transaction.commit() or if an exception was thrown it would call transaction.rollback() all behind the senes or in the manager implementation)..
7  Game Development / Networking & Multiplayer / Re: User Authentication on: 2007-03-25 12:22:47
Actually, there's something similar to what you're proposing in the current model. While an Application can't get access to the Identity object, a Manager can.


Thats good news.. Thanks..
8  Game Development / Networking & Multiplayer / Re: User Authentication on: 2007-03-24 16:53:12
Keep in mind that if you liked the old JAAS system there is no reason you couldn't write it as a  plug-in authenticator.

One thing that might be worth asking is if the Idenitity object can be made available through the ClientSession. Currently it seems like it is little different from a Principal object. (aka nothing but a name).. It would be nice for Authenticator impls to attach Permissions or Credentials or some other properties on an implementation by implementation basis. Of course all of that would be worthless if the application couldn't get reference to them because they were shielded by the ClientSession object.

I would propose that the ClientSession API include a

public Identity getIdentity()


public Identity[] getIdentities();

method so that the Authenticator could implement any type of Identity it wanted and include any type of property with the Identity impl and finally the application could actually use them..

Of course you could leave the Identity interface opaque requiring application specific casting or it might look something like:

public String getName()
public PermissionCollection getPermissions()
public String getProperty(String key)

Anyway, just a thought..
9  Game Development / Networking & Multiplayer / Re: Upgrading to 0.9, some random notes on: 2007-03-23 20:09:05

The *only* way to remove a managed object from your object store is with an explicit call to the DataManager to do so.

There is a fine point here in that you can create listeners that *aren't* managed objects.  If you do so then these listeners are non-persistent and *will* get garbage collected when they are  no longer needed.  They also will live in memory for their entire life cycle.  Some managers take extra pains to recreate these listeners from an internal persistent record when the system goes down and comes back up, but that is up to the individual manager's behavior.  It is not a requirement.


I just wanted to clarify. If I create ChannelListeners that are ManagedObjects and don't keep a reference around it never goes away?

The only way to get access to those listeners after they are created unless I keep a reference to them myself some how is via named binding. When the user leaves the channel it is essentially garbage. As there is no way to get a reference to it again unless I kept one originally or it is name bound. How would I go about destroying it?  How would I know when to destroy it?

If ChannelListener had a method like destroy() or unlinked(), or detached() or something that got called when the user left the channelor when the channel was closed it could clean itself up. But the code that calls leave() has no way to access the Listener and the listener has no way to know the user left or the channel's been closed as the API stands today..
10  Game Development / Networking & Multiplayer / Re: Upgrading to 0.9, some random notes on: 2007-03-23 16:25:12
Was running some tests on the DataManager. Apparently, if you create a managed object and then also bind that managed object with a name using the setBinding method, and then finally later you call removeObject() supplying that managed object it will also clear the named binding.

Aka you do not need to worry about cleaning up named bindings. All you have to do is remove the object itself and the named bindings will be cleared for you..

This is particularly of interest if you wish to implement your ChannelListeners as Managed objects and you want to bind them with a name. When the channel is closed or the user leaves the channel the listener (aka managed object) will be removed from the data store. And as such any named binding you may have had as well.

Additionally, if you hold a ManagedReferences to a managed object that was removed explicitly via the removeObject method, all future calls to get() or getForUpdate() on that reference will throw an ObjectNotFoundException.
11  Game Development / Networking & Multiplayer / Re: packet overhead on: 2007-03-21 23:18:30

Just did some testing of my current client, I added some debug into it to dump the number of bytes sent and received. The result was     

Sent 16472 and received 166582 bytes of game data in 74 seconds, thats 0.21679688KBps and 2.1982422KBps

Then I ran IPTraf on the box hosting it

┌ TCP Connections (Source Host:Port) ────────── Packets ─── Bytes Flags  Iface ┐
│┌                          =     358     39511 DONE   eth0  │
│└                          =     500    264461 CLOSED eth0  │

That means the server (as in box, not SGS) sent 264461 bytes, but of that, only 166582 was game data, the rest was TCP packet headers and SGS overheads. Now I admit that most of my messages were only 72 bytes of game data, there is a minimum of 20 bytes of TCP header. My question is, how much does SGS add per messages?


Yea I already looked at that using a sniffer. And the anwnser is it depends on the type of message and the delivery mechanism you use (aka RELIABLE, ORDERED, etc)..

Messages sent on the channel seem to be sized rougly like this: UTF encoded length of channel name + length of data + senderSessionId length + 19 bytes. Some of those 19 bytes is header data and some seems to be delimeter data.. Maybe shorts, ints, or longs describing the length of the data, sessionId, and channel name? I'm guessing on that but it seems to fit. Not sure exactly what the header stuff is but it varies based on the type of message being sent.. Keeping in mind that it seems the protocol itself has messages it sends that are not based on anything you are sending. For example when you join a channel a message is sent to the client. Probably the message that triggers the joinedChannel event.

Data sent directly to the server and back seems to be a bit more efficient. It is roughly message.length + 7 bytes. I am guessing that is the length of the message bytes and maybe some basic header stuff? Something like that.

12  Game Development / Networking & Multiplayer / Re: RFE, common type for Channel and ClientChannel on: 2007-03-21 22:49:25
I also want to point the asymetry between the send functions of the ClientSession (that is using a SessionId to identify the receiver) and the ServerSession (that is using a ClientSession to identify the receiver).

Question: Why ?

Well I am just going to guess but I bet it has something to do with security. Aka the ClientSession object on the server contains the userid and the sessionId, the client on the other hand only has access to the sessionId. If your client has no issue providing the world with all your servers userids then you could certainly build something to distribute those to the clients. But if they had sent them out automattically and you had a need to conceal that kind of info you be out of luck..

13  Game Development / Networking & Multiplayer / Reconnect on: 2007-03-21 16:22:28
I was wondering if the reconnect mechanism was defined enough for to to give us some info on it. Some of the questions I have about the reconnect process include:

1) Does the AppListener's loggedIn() method get called again when a user reconnects? I am guessing not!

2) I am assuming that the original ClientSessionListener's disconnect method never gets called if they reconnect within the alloted time even if they reconnect to a different node in the cluster?

3) Does the user's ClientSessionId change when they reconnect?

4) Does the user's ClientSession get reused or recreated?

5) Should we be referencing ClientSession with ManagedReference or can a java reference do the job and how does that work as it relates to a user reconnecting to a different node upon a server failure?

6) Since we bind a user to a channel using the ClientSession and if the user reconnected to another node in the cluster due to server failure obviously the object couldn't be the same  as it relates to session == session.. Does that matter?
14  Game Development / Networking & Multiplayer / Re: ClientSessions on: 2007-03-21 16:01:36
Thats basically it.

Note though that if you didn't want to store info about a DEMO user this would be no problem.
You would simply special case a user name of "demo" or "guest" and create a new, unbound ClientSessionListener ManagedObject for everyone who joined that way and remove them from the ObjectStore on disconnect.

About the only other issue I can think of is that, currently, if your reject a user by returning null from loggedIn rather then by rejecting in the authenticator you cannot pass a "reason" string back to the client.

Oh and DONT use disconnect() in loggedIn().  Thats wrong and will make odd thinsg happen in the current release.  To reject the user just return a null ClientSessionListener

Ahhh some very good points.
15  Game Development / Networking & Multiplayer / Re: ClientSessions on: 2007-03-21 15:24:14
Does that make sense?

Yes but maybe I ought to change the way I ask the question. What would I lose if the name was not unique? I was thiking about doing the authentication at the application level rather than extending the stack by building my own Authenticator like discussed in anoher thread. However, I would still use the SimpleClient's basic authentication I would simply always return the client type for the userid and a null password. Obviously if I used a null password I would use the NullAuthenticator.

But by doing that I could have dozens of ClientSessions all with a getName() of say "Full" or "Demo" as an example.

I guess it would make it impossible to bind the old ClientSessionListener with the new ClientSession as I would have no way to locate the ClientSessionListener until after the binding had already occured in the AppListeners.loggedIn() method. Is there any other issues I might encounter?

16  Game Development / Networking & Multiplayer / ClientSessions on: 2007-03-21 14:29:56
I was wondering if anyone knows if the ClientSession's identity (aka the value returned from getName()) MUST be unique? I notice that each ClientSession object has a ClientSessionId which appears to be unique. But does the identity also have ot be unique with a game? (Aka does the ClientSession get persisted using the sessionid or the identity?

17  Game Development / Networking & Multiplayer / Re: Managing ManagedObjects on: 2007-03-20 16:10:21
Yes, I was kinda thinking along the lines of registering a class with the Datamanager.

   public interface ManagedObjectTranslator
         public Object translateObject(ObjectInputStream in)

   AppContext.getDataManager.registerObjectTranslator("", new CoolTranslator());


   AppContext.getDataManager.registerObjectTranslator(CoolManagedObject.class, new CoolTranslator());

Then, when you deserialize at startup, and there is a problem the datamanager could pass the OIS to the translator and cross it's fingers. 

Your idea is interesting. But the registration wuld have to occur in the startup properties otherwise there would be no way to translate for the AppListener itself (aka the first object loaded before any programatic registrations could occur)..

I'm not so sure I like the idea of the AppListener being a managed object. Seems it would be more useful if it were constructed and initialized every time the server/app was started. Of course it wouldn't be useful to store state in if that was the case..
18  Game Development / Networking & Multiplayer / Re: About Channels on: 2007-03-20 16:00:22
Another case I case see the server wanting to attach to the channels is with pseudo users per-sey. Obviously if you have a bunch of clients communicating moves etc via the channel if you have server side users (aka artificial players) wouldn't they need to be kept in the loop as to where the human players were moving? Or would it be better for the clients to send both to the channel and to the server those moves?
19  Game Development / Networking & Multiplayer / Re: Managing ManagedObjects on: 2007-03-20 15:00:59
One thing I might suggest is a shutdown() method on the AppListener that is called when the server is shutdown properly and or if the app is shutdown properly if there is such as thing.. This would allow game developers to do some things for themselves if their application allows it

Another possible change would be to add a boolean to initialize on the AppListener. It would be true if the object was being loaded for the first time and false if the object had been loaded from the store. Obviously if this was the case then initialize would need to be called everytime it was loaded. Anyway, this could allow the upgraded version per-sey to go through its objects and do something useful..

20  Game Development / Networking & Multiplayer / Re: Managing ManagedObjects on: 2007-03-19 22:05:41
That being said, I don't have any idea how to implement such a thing.

Well Serialization kinda allows you to do that. You just have to implement the writeObject readObject methods. Of course you would need to have defaults for certain fields and your read/write code could get fairly complicated depending on the complexity of your object and possibly its children objects.

But both Externalizable and Serializable have a means to do this on a class by class basis. But it seems to me that maybe a better way to do this would be to use more of a JDO system rather than a pure serialization model.

I mean are we using serialization to store persistant data (aka data that should be stored in a database in a traditional way?) Or are we using it to store short lived objects for failover purposes and clustered access? If the former maybe their in lies the problem and the solution is to use a JDO model as opposed to a serialization model..

Just a thought..
21  Game Development / Networking & Multiplayer / Re: Managing ManagedObjects on: 2007-03-19 20:55:11
Yup. we're doing a  *lot* of thinking about both sides of that issue.

(How to recreate individual objects and how to avoid having to recreate *all* the objects when one changes in a serialization incompatible way.)

I'd love to see a wish list of behaviors and any other suggestions you have...



To me the server should automattically drop anything in which the serialversionId doesn't match without erroring. Thus when new versions of the app are deployed previously existing objects would be discarded.

Additionally, in a production server one would imagine there owuld be a startup/shutdown. Maybe objects should live only as long as the server remains running. When it is properly shutdown (aka other than a crash) maybe a destroy() method or something like that on the AppListener should be called allowing it to cleanup how it wants to clean up.

Finally, in a production environment there should be someway of deploying an application. Maybe as part of that deployment process here could be some indicator as to whether or not the objects in the datastore should be flushed or not?

Just some ideas.. Although a huge cluster (in which you might upgrade one at a time while the others remained running) could pose an issue with these ideas.. Maybe the persistant store should store its objects based on their version and the version a particular node is requesting?? Just an idea...
22  Game Development / Networking & Multiplayer / Re: About Channels on: 2007-03-19 20:47:21
I think they are useful, it just needs to be noted that listening on a channel will have serious performance implications if it's a large throughput chanel and that you should carefully consider if what you are doing is the right approach.

There is also the question of whether the server throwing a non-retryable exception whilst processing a message on a channel should effectivly vito that whole message, for all clients, or if it's purly a server processing error, and not an indication to trash the message. It doesn't fit with the virtual lan analogy if a server can vito a packet, but analogies are not always a perfect description Smiley, can you clarify what the desired behaviour was and if this is indeed a bug, or an oversite, or intended behaviour.



I think they could be extremely useful. Just because most people want to do X doesn't mean everyone does. Let the game developer decide whether to use ChannelListeners or not. And if they do use them then chances are they are using them for some reason. The ability to veto messages could be hugely beneifitial to some while others would simply always return true or not use ChannelListeners at all..

Can I ask you what you use ChannelListeners for? Your first paragraph suggests you are using them..
23  Game Development / Networking & Multiplayer / Re: About Channels on: 2007-03-19 19:54:22
Yup.  You can think of a channel as a "virtual LAN".

I realize what they are currently intended for. What i am asking is why not make them more?

It is currently a high speed broadcast mechanism. It COULD also be addressing scheme.

Now I am not privy to the actual clustered code (there may be something there that makes it impossible) but from what I can tell of the current public code it would be trivial to make it robust enough to handle either usage. (Obviously ones application and its needs would drive which way it was used) Aka if your application needs high speed don't use ChannelListeners. If you don't and you would rather use channels for addressing then do use ChannelListeners..

The reason I brought it up is that if ALL applications should use Channels only in the way you describe then why have server side ChannelListeners in the first place? I imagine it was due to some need. What was the need? And what are they good for if not to update the state of the server or to allow the server to mutate the message in transit?
24  Game Development / Networking & Multiplayer / Re: About Channels on: 2007-03-19 18:47:36
I think you are laboring under some misapprehension about channels.

The primary purpose of the channel system is to provide as fast-path through the communications layer for clients to chatter amongst themselves.  This is necessary for games that pump a lot of data between clients, such as actions games or even some MMOs for movement.

In order to get this kind of data rate a path is needed through the system that does not involve the logic and persistence   layers for every packet.,  This is why the tutorial tells you to be wary of channel listeners, they actually, to some degree, defeat the purpose of channels to begin with.  If you try to listen to every packet on the stream then you are going to perform no better then if you sent the packet to the server and then it echoed it back to a list of users.

The latter sounds like what you are  looking for and is trivial to implement in the app logic itself.

Note that there *is* a way to get at the channel stream with custom logic without involving the persistence mechanisms and that is to write a custom transport with your own filtering logic embedded therein.

Note that a chat system actually could be easily implemented without the channel mechanism as its throughput needs are much lower.  The channel system is intended as a high-throughput mechanism.

I don't really understand your security issue right now though.  if you don't want a user to be able to talk on a channel, don't joint them to it.  If you need them to be able to listen but nto speak then use two channels, one for "read" and another for "write".

Am I missing something?


1) Our situation is a little different then what you are describing. In our system we DO WANT TO handle almost every single message on the server as the server is what maintains the state and thus the relevantness of every packet. However, the number of groups (what we call channels) of users numbers in the hundreds.

2) We have learned that trusting the client to implement what we expect is a bad idea. Made worse by the fact that the Sun Game Server is open source. There is absolutely nothing preventing people from writing their own clients to it. All they need is a userid/password to the server and they could then do almost anything they wanted.

3) All though SSL over the transport offers a certain level of obscurity for message transmittion I have found that one can easily decompile a program and reverse engineer its data delivery/processing mechanism and the only safe code is that which runs on the server.

4) Our transactions (and they are mostly transactions) result in or involve the transfer of fairly significant amounts of money measured in the thousands for a transaction millions every hour. Security is absolutely necessary.. And real security.. Not security through obscurity.

As for what one intends channels to be, shouldn't one let the developer of the particular application determine what is an isn't the best solution for their environment/program? For those applications that actually do have high transaction volume on the channels and don't have a need to monitor them then don't put listeners on them. But for those that do need/want the listeners doesn't it make sense that they are useful? I mean the listener API as it stands today will take the hit if they use them one way or the other. Why not make them useful if they are going to take the hit anyway?
25  Game Development / Networking & Multiplayer / Re: User Authentication on: 2007-03-19 11:58:58
Duplicate user id's are easy to detect, and you just have to return null from the AppListener loggedIn method, I already do that.

Being the Sun Game Server I suspect that they figured that most of us would be using username/password type authentication, and anyone using anything more complicated was in the minority, but could do it be extending simple client and the authentication implementation in the server. IIRC Jeff has said the docs to cover the stack extension are due out the same time the stack goes open source, which is due for Java One.

What is currently shipping is a restricted distribution binary, so you can't publish anything with it anyway yet, which makes security not an imediate concern. I'm sure somewhere down the line someone will wonder why the whole comms layer is not encrypted in some way, IIRC (no, I don't have any references, but its something I remember reading) a large number of modern games encrypt all the wire traffic anyway to stop people inspecting and manipulating the protocol. Again, I suspect that the stack can be extended to include this functionality.


I realize that they are playing the numbers game. But there is more. The concept of JAAS is very Java specific. They are also planning on an API that will work with various client languages such as C and I am sure others.. And JAAS Callbacks are inherintly Java most especially when you start talking about custom callbacks. I mean how would you send Callbacks in language neutral way? You would have to define the Callbacks as messages of some sort. Thus eliminating the ability to create custom ones.

And I realize that language nuetrality is a core objective and an important one. It would be possible to define the API to support it. Even if they had to have the Authenticator implementation do the encoding/decoding of the messages being transfered between the server and the client.. Aka how to encode/decode custom callbacks? Let the implementation do it!

And your right in the long run I am sure they will include support for SSL. Which could be an alternative.
26  Game Development / Networking & Multiplayer / Re: User Authentication on: 2007-03-19 03:16:43
I litterally started looking at Darkstar yesterday, what is the JAAS Callback methodology?

Lots of things changed since the last public release. In the previous release they had a TCP<SomethingOrOther> client. When the connection was established with the server the server would iterate a list of Validators (kinda like JAAS Login Modules). Each Validator had the ability to send a collection of Callback handlers from the server over the wire to the client. Each time this occured a handleAuth(Callback[] callbacks) method was called on the ClientListener.

Aka the JAAS Callback methodology. In this case I could implement a Callback called Challenge which included a random string and a numeric. Thus when I got the password from the user I could hash it with the random string numeric number of times before setting it on the PasswordCallback. And all of that could be returned to the server and parsed without concern of the type of transport.

In the current release they have simplified (over simplified in my estimation) the communications stack with this SimpleClient. Now rather than the server challenging the client at all the protocol (aka SimpleClient) defines a getPasswordAuthentication() and it calls it and sends it to the server during connection irrespective of whether or not the server even cares. Obviously PasswordAuthentication only accepts username/password. So it is impossible to implement any sort of SmartCard, DigitalCert, DigestAuth, or any type of Auth mechanism other than username/password. Likewise, since it is part of the protocol (hardcoded) rather than an abstract pattern you must replace the SimpleClient with a REAL client to do anything different.

But the biggest hassel of this methodology is that you MUST implement some sort of userid/password even if the server doesn't even care? Aka if you plan on using NullAuthenticator which is the default by the way on the current release..

To me it makes more sense to impl the JAAS Callback methodology in a generic fashion and then have them provide a simple and null implementation for those 90% of users but provide the other 10% with the ability to quickly implement something stronger without having to write our own client/server transport and or apply layering to our application as you suggested.

By the way there may be an issue with your idea of implementing the auth system after connection. When the connection occurs the ClientSession is created by the server.. (aka out of your control). To construct this object it needs a name. That name is the userid of the user. What happens when the server has two ClientSession objects with the same USERID (aka Name)?? I'm not sure but I doubt it could be good. And without authenticating prior to creating this object you open up a potential security vulnerability.
27  Game Development / Networking & Multiplayer / Re: User Authentication on: 2007-03-19 02:54:39
Well even if they don't provide a secure transport for passwords, I don't see that it would be much of an issue of writing my own.  One simple way of doing it would be to simply allow the client to connect to the server under all circumstances, then after the connection is established build your own authentication protocol after the fact.

Yep! Of course if all you wanted to do was encrypt the data you could do that with an Authenticator Impl. On the client you would simply need to encrypt the password before setting it on the PasswordAuthentication object.. Of course you would have to encode the encrypted password as a series of characters.. (aka Base64 or something like that)..

Or they could simply return to the JAAS Callback methodology and make the Container useful and extensible? (Aka if we are going to write everything ourselves where do we want to stop?)
28  Game Development / Networking & Multiplayer / Re: User Authentication & Security on: 2007-03-19 00:27:38

I've created my own custom authenticator by deriving from IdentityAuthenticator.  I had a security question, when the NamePasswordCredentials object gets passed to the server, is the transmission of that password encrypted in any way?

No there is no encryption. It is sent in clear text across the wire.

I was attempting to write a challenge/auth system kinda like S/Key or Digest Auth in HTTP.. Seems that to accomplish that not only would I have to write a custom Authenticator but also a replacement for SimpleClient as simple client has no means to pass the challenge to the client.

Why they got rid of the JAAS Callback approach is beyond me. I guess they wanted it to be simple for 90% of the users.
29  Game Development / Networking & Multiplayer / Re: Upgrading to 0.9, some random notes on: 2007-03-18 22:52:49
Moved to About Channels
30  Game Development / Networking & Multiplayer / Re: Upgrading to 0.9, some random notes on: 2007-03-18 19:22:36
Some random notes on channel message life cycle

Messages sent from a client via the channel will be processed on the server before being sent to the other clients attached to the channel. Channel messages will first be run through the channel listener attached during channel creation. It will then pass through the ChannelListener attached when the sending user joined the channel. No other user's server side channel listeners will receive the message.

ChannelListeners attached when a user joins a channel are only called when THAT USER sends a message on the channel and then only if sent from the client tier and only after the ChannelListener added during channel creation is called.

If any of the server side channel listeners throw a non-retryable exception then message delivery is terminated at that point. I am guessing that this is not Sun's intent but that is the effect. So if you have the need to terminate message propigation simply throw a non-retryable exception from either of the server side channel listeners.

Any comments?
Pages: [1] 2
DesertCoockie (33 views)
2018-05-13 18:23:11

nelsongames (75 views)
2018-04-24 18:15:36

nelsongames (70 views)
2018-04-24 18:14:32

ivj94 (752 views)
2018-03-24 14:47:39

ivj94 (82 views)
2018-03-24 14:46:31

ivj94 (622 views)
2018-03-24 14:43:53

Solater (98 views)
2018-03-17 05:04:08

nelsongames (179 views)
2018-03-05 17:56:34

Gornova (405 views)
2018-03-02 22:15:33

buddyBro (1065 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!