logo logo

 Back to main page

The NWNX Community Forum

 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
 
Vaultster for NWNX4
Goto page Previous  1, 2
 
Post new topic   Reply to topic    nwnx.org Forum Index -> Development
View previous topic :: View next topic  
Author Message
Hialmar



Joined: 15 Jun 2005
Posts: 32

PostPosted: Tue Sep 28, 2010 9:26    Post subject: Reply with quote

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 Sad

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
Back to top
View user's profile Send private message
Skywing



Joined: 03 Jan 2008
Posts: 321

PostPosted: Wed Sep 29, 2010 11:51    Post subject: Reply with quote

ActivatePortal works. What difficulty are you having with it?
Back to top
View user's profile Send private message
Zebranky



Joined: 04 Jun 2006
Posts: 415

PostPosted: Wed Sep 29, 2010 13:51    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message Visit poster's website
Hialmar



Joined: 15 Jun 2005
Posts: 32

PostPosted: Sun Oct 10, 2010 15:38    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Skywing



Joined: 03 Jan 2008
Posts: 321

PostPosted: Sun Oct 10, 2010 20:51    Post subject: Reply with quote

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:

Code:

bool
NWClientSession::OnRecvMsgCharacter_Download_Gimme(
   __in NWN::ProtocolMessage & Message
   )
/*++

Routine Description:

   This routine handles an inbound Character_Download.Gimme message from the
   client.  This message requests the login character information to use for
   the handoff portal transfer.

Arguments:

   Message - Supplies the message to dispatch.

Return Value:

   The routine returns true on successful message dispatch, else false if a
   protocol violation was detected.  On catastrophic failure, an
   std::exception is raised.

Environment:

   User mode, LogonStateCharacterConfirmed or higher.

--*/
{
   NWN::ExoParseBuffer * Parser = Message.GetParser( );

   Parser;

   //
   // If we have a server side character, just hand the player the resource
   // name to use.  Otherwise, hand the player the local character data that
   // is to be used for the login.
   //

   if (GetIsServerSideCharacter( ))
      SendMsgCharacter_Download_Fail( m_CharacterResRef );
   else
      SendMsgCharacter_Download_Reply( );
   
   return true;
}

//
// Character_Download (Send)
//

void
NWClientSession::SendMsgCharacter_Download_Reply(
   )
/*++

Routine Description:

   This routine sends the contents of the player's creature to the client.
   This tells the client to log on using a local vault login for the transfer
   server for the portal request.

Arguments:

   None.

Return Value:

   None.  On catastrophic failure, an std::exception is raised.

Environment:

   User mode, LogonStateAreaLoaded.

--*/
{
   NWN::ProtocolMessage  Message(
      NWN::ProtocolMessage::CLS::ServerToPlayer,
      NWN::ProtocolMessage::CMD::Character_Download,
      NWN::ProtocolMessage::Character_Download::Reply);
   NWN::ExoBuildBuffer          * Builder = Message.GetBuilder( );
   CreatureObject               * PlayerCreature;
   GffFileWriter                  BicWriter;
   std::vector< unsigned char >   BicContents;

   //
   // First, save the player to an in-memory GFF.
   //

   PlayerCreature = GetPlayerCreature( );

   ((GameObject *)PlayerCreature)->SaveToGff( BicWriter );
   BicWriter.Commit( BicContents, GffFileWriter::BIC_FILE_TYPE );
   
   //
   // Now send it to the client.
   //

   Builder->WriteCExoLocString( PlayerCreature->GetFirstName( ) );
   Builder->WriteCExoLocString( PlayerCreature->GetLastName( ) );
   Builder->WriteDWORD( (unsigned long) BicContents.size( ) );

   if (!BicContents.empty( ))
      Builder->WriteVOIDPtr( &BicContents[ 0 ], BicContents.size( ) );

   SendProtocolMessage( Message, true );
}

void
NWClientSession::SendMsgCharacter_Download_Fail(
   __in const NWN::ResRef32 & CharResRef,
   __in bool Type4Character /* = false */
   )
/*++

Routine Description:

   This routine sends the player character's resource name to the client.
   This tells the client to log on using a server vault login for the transfer
   server for the portal request.

   Despite the name of the message, this does *not* imply that the server
   transfer has failed.

Arguments:

   CharResRef - Supplies the preferred login resource name of the character.

   Type4Character - Supplies a Boolean value that indicates whether the
                    character was not loaded a saved game.

Return Value:

   None.  On catastrophic failure, an std::exception is raised.

Environment:

   User mode, LogonStateAreaLoaded.

--*/
{
   NWN::ProtocolMessage  Message(
      NWN::ProtocolMessage::CLS::ServerToPlayer,
      NWN::ProtocolMessage::CMD::Character_Download,
      NWN::ProtocolMessage::Character_Download::Fail);
   NWN::ExoBuildBuffer * Builder = Message.GetBuilder( );

   Builder->WriteCExoString( m_Server->StrFromResRef( CharResRef ) );
   Builder->WriteBOOL( Type4Character ); // Loaded from IFO/saved game.

   SendProtocolMessage( Message, true );
}
Back to top
View user's profile Send private message
Hialmar



Joined: 15 Jun 2005
Posts: 32

PostPosted: Mon Oct 11, 2010 9:44    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Skywing



Joined: 03 Jan 2008
Posts: 321

PostPosted: Mon Oct 11, 2010 19:01    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Hialmar



Joined: 15 Jun 2005
Posts: 32

PostPosted: Mon Oct 11, 2010 21:02    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Hialmar



Joined: 15 Jun 2005
Posts: 32

PostPosted: Sat Nov 27, 2010 16:33    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    nwnx.org Forum Index -> Development All times are GMT + 2 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group