4
：簡介
?
Dm
協議允許管理指令在節點上執行，跟
SyncML
同步協議和
SyncML
表示協議類似都采用的是包的形式。設備的一個節點表示為一組可配置參數，可以這個節點進行讀和設定參數的鍵、值操作，而終端的應用軟件另外一個節點可能是的正在可運行環境中（意思是不會影響到別的節點的功能），對這類型的節點操作可以對軟件的一部分功能進行下載、升級或者卸載
.
?
SyncML DM
這些指令代表這些操作，在
SymcML
表現協議和
SyncML
表現協議
DM
的用戶手冊中有描述。這些指令和消息的結構等同于
SyncML
數據同步協議，并且管理協議的
DTM
就是來源于
SyncML
數據同步協議的
DTD
?
5
：節點處理
?
每一個節點的路徑就是設備的唯一統一資源標識，這些標識必須遵循這樣一些指定的需求：
SyncML DM
樹和描述加以限制和指定
?
每一個節點都有一個可以決定什么樣的管理內容可以用來設置或者讀的類型，在節點上操作需要實現定義這個類型的值，當節點被讀的時候，這個類型的值將被返回。
舉例說明，有的節點只是一個簡單文本類型，需要設置，而有的節點是
WAP Provisioning document MIME
的復雜類型，甚至其他節點可能象
WAP
設置或者軟件安裝這樣更復雜的值
?
SyncML DM
協議的指令的
target
和
souce
由
目標和來源
元素分別指定
target
是接納著，
source
是來源，這些過程出現的異常都會在管理命令需求中的異常中會被提及
?
?
6
：包中的多消息
?
6
．
1
描述
? DM
管理協議中中提供用多個
MESSAGE
來傳輸一個包的功能，當一個包非常大的時候，分成多個
MESSAGE
進行傳輸是非常有必要的，這樣的局限是可能由傳輸協議或者終端的功能限制決定，（分成多個
MESSAGE
就可以解決這個問題）。
?
? DM
管理協議中，包作為一個邏輯組的作用是非常有限的，大部分的限制在
MESSAGE
上，而不是在
PACKAGE
上，舉例：一個
COMMAND
必須完全適從一個
MESSAGE
。
?
?
為了避免大量客戶端而有限的資源，服務器等待從客戶端的包的
command
返回一個狀態，
如果上一個
COMMAND
沒有返回一個狀態服務器不允許發送一個新的
COMMAND
，換句話來說，大部分
server
發送到客戶端的
COMMAND
都會收到
CMMAND
（
package
）的返回信息，除非
SERVER
發送一個大的對象或者請求更多的
MESSAGE
（用
1222 ALERT
）
一個
PACKAGE
包含大對象數據將會被分成很多
MESSAGE
傳輸，在第七部分會詳細描述
?
說明
server
在處于一下一種包的邊界的狀態的時候：
?
?
?1
：
server
有一個完全大的包，在這種狀況下，
server
等待從
client
的
COMMAND
返回狀態，由于狀態和結果非常大（如
GET COMMAND
的結果），
client
將發送多個
MESSAGE
回
server
，然后結束他的回應
?
?2
：
server
從
client
接受到一個完整的包，
server
將會發送一個新的
COMMAND
給
client
?
?3
：
server
發送了包中的一個或多個指令，但是沒有發送包中的最后一個指令的時候，只有當
package
中的最后一個指令被發送出去的時候，這次狀態才被認為是有效的
?
?
由于
SyncML
的傳輸形式是
request/response???
的形式，無論是客戶端還是服務器端在傳輸消息的時候都不應該包含一個開始命令或者一個結束的標志，以便保證
response/request
循環進行下去（言外之意就是有個這個標志就是開始和結束的時候）
.
?
舉例：當
server
在
STATE1,
他可能收到客戶端的很多
MESSAGE,
這些
MESSAGE
包含了
status
和
result
。
Server
會對任何一個
message
回應，除了對
NEW COMMAND
進行回應外。
Server
對發送的回應在
SyncHdr
中包含了一個
1222 ALERT
，
client
也指定了，（表示沒有結束還有消息）。
STAUTS
必須對
ALERT
的回應進行發送而不是對
RESULT
的回應進行發送
?
?
ALERT1222
可以被
ALERT 1223
替換，因為服務器可以主動結束一個過程
?
下圖展示了多個
message
被發送
6
．
2
需求
?
?
如果
SyncML package
分成多個
MESSAGE
被傳送，最后一個
MESSAGE
必須包含一個
FINAL
的標志，其他么
message
一定不能包含
final
標志。
Final element
由
server
發送而不是由
client
發送，最終停止本次的
PACKAGE
操作。
?? Server
在每個
MESSAGE
必須發送
FINAL message
，不過在發送大的對象的時候或者發送
NEXT MESSAGE
的相應的時候不會發送
7
：大對象的處理
?
? SyncML dm
協議中，大對象不能完全在一個
Message
中傳輸，根據
SyncML data
同步協議指定的大對象處理方案可以分成多個
Message
。規則如下：
?
第一個限制就是支持大對象處理的終端必須顯示的之處
DevDetail/LrgObj
的標識為
true
第二個限制是在
server
和
client
傳輸的
MaxObjSize
有多大，在
SyncML data
同步協議中
MaxObjSize
會在
Meta information
中指定。
DM
協議中被發送著接受的最大對象的大小（
MaxObjSize
）包含在
syncHdr
中（
message
的
META INFO
）
,syncHdr
中指定的
MaxObjSize
，發送者發送的單個對象都不能超過這個大小，如果
MaxObjSize
沒有被發送，接收者可以自由發送任何大小的
message
給
server
。
?
需要指出的是：
MaxObjSize
會影響整個
DM session
，如果在隨后的
message
中沒有對這個值進行重新設置。新的
MaxObjSize
在后來的
message
指定一個可能的原因是
client
的
free memory
大小的依賴，（有東西創建在
MEMORY
的時候或者刪除的時候
FREE MOMORY
會發生變化）。
第三個限制：在上一個單元結束前終端會檢測新的對象（
messge
），終端會回復一個
1225
的
alert
?
?
?
?
?
?
?
posted on 2006-05-23 13:58
小小程序程序員混口飯吃 閱讀(2052)
評論(6) 編輯 收藏 所屬分類:
讀書 、
java