Real problem with these mobile networks (GSM/GPRS/CDMA/WCDMA-3G-UTMS) is NOT bandwith.
The problem is latency. I have seen that in GPRS network roundtrip times are more that 1 (one) second. So mobile networks are not ideal for realtime-online-multiplayer-games.
TCP/IP protocol also works pretty bandly in this high-ping environment with standard parameters. TCP/IP is made for quite low-ping networks where you roundtrip-times are more like 0.01 seconds than 1+ seconds. Mobile (or any telephone) networks are not really done for handling (big) packet-switched data, but for circuit switched audio.
So operators and manufacturers talking (bul*-s****ing) about "massive bandwidth", which is actually quite unusable because of this latency problem.
Symbian OS (EPOC32) is quite nice some ways: works, spends only little memory.
But currently we have some minor( or major) problems with it.
* It's difficult to program and the whole programming ideology
is rather different than any other platform I know.
(it's WHOLE C++ (not C), no static variables, those L-ending functions with setjmp-style error handling something...).
All this is a major block for programmers. Every programmer, that
I know, who have studied Symbian environment say that it's quite awful
to make code and takes a quite long time to study it.
* Almost all tools are just for M$-@#%-windows (like for Nokia's Platform-60,
which is used in Nokia 7650). To use Nokia's tools you NEED M$ Visual Studio.
(whole thing eats maybe half Gbyte of your hard drive).
There is an effort to make important tools (compiler, linker) to run
in Linux too.
Maybe Symbian nice, but it's still rather hostile to (non-M$) programmers.
A = market category
1 = basic (not much used lately)
2 = old "classic" phones (2110) (not used much since)
3 = young people phones
(for people that are not in serious work)
Look plastic, feel plastic.
You can change cover/ringtones/logos/screensavers.
4 = not used (in Asia 4 is like 13 in west;
you have to think also asian markets)
5 = mostly little bit special stuff
(5210=outdoor,5510=music-player)
6 = classic (matter a fact phones) for
people that use phones in work
(not outdoors). For men.
7 = special/extraordinary stuff (7110,7210)
Usually not so cheap stuff.
8 = Design mobiles (8110(=banana),8810(zippo),8850,...)
Ladies/small stuff (8210,8310,...)
9 = Communicators (9000,9210...)
B = generation/version (inside category)
(6110,6210,6310 (no 6410), 6510,6610...)
OR subcategory
8[23]XX = small/ladies stuff
88XX=design stuff.
C = network system
1 = GSM (first it was GSM900 now also 1800)
2 = AMPS (usa - old analog system)
3 = GSM (was just GSM1800 [6130])
4 = -
5 = GSM900+1800 (sometimes +1900)
now usually triple-band + something special
6 = D-AMPS/TDMA (usa+americas)
7 = CDMA1900/CDMA2000?
8 = CDMA1900 (usa)
9 = GSM1900 (usa)
One thing that makes apache process/thread model problematic is HTTP Keep-Alive support (HTTP/1.1).
Your keep-alive connection eats whole thread/process it's lifetime. So, if you accept keep-alive (for long time) you can have hundreds of idle-processes/thread waiting next request to come from idle connection. To make things even worse most browsers open multiple current connections to same server to fetch all those numerous pictures (in typical html-page).
To compensate this you must configure you apache instance for very many child-processes (MaxClients). Then HARD_SERVER_LIMIT (in unix 256) limits you (you must edit/compile server to get it bigger).
Usually all this means that you cannot use Keep-Alive in busy site with apache.
Accelerated apache project (http://aap.sourceforge.net/) could help here using sofware threads), but state-threads-library's non-bsd/apache compatible license have made it impossible to make these patches offical (have I understand it right?). In aap http-connection doesn't own whole process but just software thread.
In my opinion. There should be way to make MPM (processing model) that would reserve process/thread just for every http-request and not for whole http-connection. Currently it's difficult (or impossible ?) to that kind of MPM in apache-2.0.
Slashdot Mirror
If you going to play Quake then...
Real problem with these mobile networks (GSM/GPRS/CDMA/WCDMA-3G-UTMS) is NOT bandwith.
The problem is latency. I have seen that in GPRS network roundtrip times are more that 1 (one) second. So mobile networks are not ideal for realtime-online-multiplayer-games.
TCP/IP protocol also works pretty bandly in this high-ping environment with standard parameters. TCP/IP is made for quite low-ping networks where you roundtrip-times are more like 0.01 seconds than 1+ seconds. Mobile (or any telephone) networks are not really done for handling (big) packet-switched data, but for circuit switched audio.
So operators and manufacturers talking (bul*-s****ing) about "massive bandwidth", which
is actually quite unusable because of this latency problem.
-pihl
Web advertising revenues are falling (no more hype).
You need more visibility.
You need BIGGER ads!
At first it was enough for any calculation machine (=computer) just to be Turing-Complete.
But after Doom every self-respected Computer-arch/OS must be Doom-Complete (Doom runs in it).
What next?... NP-Complete?
Symbian OS (EPOC32) is quite nice some ways:
works, spends only little memory.
But currently we have some minor( or major) problems with it.
* It's difficult to program and the whole programming ideology
is rather different than any other platform I know.
(it's WHOLE C++ (not C), no static variables, those L-ending functions with setjmp-style error handling something...).
All this is a major block for programmers. Every programmer, that
I know, who have studied Symbian environment say that it's quite awful
to make code and takes a quite long time to study it.
* Almost all tools are just for M$-@#%-windows (like for Nokia's Platform-60,
which is used in Nokia 7650). To use Nokia's tools you NEED M$ Visual Studio.
(whole thing eats maybe half Gbyte of your hard drive).
There is an effort to make important tools (compiler, linker) to run
in Linux too.
Maybe Symbian nice, but it's still rather hostile to (non-M$) programmers.
pihl
Nokia seems to have numbering system like this:
ABCD{i} where:
A = market category
1 = basic (not much used lately)
2 = old "classic" phones (2110) (not used much since)
3 = young people phones
(for people that are not in serious work)
Look plastic, feel plastic.
You can change cover/ringtones/logos/screensavers.
4 = not used (in Asia 4 is like 13 in west;
you have to think also asian markets)
5 = mostly little bit special stuff
(5210=outdoor,5510=music-player)
6 = classic (matter a fact phones) for
people that use phones in work
(not outdoors). For men.
7 = special/extraordinary stuff (7110,7210)
Usually not so cheap stuff.
8 = Design mobiles (8110(=banana),8810(zippo),8850,...)
Ladies/small stuff (8210,8310,...)
9 = Communicators (9000,9210...)
B = generation/version (inside category)
(6110,6210,6310 (no 6410), 6510,6610...)
OR subcategory
8[23]XX = small/ladies stuff
88XX=design stuff.
C = network system
1 = GSM (first it was GSM900 now also 1800)
2 = AMPS (usa - old analog system)
3 = GSM (was just GSM1800 [6130])
4 = -
5 = GSM900+1800 (sometimes +1900)
now usually triple-band + something special
6 = D-AMPS/TDMA (usa+americas)
7 = CDMA1900/CDMA2000?
8 = CDMA1900 (usa)
9 = GSM1900 (usa)
summary: 1-5= GSM:euro/asia stuff 6-9=usa/americas
D = subversion (not much used in europe)
i = extended model (like 6310i)
One thing that makes apache process/thread model problematic is HTTP Keep-Alive support (HTTP/1.1).
Your keep-alive connection eats whole thread/process it's lifetime. So, if you accept keep-alive (for long time) you can have hundreds of idle-processes/thread waiting next request to come from idle connection. To make things even worse most browsers open multiple current connections to same server to fetch all those numerous pictures (in typical html-page).
To compensate this you must configure you apache instance for very many child-processes (MaxClients). Then HARD_SERVER_LIMIT (in unix 256) limits you (you must edit/compile server to get it bigger).
Usually all this means that you cannot use Keep-Alive in busy site with apache.
Accelerated apache project (http://aap.sourceforge.net/) could help here using sofware threads), but state-threads-library's non-bsd/apache compatible license have made it impossible to make these patches offical (have I understand it right?).
In aap http-connection doesn't own whole process but just software thread.
In my opinion. There should be way to make MPM (processing model) that would reserve process/thread just for every http-request and not for whole http-connection. Currently it's difficult (or impossible ?) to that kind of MPM in apache-2.0.
pihl