Reconnect

Networking & Multiplayer
#1

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?

#2

Obviously this all applies to the full multi-stack…

Correct. Also you do not get a disconnected message until the reconnect window has passed without a reconnect.

Yup see above

I don’t believe so. I need to double check that with the comm team but I bleieve to all external view its as if the client never left.

The only reason why we have a “reconnecting/reconnected” callback in the client API is because there are things clients may want to stop doing during a reconnecting, such as pumping a flood of packets, and they may want to alert the user as to why the pause. (eg “Lost Connection To Server” type messages)

ClientSession remains valid

Java reference. (ClientSession is not defined as being a ManagedObject.)

No. Its the contents of the ClientSession object that really matter and those are duplicated.

Routing between nodes is totally invisible to you.
[/quote]