[MUD-Dev] The Lag monster...

[J C Lawrence]

On Thu, 11 Nov 2004 13:55:25 -0800 (PST)
Harlan Beverly <hbomb at fastai.com> wrote:
> "Sean Kelly" <sean at f4.ca> wrote:

>>> I can see how optimizing the data sent might help performance,
>>> but I don't think data transfer is the bottleneck in regular
>>> gameplay.

> By your own admission, in some cases Data Transfer is one of the
> bottlenecks.

I smell a solution desperately in search of a problem and failing to
find one.  Most of us on this list are some sort of engineers.  We
can do a lot better than this.

I see a number of core problems with the proposal:

  1) What the problem space is has yet to be defined past the very
  vague arm waving level.

  2) Whether in fact that problem space is in truth a problem for
  the operators in that field hasn't been determined though several
  in the area have suggested that it isn't for them.

  3) Why such a proposed device would be a reasonable address to
  that problem space hasn't been mentioned.

  4) Whether in fact such a device could effectively address the
  problem area hasn't been determined or discussed, let alone
  logically demonstrated.

That makes it rather hard to know what is being discussed let alone
its valid applications.

> So for these players, data compression, grooming, etc. would
> indeed improve their apparent laggieness.  (the question would be
> to what extend?)

What hard evidence do you have that such perceived lag is in fact
appreciably created by last mile constraints rather than
intermediate IP cloud routing and packet-loss issues?  I'm not
saying that this isn't a reasonable supposition, just that as an
"obvious fact" it needs to be demonstrated.

There's a wide range of technological devices and services that
would be Really Cool and Utterly Bodacious (tm) if they were only
deployed.  Some of them are truly wonderful and easily demonstrated
as everything they are sold as.  The problem is that their value is
only delivered after N% end-user deployment, where N is typically
near 40% or higher -- and that's an absolute deal killer.  They'll
never see the light of day in terms of effective market penetration.
Why is your approach different?

>> "Justin Randall" <logic at jrlogic.dyndns.org> wrote:

>>> Offloading *authoritative* server calculations to one or more
>>> clients only leads to new avenues of grief. Rule #1 in online
>>> gaming: NEVER trust the client, even if other clients are
>>> watching.

> I find this an interesting point, because 'the jaggies' is caused
> by incorrect extrapolation results, etc.

> What would happen to MMORPGs if you COULD TRUST THE CLIENT?  For
> example, all players of a game must have a special NIC card (which
> I will gladly sell).  This NIC card has preloaded firmware which
> is Digitally Signed (and cannot be modified without the creators
> digital signature)...

You are assuming that transport security solves the larger problem
rather than being one of the smaller and less significant components
in a verifiable service definition.  In fact you're assuming that
verifiably correct data stream deserialising equates to a verifiably
correct server<->client_application data stream, which isn't in fact
true.

Consider for example a transparent ethernet bridges immediately
upstream of your device which intercepts, exposes and potentially
rewrites all packet streams.  Such a bridge could be an external
device (eg $10 i486), or an application on the client host running a
loopback through a spare NIC into your NIC.  Such devices are
cheaply available and setup (eg any Linux distribution), and the
programming required for the packet munging is not difficult.  Or,
how about an installed kernel module on the client machine which
exposes the operation of your device and which intercepts and
rewrites both the data the application receives from the device
(potentially on the basis of OOB data from the ethernet bridge), or
which intercepts/rewrites the data the client application sends to
your device?  Impossible to reliably detect and not a particularly
unusual or hard programming project, especially as prior art for
other devices and protocols is already well established and
available in the field.

> This NIC card (with a PowerPC + Digitally Signed Firmware), could
> perform certain interpolation/extrapolation/ and even certain
> Server functions... (Not sure what), that could help distribute
> the processing load away from the Server computer.

Are larger scale MUD servers known to be particularly CPU bound
rather that IO bound (IO to network, IO to memory bus, IO to storage
etc)?  Why would a special purpose enhanced NIC be a suitable
address for that problem instead of simply buying more/faster
general purpose CPUs which don't require specialised vendor and
platform specific programming?  If your device does offer some sort
of end-to-end guarantee, how would the device's operation and
service delivery be affected by intermediate network behaviour
(variant routing, packet loss, out-of-order packet delivery, etc)?

> What effect would this have on Game performance, apparent lag,
> etc?

That's rather up to you to demonstrate.

--
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
claw at kanga.nu               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev