Vaultster for NWNX4

[Hialmar]

We will once again resume working on this at ALFA.

Here is the last solution we talked about:
- use Vaultster (or ActivatePortal but it seems broken currently) for
server portaling ;
- do backups to a local folder when required (before portaling and
when logging out) ;
- use a folder syncing solution to synchronize all backup folders
(either Dropbox, Microsoft Mesh, a webdav shared directory, rsync...).

What I have done so far is:
- port Vaultster to NWNx4 (see above) ;
- add functions to it so that we can copy a bic from one place to another.

If you have other ideas we are interested by them.

Our current issue is the following :
- Let's say player Joe using character Bob is playing on server A.
- Server A's ISP fails. Joe gets disconnected. Server A backups
Joe.bic to the backup folder but the syncing solution cannot copy it
to the shared directory (because there is no working Internet connection) ;
- Joe asks the manager of server B for him to get a recent (but not
last) version of character Bob to be copied to server B.
- Joe plays with Bob on server B. When he logs out this version of Bob
(let's call it V1) is copied to the backup.
- Later on server A ISP gets back up. Server A syncing solution then
overwrite Bob V1 to an older version of its bic file

Do you have any idea how we could solve this problem ?

I'm thinking that maybe the sync solution could solve it automatically
using server timestamps but I'm unsure if this would work with servers in different timezones and with non synchronous clocks.
_________________
Hialmar, A Land Far Away Infrastructure Administrator

[Skywing]

ActivatePortal works. What difficulty are you having with it?

[Zebranky]

I believe it was a scope misunderstanding -- ActivatePortal is not intended to transfer the .bic between servers (hence the need for Vaultster).
_________________
Win32 SVN builds: http://www.mercuric.net/nwn/nwnx/

<Fluffy-Kooshy> NWNx plugin is to this as nuclear warheads are to getting rid of fire ants.

<ThriWork> whenever I hear nwn extender, I think what does NWN need a penis extender for?

[Hialmar]

Ah yes sorry for that.

Still there seems to be a problem with ActivatePortal and Vaultster:
ActivatePortal works with an index in the GSID folder.
If player Joe has characters Al, Bono and Chuck on server A and plays Chuck.
If he uses ActivatePortal to go to server B and he has characters Al, Bono, Charles and Chuck he will get logged with Chuck instead of Charles.

We are unsure of this and we will need to test that but it seems that it was coded on the assumption that /servervault would be common/shared between the modules, so there was no checking for whether the .bic you were just using when you portalled still existed when entering the second module. If the index position was empty, you'd be thrown back into character creation instead.
_________________
Hialmar, A Land Far Away Infrastructure Administrator

[Skywing]

No, that's incorrect. Depending on server-side configuration, the client is either given the RESREF of the character to log on with (if a server-side character was in use), or a raw BIC to log on with (i.e. if a local vault character was in use).

Now, if the character RESREFs (generally created by the first and last names concatenated together) don't match on the local and remote server and server-side characters are in use, unexpected behavior may result. This is typically most likely to be the case where the same character name has been used multiple times and a unique serial number has been appended to the RESREF. Characters are named in the server vault directory based on the the form RESREF.bic, under the community account name of the incoming player. (Note that community accounts aren't really related to GameSpy, but that's a nit point.)

Note that if you are really synchronizing characters between servers, the you'll have the same RESREFs everywhere and even multiple characters with the same name shouldn't be an issue.

The handshake here for portal works as follows (in NWN2 -- I'm assuming it's probably identical in NWN1, but I've only examined the protocol for NWN2 in detail):

Terms:
Client - the portaling player's client
Local server - the server that the player is portaling from (i.e. the source server)
Destination server - the server that the player is portaling to (i.e. the destination server)

1) Local server sends Portal.ActivatePortal to the client, informing the client of the remote server hostname / port / password information.
2) Client pings (BNXI) the remote server to check that it is up. If the remote server responds to the ping, then the client sends Character_Download.Gimme to the local server. The purpose of this message is to request the login character information to use for the remote server connection.
3) The local server replies with Character_Download.Fail and a RESREF (for example, "firstnamelastname") to use if the player was logged on with a server character. The RESREF supplied is the same RESREF that the client used to log on as a server vault character on the local server. Otherwise, if the player was logged on with a local character, the server dumps the player's character to a raw BIC and transmits it to the client with a Character_Download.Reply message.
4) The client breaks the connection to the local server and makes a new connection to the remote server. Assuming seamless portal mode was engaged, the client either attempts to log on to the remote server with the given RESREF (if the local server sent a Character_Download.Fail message) or the given local character file from the local server (if the local server sent a Character_Download.Reply message).

--

For reference, this is my implementation of the local server's selection of which character data should be sent to the client:

[Hialmar]

Thanks for the detailed infos.

As we will send bics with Vaultster we shouldn't have any problem then.

That's one less problem to take care of.

By the way, here is the solution we chose to implement so far:
Vaultster with a master server (pushing bics on save/logout to all servers).

i.e. each time we save (even on PC logout but not when portaling obviously), we will also send the bic to the master server (a linux version of Vaultster server) which will in turn send this bic to all other servers.

This way, if a server is down we can still connect to any other server with the last version of the bic.
_________________
Hialmar, A Land Far Away Infrastructure Administrator

[Skywing]

As long as you are keeping the bic filenames intact and aren't changing them, then you ought to be fine, yes.

Be sure to design a mechanism where an offline server gets the latest character data when it comes back up from downtime (i.e. maintenance/module updates/etc) if you choose such an approach.

[Hialmar]

The plan is that when the server comes back online, players will need to move back their characters there using portaling.

If they do not, the next time they save or logout the bic will be sent to the server that came back online.

Not sure if we need more than that.

Anyway, if a player logs on a server where their character isn't supposed to be, they are dominated and can't do anything. They need a DM to validate them.
_________________
Hialmar, A Land Far Away Infrastructure Administrator

[Hialmar]

Just a note to tell that we have a running version of all this.

The code can be found here:
http://sourceforge.net/projects/alfavault/

Hopefully we will soon start testing it in a distributed environment (ie not on my computers only). When everything is ironed out I will put everything on virusman's svn.
_________________
Hialmar, A Land Far Away Infrastructure Administrator