(keitai-l) Re: SIM and J2ME

From: Chris Wooldridge <Chris.Wooldridge_at_bullant.com.au>
Date: 09/25/03
Message-ID: <8AFFE88038D085458C8B0E604D9B3D46015C6876@sydmail1.au.bullant.ads>
Bill,

If you search the archives for this group, you will find a number of threads
discussing latency on the various Japanese networks.  

The figures of 150-200 ms I quoted yesterday were measured on the PDC
network in 2001 in response to a question I posted back then.  Since 2001
PDC bandwidth (iMode) has been upgraded from 9.6 kbps to 28.8 kbps.  I do
not know what this upgrade has done to the (rather good) PDC latency.

Bullant has a very efficient protocol called RAP.  The 9.6 kbps offered by
PDC is perfectly adequate for running very complicated MS Windows GUIs that
can be described in a couple of kb of data.  By way of comparison to our
Windows product, DoJa or MIDP simply does not have the screen real-estate or
complexity of GUI controls to cause a bandwidth issue unless the data stream
is laced with heavy image content.  Indeed our biggest issue for DoJa is
that HTTP header overhead that we cannot control.  As you say, once you have
a network, latency is really the problem for true thin-client applications.


The variance in the latency is the killer for any sort of real time
networked game engine such as the one you describe.  This is why Nokia has
gone for Bluetooth as the basis for real time multi-player games in the
nGage deck.  Because we cannot control latency we at Bullant focus on what
can be done today - move based multi-player games, IM, & business apps such
as PIM.  All of these services work well on today's networks in Japan and
elsewhere.

By the way, our experience of the Nextel iDen network was actually very good
even on an old i90c handset.  Nextel iDen handsets have reliable TCP in MIDP
1.0 as well as HTTP which is a real boon (no 300 byte useless HTTP header
overheads and long lived connections).  They also have the lightweight UI
components for a Canvas which far more useful than the MIDP Form elements to
us.

On a separate note to latency, an interesting observation from Wireless
Japan - and one backed up by recent discussions of the DoCoMo 505 handset
benchmarks - is that the handset really does matter when it comes to the
user experience.  We have tested on all of the FOMA handsets and all of the
505 handsets.  FOMA did not make an appreciable difference to application
performance for our thin client.  FOMA did make a big difference to the
phone bill for packet data charges.  The real difference was in the handset
itself.

Similarly, one J-Phone handset (alas I do not have the model detail as it
was a on loan from J-Phone) was a blazer and out performed everything else
on our stand including all of the other J-Phone handsets and everything from
DoCoMo.  

This observation would seem to be counter intuitive for a network based
thin-client framework.  Nevertheless, for our applications, it was certainly
true.

Chris


> 
> FYI:
> 
> The 'latencies' for some of the USA Java phones are as high as 6 to 8
> seconds.  Nextel has the best results, because of PTT (Push To Talk),
> but even that is 1 to 2 seconds.  I'm impressed that you see 1 second
> latencies in Japan ... gives me hope.
> 
> We're shipping a 3D multiplayer game latter this year (MIDP 1.0).  It
> was one of the most interesting design challenges I have ever faced.
> 
> To go to the next generation of multiplayer games ... we will have to
> move to a "thin client" model ... but we will also have to be very
> careful on packet loads.
> 
> Bill Volk
> Teknik.
Received on Thu Sep 25 03:52:19 2003