Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (576)
games submitted by our members
Games in WIP (497)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  ClientSessions  (Read 1367 times)
0 Members and 1 Guest are viewing this topic.
Offline floersh

Senior Newbie





« Posted 2007-03-21 15: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?

Offline Jeff

JGO Coder




Got any cats?


« Reply #1 - Posted 2007-03-21 15:46:50 »

I was wondering if anyone knows if the ClientSession's identity (aka the value returned from getName()) MUST be unique?

The name is provided  by the authenticator, (The entire internal Identity object actually is. That will make more sense when you have the document on writing Authenticators that I'm writing now.)  So the answer to your question is that it is completely up to the policy of the authenticator.

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

A ClientSession and everything relating to it is only valid for the life of the session.  So while it is unique at a  point in time, its not necessarily historically unique.

If you want a unique identifier other then name, it should be provided by your authenticator in an extended Identity object that you use a custom manager/service pair to read.  Again, this is all in the doc I'm writing now.

Does that make sense?


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline floersh

Senior Newbie





« Reply #2 - Posted 2007-03-21 16: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?

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

JGO Coder




Got any cats?


« Reply #3 - Posted 2007-03-21 16:32:58 »


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?



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

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline floersh

Senior Newbie





« Reply #4 - Posted 2007-03-21 17: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.
Pages: [1]
  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.

xsi3rr4x (12 views)
2014-04-15 18:08:23

BurntPizza (11 views)
2014-04-15 03:46:01

UprightPath (24 views)
2014-04-14 17:39:50

UprightPath (10 views)
2014-04-14 17:35:47

Porlus (27 views)
2014-04-14 15:48:38

tom_mai78101 (49 views)
2014-04-10 04:04:31

BurntPizza (108 views)
2014-04-08 23:06:04

tom_mai78101 (208 views)
2014-04-05 13:34:39

trollwarrior1 (176 views)
2014-04-04 12:06:45

CJLetsGame (182 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
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!