Gammon Software Solutions forum

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

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

Home \| Users \| Search \| FAQ
Username:	Register forum user name
Password:	Forgotten password?

(New message)

Subject:	Suggested protocol for server to client "out of band" messages
Name:	Your forum user name. Register forum user name
Password:	Your forum password. Forgotten password?
Message:	[quote=Sproingie] 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. [/quote] Message to be posted (in English, please).
Forum codes:	Check this if your message uses 'forum codes' or templates (auto-detected for new posts). Forum codes Templates

Save this message ...

Subject review (reverse sequence)

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

KaVir Germany (114 posts)

Date

Thu 21 Apr 2011 11:59 PM (UTC) [ quote ]

Message

Keirath said:
The biggest complaint I have gotten out of it from others is the fact that it sends a prompt everytime the out of band messages are sent. Is there any way to avoid this?

The approach I used in my MSDP snippet is to set a flag whenever out-of-band data is sent to the client, then the mud checks the flag before sending a prompt or blank line. Sending a new command clears the flag.

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Thu 21 Apr 2011 12:36 AM (UTC) [ quote ]

Message

On my version it sends a blank line. Kinda annoying but since it is just for testing I just install my "omit blank lines plugin".

There must be a good reason, you would have to trace through the code (maybe use gdb) to work out why the out-of-band stuff triggers the prompt.

- Nick Gammon

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

Posted by

Keirath (9 posts)

Date

Wed 20 Apr 2011 04:44 PM (UTC) [ quote ]

Message

I have show_status working on an SWR and its updating properly. First off, I have to say this has been a really awesome advancement and has opened the door for alot in the SWR community. Currently, we are working on some graphical output for space combat and the likes.

The biggest complaint I have gotten out of it from others is the fact that it sends a prompt everytime the out of band messages are sent. Is there any way to avoid this?

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Wed 20 Apr 2011 05:26 AM (UTC) [ quote ]

Message

You can do the "loadstring" without preceding it with setfenv. Then whatever is in the string has access to global variables, and potentially it might change them too.

- Nick Gammon

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

Posted by

Henry Tanner Finland (23 posts)

Date

Wed 20 Apr 2011 01:29 AM (UTC) [ quote ]

Message

a quick question:
I need to access global stuff so what should I replace "setfenv" with?

I got this!

Posted by

Orik USA (182 posts)

Date

Fri 12 Mar 2010 11:59 PM (UTC) [ quote ]

Amended on Sat 13 Mar 2010 09:18 AM (UTC) by Orik

Message

I have just found out that when I snoop a player, all my plugins break and I can see their show_status.

Guess I'll have to figure out a 'workaround' on this.

***EDIT***
What I did was put the show_status below the snoop part and it's working fine now.

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Sat 06 Mar 2010 10:57 PM (UTC) [ quote ]

Message

Xtian said:

For persistent GUIDs you could concat the counter you are using now with the reboot time of the server-session. This is what we do. (and a separator in between)

That's a sensible idea. Then the internal number can start at 1 and just be concatenated with a fairly small boot time number. That should allow for any contingency.

- Nick Gammon

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

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Sat 06 Mar 2010 10:28 PM (UTC) [ quote ]

Message

Nick Gammon said:
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.

Well don't forget that a lot of these aren't necessarily people manually creating items; every corpse has several stages of decomposition, a game with dynamic descriptions could have a description for each combination of day/night/season/etc., and so forth. Obviously this won't get you to 'terra-items' but it shows that even with a nominal space of, say, 1,000 things you might actually be dealing with well over 5,000 attribute hashes.

Twisol said:
You shouldn't have to create new GUIDs, considering that most areas only have a specific amount of mobs.

Well, until you get auto-generated mobs, or mobs that are otherwise created without going through the area reset (e.g., summoning spells). I don't see much point in persisting a mob's GUID beyond its own death, considering that we don't need to worry about keeping enough GUIDs around.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Xtian (53 posts)

Date

Sat 06 Mar 2010 06:46 AM (UTC) [ quote ]

Message

For persistent GUIDs you could concat the counter you are using now with the reboot time of the server-session. This is what we do. (and a separator in between)

Posted by

Twisol USA (2,229 posts)

Date

Sat 06 Mar 2010 02:02 AM (UTC) [ quote ]

Message

Briefly: in WoW, the ID that each mob has persists across death. You shouldn't have to create new GUIDs, considering that most areas only have a specific amount of mobs.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Fri 05 Mar 2010 09:46 PM (UTC) [ quote ]

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

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Fri 05 Mar 2010 09:33 PM (UTC) [ quote ]

Message

Indeed. My proposed spec which started a few pages back suggested that items be identified by at *least*:

A GUID - this must be unique, is not a hash, and identifies the item on the MUD; and
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

Posted by

Sproingie USA (8 posts)

Date

Fri 05 Mar 2010 09:13 PM (UTC) [ quote ]

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.

Posted by Nick Gammon Australia (18,770 posts) bio Forum Administrator

Date

Fri 05 Mar 2010 08:25 PM (UTC) [ quote ]

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

Posted by

Twisol USA (2,229 posts)

Date

Fri 05 Mar 2010 06:14 AM (UTC) [ quote ]

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

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.

59,364 views.

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

Reply to this subject Start a new subject Refresh page

Go to topic: Search the forum

Comments to: Gammon Software support
Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )