I think there several ways to look at this. The Palm VII works well for
quick access to more or less tailored content from a small handy low
maintenance device. It is good. Let's call it the Miata or the Z3 :-)
Lets call the Qualcomm pdQ a SUV. It's not so nimble, but it can transfer
lots of data. With it you can open a TCP connection just like Earl wants.
You get about 14kbps of through put and it will cost you less than $.50 to
transfer 50Kbytes of data and you can transfer that amount in about a
minute. I think one of the reasons for cost is lower is because the cost of
building out the infrastructure (billions of dollars) is already sunk and
paid for by the cellular voice networks (pdQ uses the same antennas/towers,
base stations, backhauls etc. as the voice infrastructure).
The downside is its larger size and the need to recharge the unit. That is,
a lot of the things Dave is talking about are right on in terms of the
design decisions made for the Palm VII.
On a pdQ what it takes to open a connection to the server is something like
this:
1) Bring up a data call -- This is usually a couple of seconds
2) PPP negotiation to authenticate and establish the IP address -- This
takes several round trips and depends on the PPP configuration of your
service provider (e.g., Sprint PCS vs AirTouch). This is typically 2 or 3
seconds
3) Do a DNS look up -- This is one UDP pack out and one packet back.
I've seen it take anywhere from 1 to 10 seconds
4) TCP connection establishment. I believe this is about 1.5 round trips
and I've seen it take from 1 to 5 seconds
So if you add up all the round trips you do get about 5 and it takes 6 to
20 seconds. If you've done steps 1and 2 (i.e., a data call is up) then it's
less than 3 round trips and very fast. In an informal test I find it's less
than 3 seconds to establish a TCP connection once the PPP session is up.
LL
At 11:23 AM 9/28/99 -0400, earl johnson wrote:
>(Sorry if this is a repeat I did not see it posted.)
>
>The issues you talk about battery, delay, ... are optimization issues.
>What I
>have is code that will run on any box with an internet connection
>(PalmIII, PalmV,
>Windows, UNIX, VMC, Mac, Windows CE, Tandy 1000SX, ....), but will not
>run on a
>PalmVII. Why don't I get an error when loading in the NetLibrary if it
>is not
>supported? If the web clipping architecure is using UDP could I use
>UDP? Are you saying that
>it is wrong or impossible to to TCP on PalmVII?
>
>Earl Johnson
>
>David Fedor wrote:
>
> > >I have a TCP/IP program that works on PalmIII and PalmV via their
>modems, but
> > >when I try it on the PalmVII wireless modem the socket will not
>connect.
> >
> > The wireless radio in a Palm VII can't be used as a generic tcp/ip
> > connection - there are severe battery life and latency concerns that
>make
> > it unreasonable to do so. And even if you had money and time to burn,
>the
> > infrastructure isn't set up that way.
> >
> > As an example: I believe I remember that making a socket connection
>over
> > tcp/ip requires 5 or 6 back-and-forth packets between the client and
> > server. Latency is high in wireless nets like the one that the Palm
>VII
> > device uses right now, and so just making a connection would take, oh,
>30
> > or 45 seconds? Bad user experience. And with that chatty protocol,
>the
> > users bill will be much higher too. The web clipping architecture
>does
> > lots of tricks (including using UDP instead of TCP/IP) to make it
>fast,
> > cheap, and power-conserving.
> >
> > You might want to do a bit more research into the tradeoffs and
>options
> > before just writing the code :-)
> >
> > FWIW, there are other radios which do function as more of a
>conventional
> > tcp/ip stack and connection. This just isn't the right tool for that
>job;
> > it is designed for something different.
> >
> > -David Fedor
> > Palm Developer Support
>
>
>
>
>
