Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ MUDs ➜ General ➜ Suggested protocol for server to client "out of band" messages
Suggested protocol for server to client "out of band" messages

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22 23  

Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #315 on Fri 05 Mar 2010 01:11 AM (UTC)
Message
Nick Gammon said:

Xtian said:

In our experience 7-10 commands per seconds is a good value. After that incoming messages will be buffered and delayed.
But connections in char-mode will need a higher value if you count each incoming character as a command.


10 commands per second? Per player? What on earth are they typing?


I'm thinking aliases, maybe?
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #316 on Fri 05 Mar 2010 01:18 AM (UTC)
Message
David Haley said:

I would be tempted to use all characters from the md5 hash. "If it's good enough for git..." I was going to say that compression would probably help here, but maybe it wouldn't be too useful after all because hashes are not likely to be very repetitive. Even so, I'm much more worried about unintentional collisions than I am about sending a few more bytes.

Even with server-side detection of collided hashes, it's still only over one session. A MUD could have many sessions with reboots etc., so I'm not sure that would be enough.


Well as I said, even after a reboot, virtually everything will hash the same - these aren't GUIDs after all. In other words, before the reboot you have "a large wolf is standing here, with blood dripping from its jaws", and after the reboot you will have the same thing, and thus the same hashes.

You could make the hash larger, and with MCCP in use probably the compression would absorb a lot of that extra stuff, because if the same wolf keeps walking around the hash for it will quickly be compressed.

I'm not sure that you want to jump from 10 hash characters to 40 "just in case". Why not go to 80 then? If you can demonstrate that with (say) a 14 character hash (56 bits) that the likelihood of a collision with 100,000 known MUD objects is extremely small, then should be acceptable.

I mean, the very occasional (like 1 in 10 years maybe) incorrect message to a single player is hardly the worst problem facing MUDs these days.

I'm talking about managing risk here - there is a risk when you get in your car and drive you will be killed, and you don't stay at home until the risk can be demonstrated to be zero, now do you? People smoke, drink, drive cars, fly in aircraft, all of which activities have a well-known non-zero risk factor. If the risk of dying was 50%, then certainly you might stay home. If it is 1 in 100,000 you will probably go out.

Anyway, I want to point out that the number of characters in the hash is not central to the design. Individual MUD admins can crank up the number of character to reach their comfort level, and if a 40-character hash makes you comfortable, well and good.

The hash is being sent as a string, and stored as such at both ends. The size of the string can change over time, and in any case there is nothing in the design that fails if you make the string larger.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #317 on Fri 05 Mar 2010 01:21 AM (UTC)
Message
Twisol said:

I'm thinking aliases, maybe?


Indeed, but a lot of MUDs throttle input anyway (Achaea springs to mind here, where you can't walk very quickly, and thus that slows down your speedwalking attempts).

Also Smaug only pulls one command at a time out of the queue every 0.25 seconds anyway, and I think starts to throw in another delay after it processes a couple of commands (the WAIT_STATE macro).

And WoW of course, has the "global cooldown". All designed to stop a single player from logging on, visiting 5 continents, and completing 20 quests in 5 seconds.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #318 on Fri 05 Mar 2010 01:22 AM (UTC)
Message
Here's a suggestion. With every item, store a counter of sorts, which starts at 0. If two items clash, and they are demonstrably not of the same internal template (assuming the server has a concept of models and instances), increase the counter of the newer object and re-hash until it's unique.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #319 on Fri 05 Mar 2010 01:29 AM (UTC)
Message
Nick Gammon said:

Twisol said:

I'm thinking aliases, maybe?


Indeed, but a lot of MUDs throttle input anyway (Achaea springs to mind here, where you can't walk very quickly, and thus that slows down your speedwalking attempts).


From my experience, the input is still processed, not really throttled. It's just a limit on how quickly you can move. Try doing 20 'ql' commands and one 'score', and see how soon the score comes out. (But note that the first command is always processed separately from the rest, for some reason; it's well known in combat circles, and people stick a no-op command in first so they know the rest are processed atomically.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #320 on Fri 05 Mar 2010 04:22 AM (UTC)
Message
Nick Gammon said:
Well I don't call processing things after 0.25 seconds "slowing everything down". And I already process requests in batches (10 I think at present), so there is extra throttling there.

When I unthrottled Darkstone such that input was processed as it arrived (while still making sure that gameplay was unaltered) people immediately noticed and reported that the game was far more responsive -- even before I told them that I did anything. So I think that a quarter of a second is actually pretty noticeable.
There's a difference between how fast you walk around and how fast commands (like say, tell, etc.) are processed.

Regarding the hash, I think that the checksum idea I proposed would address the risk quite considerably. Although the hash length doesn't make assumptions about the client or server, having the extra (small) checksum does force support on both ends.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Xtian   (53 posts)  Bio
Date Reply #321 on Fri 05 Mar 2010 04:27 AM (UTC)
Message
Nick Gammon said:

Xtian said:

In our experience 7-10 commands per seconds is a good value. After that incoming messages will be buffered and delayed.


10 commands per second? Per player? What on earth are they typing?



With numpad walking you can reach 5 commands/s easily. Add in some triggers that fire when you enter rooms and you reach 10.
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #322 on Fri 05 Mar 2010 05:59 AM (UTC)
Message
So, no global cooldown, huh?

Anyway, I have been a bit distracted from doing another demo of the hash concept, as I have been doing a mapper for Achaea, based on the one I showed in the YouTube video.

One of the things that makes this mapper work so smoothly is that they use the telnet subnegotiation "out of band" idea themselves (using their ATCP protocol).

With the recent changes to MUSHclient it is quite trivial to pick up those messages, and act on them.

And the nice thing about the telnet messages is that they work reliably, regardless of how much the player fiddles with their prompt, or setting up short or long room-name displays etc.

In short, it "just works" (TM).

Not only does it work, but it is fun to use. You can RH click on a room and speedwalk to it by the shortest route (in the case of Achaea the short delay between movement commands is allowed for by the plugin). It shows the room name, the area name, and you can search for a particular room by name, or find nearby areas.

I am negotiating with them to add extra out-of-band data like, "is there a shop here?". We have in-principle agreement to do just that, as I believe that the way that MUDs are going to survive is for MUD client developers, and MUD server developers to work cooperatively together for the good of the community.

I will release the plugin for people to play with, as soon as these improvements are ironed out (extra data from the server, that is).

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #323 on Fri 05 Mar 2010 06:06 AM (UTC)
Message
Nick Gammon said:
I am negotiating with them to add extra out-of-band data like, "is there a shop here?". We have in-principle agreement to do just that, as I believe that the way that MUDs are going to survive is for MUD client developers, and MUD server developers to work cooperatively together for the good of the community.


Ahh yes, they mentioned they had gotten in touch with you on their blog. This might be an opportune time to say I've always wanted a Room.Environment message?
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #324 on Fri 05 Mar 2010 06:08 AM (UTC)
Message

The blog? Maybe I should read it. ;)

This is the current Achaea mapper:

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Twisol   USA  (2,257 posts)  Bio
Date Reply #325 on Fri 05 Mar 2010 06:14 AM (UTC)
Message
Nick Gammon said:
The blog? Maybe I should read it. ;)


Link below: [1]. The specific place it was mentioned is in a comment on Screencasting: [2].

[1] http://anvil.ironrealms.com/

[2] http://anvil.ironrealms.com/?p=150
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #326 on Fri 05 Mar 2010 08:25 PM (UTC)

Amended on Fri 05 Mar 2010 08:27 PM (UTC) by Nick Gammon

Message
David Haley said:

Well, that's not really how hash math works, and I agree that the chances are small, but I guess I don't see the point in adding that risk when it's so easy to reduce the probability by just adding a few characters.


I did some tests. On the test server with the standard SmaugFUSS areas I made the server generate a hash for every mob, object, area and room. This was the results:


770 mobs, 1313 objects, 23 areas, 41676 rooms.
Size of hash_info_map is 2825


It is interesting that there must have been a *lot* of duplication (auto-generated rooms maybe?) because out of 43,782 total items we only got 2,825 hashes. It shows just how much data hashing can save, we have substantially reduced the amount that has to be sent down compared to sending the details for all 43,782 items.

The next test was to reduce the hash size until I got a collision, which happened at 6 characters (ie. 24 bits).

At 7 characters of hash (28 bits) there was no collision, although obviously we are on the cusp there.

This would appear to indicate that for safety's sake (and for larger MUDs) we should at least double the number of characters of hash (from 7 to 14), and possibly a bit more as well.

So for my test server I have increased it to 20 characters (80 bits) which allows for 1,208,925,819,614,629,174,706,176 different hashes, and should be safe for a space of 1,099,511,627,776 items.

So in other words, 14 characters should be safe on a minimal SmaugFUSS, but 20 characters should cover most MUDs.

Remember, you will have trouble storing 1,099,511,627,776 different items in memory, that is like 1 terra-items. Even if you only used 1 byte to store each one, you wouldn't fit them all in current memory. Plus you would have to hire a few trillion builders to generate all the mob/room/object descriptions.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Sproingie   USA  (8 posts)  Bio
Date Reply #327 on Fri 05 Mar 2010 09:13 PM (UTC)
Message
If you want UUIDs, why not just use real actual UUIDs, for which there is a solid spec and tons of fast solid library support? Sure they're long, but some of these complicated alternatives are looking a lot worse.

That said, a hash isn't terribly bad for a cache key either if you want to verify it against its content, but they don't do much to encode identity, so if you need a different identity across restarts, you're back to UUIDs.
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #328 on Fri 05 Mar 2010 09:33 PM (UTC)
Message
Indeed. My proposed spec which started a few pages back suggested that items be identified by at *least*:


  1. A GUID - this must be unique, is not a hash, and identifies the item on the MUD; and

  2. A hash of the attributes of the item. So for example, if the server repops "a fierce wolf" every minute, each one of those thousands of wolves has the same hash (thus saving downloading the description to the client), but each one has a unique GUID.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Gammon   Australia  (23,165 posts)  Bio   Forum Administrator
Date Reply #329 on Fri 05 Mar 2010 09:46 PM (UTC)

Amended on Fri 05 Mar 2010 11:43 PM (UTC) by Nick Gammon

Message
Just to clarify in case I wasn't clear earlier on:

The GUID is not a hash, and is not based on one. You simply increment a number (I am using a 64-bit number). There are ways of making sure you start with a different number on each reboot (for example, taking the time and multiplying by a large-enough figure). Or, the server could write to disk every minute the largest number it has used so far, and then you just allow for the maximum number it could possibly allocate in a minute.

From my figures further up the page, the server generated 43,782 items (mobs, objects, areas, rooms) - these would all have a unique GUID. But it only used 2,825 hash entries. This is because a lot of those things shared the same attributes (mobs had the same name, objects looked the same etc.).

Now as the MUD powers along, and players kill things, and loot them, the number of GUIDs allocated would keep increasing quite rapidly. But not rapidly enough to exhaust a 64-bit GUID space (18446744073709551616 items). But the number of hashes will stay more-or-less constant, as the MUD keeps replacing mobs by ones of the same name.

And my test was a worst-case scenario - it assumes that the description of every mob, and every object, and every room, needed to be hashed and sent to the players in one session. Although probably that would eventually happen - since the hashes are supposed to last for ever.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

928,612 views.

This is page 22, subject is 23 pages long:  [Previous page]  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22 23  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home