笔记
一 MIDP通讯技术
1. HTTP：
当网络中的真实电话配置HTTP流MIDlet的时候，不要尝试一次只发送一小段数据：在发完全部数据之前，不会收到什么东西。
当从服务器发送HTTP响应要被延迟到某个事件发生，移动网络中开发连接可能很昂贵，通常会因超时而被中端，这一情况比在互联网上更容易发生。
移动电话通常没有资源去支持多重开放的HTTP连接。在数据结构和数据缓存方面的开销非常大。
HTTP 方法
GET：用于向服务器请求一个静态资源，重复一个GET请求将得到相同的资源响应。GET请求仅提供资源的URL，不包括任何消息体。
POST：用于向服务器请求一个动态资源(如游戏中的一个回合)，重复一个POST请求将得到不同的资源响应。POST响应也包括一个带服务响应数据的消息体，是MIDlet的常用方法。
来自某个服务器的HTTP响应可能包含成功(2xx)、重定向(3xx)或错误(4xx, 5xx)之类的状态码。这些代码需要由HTTP客户端处理。
HTTP消息体
发送的信息只是一串字节流，可以对这些字节信息进行编码，包括：
文本；图像文件(至少支持对PNG解码)；XML；其它用户定制数据结构。
HTTP会话
服务器把MIDlet发起的一系列连续请求作为一个HTTP会话来跟踪，由于HTTP本身是无状态的，所以必须在HTTP协议层之上实施会话管理。
方法一：各种会话cookie。
方法二：URL重写。
由于cookie还有其它用途，所以处理会话cookie的完整MIDlet实现起来比较复杂，重新URL则简单许多。
HTTP服务器
有包括java servlet, jsp, asp, asp.net, cgi script在内的多种选择。
2. TCP:
互联网上的http通常以TCP实现，TCP连接的端点是一个套接字socket。MIDP 1.0 不包括对TCP的支持，MIDP 2.0 规定了对TCP的支持，制造商可以自己选择是否包含这种支持。
3. UDP:
使用UDP时，两台正在通讯的设备间所发送的数据报(datagram)往往也被称为数据包(data packet), MIDP 1.0 不包括对UDP的支持，MIDP 2.0 规定了对UDP的支持，制造商可以自己选择是否包含这种支持。在诸如GPRS这样的分组交换协议上实现时，考虑到移动网络的响应时间，包的发送量一般并不需要超过每秒一个，并注意包的大小。
4. 串行电缆
MIDP 2.0中通过接口SerialPortConnection实现支持。
5. 红外
MIDP 2.0中通过接口SerialPortConnection实现支持。
6. 蓝牙(MIDP可选包通讯技术)
一种短程无线技术，支持约10米范围最多8台设备一起通讯，响应时间短，非常适合于多人游戏(由于蓝牙超各个方向传输，彼此之间不必正对)。
7. SMS短消息服务
SMS(Short Message Service)可以发送文本消息或者是二进制数据，是一种“存储转发”技术。通过一台短消息服务中心(SMSC)保存消息在队列中，并稍后转发。
8. MMS多媒体消息服务
是SMS的一种升级版本，允许把一段消息分成几部分，包括文本，图片，声音以及视频，也是一种“存储转发”技术。MMS实现综合使用了SMS和HTTP。
二游戏服务器技术
HTTP和HTTPS
在服务器端，你可以使用任何一种通常用于HTTP服务器的技术，如：静态网页、CGI、ASP、Java servlet，以及JavaServer Page（JSP）。Java程序员通常的选择是Java servlet。
三游戏类型及相关注意事项
多玩家单人游戏 & 回合制游戏：
这种游戏的特点是玩家轮流上阵，没有用到网络，也不会受网络延世的限制。
循环赛游戏 & 同时行动游戏：
当使用MIDP 1.0，可以选择HTTP，但HTTP有一个重大缺点，游戏服务器无法告知MIDP客户端：现在轮到你了，所以客户端必须测试，定时询问游戏服务器：轮到我了么，所以应该考虑提供一种能中断等待并立即开始下一次查询的方案。
MIDP 2.0，TCP可能是最佳选择，轮到一个玩家时，服务器会立即通知他，这很重要，因此UDP就可能不太适合。另外，在循环赛中，TCP可能导致的额外延时并不成为问题。
“随时玩”类型游戏：
如果游戏中涉及实时动作，HTTP的延时就会显得过于严重。用MIDP 2.0时应该考虑UDP， TCP，或两者结合。移动网络的延时对快速的，实时的多人交互游戏来说影响太大了。
四多人游戏共通特性
永久性用户帐户
游戏大厅(Lobby)
高分表
玩家之间交谈
显示延时 ...