一 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)
高分表
玩家之間交談
顯示延時 ...
