ID:153748
 
On my MUD I need to create a command which will reboot() the world, and automatically connect the clients back to their correct mob. The problem im faced with is this:

When you connect with telnet, your key is equal to that of your IP. That would be fine, if people couldn't share an IP address. Their key looks like so: "Telnet @ip_address", or "Telnet x @ip_address" if multiple connections have been made from the same IP, where x is the amount of connections made at the time of the most recent clients connection(I.e. "Telnet 1 @ip_address", "Telnet 2 @ip_address" etc).


If I could rely on reboot() reconnecting the clients in the order they connected, I could use the key to figure out who had which mob, but I can't. What if someone disconnects during a reboot, or the order simply depends on who can reconnect the fastest(most probable)? Then someone might end up in the wrong mobile!

I need to find a way to figure out which client has which mob in the world(Not the one they connected with), and am unable to use key nor IP address. Any thoughts? My final solution would be to use IP addresses, and disallow multiple connections from the same IP, but thats a huge limit on my MUD, and I don't want to do that.
Alathon wrote:
I need to find a way to figure out which client has which mob in the world(Not the one they connected with), and am unable to use key nor IP address. Any thoughts? My final solution would be to use IP addresses, and disallow multiple connections from the same IP, but thats a huge limit on my MUD, and I don't want to do that.

The only other way I could think of, is have maybe a sort of 'owner' variable assigned to the mobs, and upon login, match up the mob with the owner variable. Not sure how well it would work, but you're smart, I'm sure you'll think of something. ;)

~>Volte
In response to Volte
Volte wrote:
The only other way I could think of, is have maybe a sort of 'owner' variable assigned to the mobs, and upon login, match up the mob with the owner variable. Not sure how well it would work, but you're smart, I'm sure you'll think of something. ;)

~>Volte

That won't work. What will I set the owner variable to?
In response to Alathon
Alathon wrote:
Volte wrote:
The only other way I could think of, is have maybe a sort of 'owner' variable assigned to the mobs, and upon login, match up the mob with the owner variable. Not sure how well it would work, but you're smart, I'm sure you'll think of something. ;)

~>Volte

That won't work. What will I set the owner variable to?

You could, of course, simply not allow people to reconnect to their mobs immediately -- they'd be saved by name and password (like in every other MUD), and their characters would be independent of their IP address. When the world reboots, every character would be saved, and then they'd necessarily be forced to enter their name and password again. Once they've done that, though, everyone would be as normal.
In response to Spuzzum
Spuzzum wrote:
You could, of course, simply not allow people to reconnect to their mobs immediately -- they'd be saved by name and password (like in every other MUD), and their characters would be independent of their IP address. When the world reboots, every character would be saved, and then they'd necessarily be forced to enter their name and password again. Once they've done that, though, everyone would be as normal.

Yep. But that defies the entire point of the hotboot command, which is to automatically reconnect everyone, so they can continue playing even though the world is being changed.
In response to Alathon
Yep. But that defies the entire point of the hotboot command, which is to automatically reconnect everyone, so they can continue playing even though the world is being changed.

Yes, I know... but since a true hotboot doesn't seem to be possible in BYOND's architecture, I'm just offering it. ;-)
In response to Spuzzum
Spuzzum wrote:
Yes, I know... but since a true hotboot doesn't seem to be possible in BYOND's architecture, I'm just offering it. ;-)

Sure it is, its just kind of limited. Means I have to block off duplicate IP addresses. Already have it working.

It would be easier if you could find out the order in which the clients were set to reconnect, then you could figure out which client would be connected to which mob in the order they reconnect, and simply allow each client a grace time to reconnect, and if not met skip to the next one and up the count one.

I believe that's how MUD's do it, although I can't be entirely sure. It seems like an easy way to determine who connects to two, without having to acquire some "unique" info from the client itself. One way to accomplish it could be to give the client a unique connection_id, that corresponds to the position in the connection qeue upon a reboot(). This could be used as the "unique" identifier on MUD's(Unique within a single session), and make this very easy.
In response to Alathon
One way to accomplish it could be to give the client a unique connection_id, that corresponds to the position in the connection qeue upon a reboot(). This could be used as the "unique" identifier on MUD's(Unique within a single session), and make this very easy.

Unfortunately, that's not guaranteed to work. Since people connecting will connect at different times, 216.66.169.99 1@telnet will not be guaranteed to be the same person twice. Since the connection id would have to be generated after the person connected, there'd be no way of certifying that the given person is the same person as he/she was last time.
In response to Spuzzum
Is there anything in BYOND to report the port number of a connected client? A software reboot still uses the same port number, so if you match up the IP and port number you'll have the correct client. Unfortunately I can find nothing in the reference to report a client's port number.

You could go ahead and reconnect all the players that were present before the reboot who had unique IP address and require the others to log in normally. I think that's about the best compromise you're going to get.
In response to Shadowdarke
Shadowdarke wrote:
You could go ahead and reconnect all the players that were present before the reboot who had unique IP address and require the others to log in normally. I think that's about the best compromise you're going to get.

Hmm. I guess that is better than just blocking multiple connections from the same IP, until/if the ability to view ports is implemented.
In response to Alathon
I haven't really messed with it yet but could you use client side saving?
In response to English
English wrote:
I haven't really messed with it yet but could you use client
side saving?

Now there's an idea!

A variant of this: when the player logs in *for the very first time*, you have (s)he enter a temporary file location (\windows\temp for example) that your game has read/write access too. This is where a 'session' key is stored - composed of their playername and a randomly generated number/alpha-numeric code/hash/timestamp/whatever. This 'key' is used for determining who gets what mob on hot-re-booting. You can have the player use the same key all the time (transparent to them after the first time), or generate a new key on-the-fly after each login to ensure a sort of 'session security'.
In response to digitalmouse
digitalmouse wrote:
A variant of this: when the player logs in *for the very first time*, you have (s)he enter a temporary file location (\windows\temp for example) that your game has read/write access too. This is where a 'session' key is stored - composed of their playername and a randomly generated number/alpha-numeric code/hash/timestamp/whatever. This 'key' is used for determining who gets what mob on hot-re-booting. You can have the player use the same key all the time (transparent to them after the first time), or generate a new key on-the-fly after each login to ensure a sort of 'session security'.

But how do I determine what client each specially generated key belongs to? Perhaps show me a step by step walkthrough of what the game does, so that I can understand?
In response to Alathon
Alathon wrote:
But how do I determine what client each specially generated
key belongs to? Perhaps show me a step by step walkthrough
of what the game does, so that I can understand?

Hmm... ok...let`s try this...

When a client connects for the first time, I'm guessing you go through some sort of character creation process which then gets assigned to a mob in the game world. The last thing you ask is the location of a place on thier computer (again, maybe default to a standard temp directory) where the clientkey can be stored.

You generate the key (let's say digitalmouse_123), store it in the known directory, store it with the mob associated with that player/key combo, and also save it into a multidimensional array (I guess a DM list would suffice) that looks something like this (character name, player key, temp direcotry, last known IP address):

var/list/client_list = list(player = "ratman", key = "digitalmouse_123", tmp_dir = "/tmp/", known_ip = "10.0.0.9")

Of course this would be filled in dynamically from the login form processing...

You would also want to store all the IP connections in a array/list too, so that you have them to quickly search through - I'd also sort the IPs if possible, making duplicates group together (helps speed the searching process I would think).

Then on hotboot, just loop through the connections, looking for matches in your player list. Something following this process:

start a loop of all the client ip addresses collected in the last session
connect to a client ip
find that ip in the client_list (mentioned above)
look in the temp directory given
if the client key matches a mob key then we have a winner!
make the connection to the mob for that player, play continues where left off...
rinse, lather, repeat

Remember, that is just a basic outline of the process - I'm sure others here can convert this into the correct DM syntax...

Does that help any?

In response to digitalmouse
digitalmouse wrote:
When a client connects for the first time, I'm guessing you go through some sort of character creation process which then gets assigned to a mob in the game world. The last thing you ask is the location of a place on thier computer (again, maybe default to a standard temp directory) where the clientkey can be stored.

Telnet has no ftp() capability, making this impossible =(.