| Mailing List | | Home | | MUD Dev - Discussion of MUD system design, development, and implementation | | Mac Game - Mac game development | | Rivers of MUD - a Diku and Merc based multiuser dungeon | | SMAUG | | DirGames - Director, Shockwave, and Flash Game Production |
|
|
 | | | Trusting the client, encrypting data | Trusting the client, encrypting data 2003-11-26 - By Ola Fosheim Grøstad
Back
I've suggested something similar, a long time ago, but will try
again. Hoping for some discussion.
One core problem in virtual worlds with a large user-base is that
there are no surprises as the client has access to the entire
database which is static. This is viewed as necessary in real-time
interaction as the responsiveness of the internet is not guaranteed.
A solution to this is to presend data in a neighbourhood arround the
location currently occupied by the avatar. Unfortunately this will
let a hacked client expose any surprises "behind locked doors" and
thus give hard-core users an unfair advantage.
However, this can easily be solved by (symmetrically) encrypting
data on a cell-by-cell basis using unique keys for each cell. The
problem is then reduced to sending the decryption key in a timely
fashion.
How do you achieve timeliness? I would suggest sending a datagram
(could be a TCP/IP fake in order to circumvent router priorities as
you only need 32-64 bits to be transferred) down 2-3 different
connections. Is this sound given the net topology? Or are the
bottlenecks usually near the end-user? Comments
appreciated. Another solution is to rely on next generation network
protocols sending only keys with top priority in order to limit
costs, but I am not sure when this will become a reality. Anyone?
(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.)
--
Ola - http://folk.uio.no/olag/
__ ____ ____ ____ ____ ____ ____ ____ ____ ____
MUD-Dev mailing list
MUD-Dev@(protected)
https://www.kanga.nu/lists/listinfo/mud-dev
|
|
|