[MUD-Dev] Trusting the client, encrypting data

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

"Eli Stevens" <listsub at wickedgrey.com> writes:

> B's state).  I'm having a hard time coming up with a good solution
> to this problem for dynamic data, unless all of the deltas are
> sent (perhaps encrypted, perhaps not) to be applied as soon as the
> base cell is revealed.  That sounds pretty rough on the client,
> esp. if the room A player waits for a long time before opening the
> door.

> Hmm.  Is there a way to take an encrypted cell and apply a delta
> to it _without_ being able to decrypt the cell itself?

This depends, of course on what you allow players to do, what they
typically do and how you structure your protocol. If you use 16-bits
per moved object and 100 objects have changed in one cell then you
can do with 200 bytes. That is rather ok, fits into a packet.

> Also problematic is that cells become visible as a unit, rather
> than incrementally (whole room vs. line of sight through a door).

Depends on the granularity/resolution and design?

>>   (Note: Encrypted data shared by multiple users could also be
>>   sent over HTTP in order to take advantage of caching
>>   proxies. You should also distinguish between encrypted chunks
>>   with short-term and long-term data, but that goes without
>>   saying.)

> This would effectivly result in groups of players all learning the
> key as soon as the server tells the first player in the group what
> the key is.  It might make for some interesting scouting
> mechanics, or squad-based p2p knowledge sharing (offloaded from
> the server).

Yeah, I thought about that, but in theory he could just redistribute
the data and not a key. So this is perhaps a more deep-rooted
problem?  I don't think this would be a problem for a typical MMO,
where it would be nice to have a "team-view" of an area, as you
suggest it might actually be interesting. It could become a problem
with big alliances, but then it depends on how long your cells
remain valid. If they only last for one hour and the world is big,
then it should be fairly ok?

However, caching is probably best for some less critical
information, such as libraries that contains bits and pieces rather
than the links between them that you need in order to reconstruct
the contextualized meaning of the information (what does this mean
in my scene?) or contexts/dictionaries for compression schemes.

--
Ola - http://folk.uio.no/olag/
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev