What is an Interface

What is an iterface?(什麼是介面)?
在英文裡面,一個介面(Interface)是一組用來與不相干實體互動的設備或系統.根據這個定義,一個遙控器是一組介於你和電視的介面,英文是一組介於兩個人之間的介面,在軍隊中的行為協定是一組在不同階級的人之間的介面.在Java語言中,一組介面是一個與不相干物件互動的設備.一組介面大致可以比擬為一個協定(在行為上的允許).實際上,其他物件導向語言也有介面的功能,但他們稱他們的介面為協定.
腳踏車類別和他的後繼類別定義了一部腳踏車在騎的時候可以做什麼和不可以做什麼,但不包括腳踏車在其他期間與世界的互動.舉例來說,在店裡的一部腳踏車可以被一個庫存程式來管理.一個庫存程式不管物品是什麼類別的,他只要每個物品提供確切的資訊,像是價錢和追蹤號碼,就能管理.取代在其他不相關聯的物品上作強制類別關聯的做法是,庫存程式初始化了一個通訊的協定.這個協定引入常數和函式的集合,包含在一個介面之中.庫存介面將會被定義,但不是實作,裡面的方法將會被用來設定和取得零售價錢,給予一個追蹤號碼等等.
在庫存程式裡作業時,腳踏車類別必須藉著實作這個介面以同意這個協定.當一個類別實作一個介面,這個類別就需要實作在介面中定義的所有方法.例如,腳踏車類別將提供設定和取得零售價格,給予一個追蹤號碼等方法的實作.
使用一個介面去定義一個行為的協定,以用來被任何類別來實作.介面在以下情況是非常有用的:
.在沒有關聯的類別中找到相似點,而不需要強制給予類別的關係.
.定義一個或多個類別預計要實作的方法.
.不需要顯露出物件的類別,就能顯露他的程式化介面.

Windows Script Component 與 NT/2000 的安全

摘要:說明 Windows Script Component 與 NT/2000 檔案安全的關係

內容:

說明
參考

下載本文章的範例程式(下載後以滑鼠右鍵點選,然後選擇註冊即可)

說明

前二日,我在使用WSC(Windows Script Component)的時候,發現了很詭異的事情.

這個元件不管是利用VB或是利用Windows Script Host呼叫,都是正常而且可以運作的.

但是在 ASP 中,卻始終無法使用, 我為了這個問題,搞了兩個多小時,才終於搞懂,這個檔案的安全權限必須要加入IUSR_XXXX(IIS訪客)這個使用者才行!

唉唉唉~~

真是難搞的要命,如果各位有遇到難解的問題,不妨檢查一下資料夾以及檔案的安全權限,也許就能迎刃而解了.

呼~~

上面有提到 WSC, 我在這裡也順便說明一下, WSC 是 Microsoft 提出的一個與 Script 相關的技術,它讓我們可以利用 Script
來撰寫COM的元件,你可以參考http://www.microsoft.com/taiwan/products/develop/scripting/,這裡有許多與
Script 相關的技術文件.

本篇文章所附的範例則是來自 Active Server Pages 3.0 深度探索一書中的範例,主要的用處是結合Recordset來產生一個表格,使用方法很簡單:

dim objtbl
set objtbl = server.createobject("asptable.wsc")
objtbl.addcolumn "員工編號","emp_no",""
objtbl.addcolumn "員工姓名","emp_name", ""
obj.gettext()

不過我改寫過了,增加了兩個方法,一個方法是getpagetext(pageno),可以得到第幾頁的Table;另一個則是obj.getstrtext(),取得整個table的html字串.

當然這裡寫的還不是清楚,以後再來補吧 ^_^

參考

Active Server Pages 3.0 深度探索(國外出版社Wrox,國內則是由碁峰翻譯後發行)

2001/8/30與saint閒聊

Saint said:
Dear, What’s your best program framework ?
—-
Ellery said:
I have no framework in VFP~
大多只是一些小技巧以及函數罷了
你這樣問,有點不知道該怎麼回答你
你想要知道什麼呢??
—-
Saint said:
不一定是VFP
我是說,你沒有想過,有關於framework這樣的事嗎?
從我把資料給物件化時,我就很想要做一個可以自動產生程式的一個framework
到了這裏,又做了menu object 之 後,這一個想法,一直在心中盤算!
所以我想要做一個是my style object framework ,You know ?
可是當我要去做時,發現並不簡單!所以想要聽聽看你的看法!
—-
Ellery said:
有想過~
但真的不簡單
1.需要對該語言的特性作深入的了解
2.需要對物件導向的各種 pattern 有相當的認識,才能作出簡潔而又漂亮的設計
其實也不一定要有相當的認識,但也要有看過大量的Framework
另外,人都會有野心,會想要弄出跨平台,甚至跨語言的一個東西
這樣子的領域就又更龐大了
當我越想越多的時候,就越覺得龐大,越覺得不能馬上動手
所以一直沒有作
跨平台的東西, Borland Kylix and Delphi,Qt 和 Java 是著名的代表
Borland 的產品 CLX
Qt 是 linux 上著名的桌面管理 KDE 的底層,以C++撰寫,但寫出的東西,一樣能在Windows上compile
Java 則更誇張,compile 一次之後, run everywhere,只要檔案複製過去,然後執行環境的Java Virutal Machine有支援,就一切ok
跨語言的東西,COM, CORBA, 以及 beta版的 .Net 應該算是代表
COM, 衍生出 DCOM, COM+
CORBA, 則是 Unix 以及 Unix like 環境下,類似COM的東西,但其實CORBA出來的較早
這個標準實作的比較漂亮且完整,只是支援的語言不多,目前我知道的只有 Java, C++, Object Pascal 而已, Windows 平台上較不常見
.Net 是微軟的一個弘願,Linux上也有了相關的計劃,將來是可以期望的一個東西
說了那麼多,我的最後結論其實是
Framework仍然要作,但是不要像我一樣考慮那麼多,考慮的太多,反而讓自己無法前進
應該依照目前想實作的狀況,一族一族的去實作出來
比如說,現在要作 menu, 就先把 menu 類別及其衍伸類別實作出來
要作檔案,就把檔案類別及其衍生類別實作出來
一個一個去實作
將來如果需要合作的時候,再去參考 Design Pattern 中與合作相關的Pattern去實作
不行,再重寫
但是什麼都要自己寫嗎??
不, 如果現成語言裡已經提供了現成的一個類別, 那麼就直接使用
有跨平台或跨語言的需要,就寫一個wrapper類別把他包起來,將來若跨平台或語言的時候,只要重新實作這個wrapper就可以了
喔~~
回頭看了一下,我居然打了這麼多字
謝謝你的收看
^_^
—-
Saint said:
我倒是沒有想到過說要跨平台這一個問題!
不過我的想法,也倒如你所說的一樣!想的越多,我越難下手去做,
不是沒有想過說,先做一個起來,以後再用合併的方式來做
可是是否會有一個問題,就是所以的物件的起源,我是說如果這樣做的話
我會有一個base object 那有可能我所有的物件都會去參考這一個當做base
想著想著,有時想到如果程式要做,如果只是自己才看的懂那又矢去了意義!
想的越多越難做!
—-
Ellery said:
單一繼承的關係比較簡單,而且效率會較好
八月的時候,我看了侯捷翻譯的”深度探索C++物件模型”
雖然只看到第五章,就因為借書期限到的關係,只好還書
不過有作筆記(這是我第一次看書作筆記!)
對於物件導向實際上的運作了解很多
所以,我想還是建立一個 Base Object
但盡量只賦予必要的特性就可以了
也就是雖然此族的衍生類別都從一個父類別開始繼承,但此父類別必定繼承 Base Object
若真需要增加屬性或方法,只更動此父類別就可以,而不更動父類別
其實對於VFP來說,此動作並不是必要
因為VFP並不是強型別的語言也沒有支援虛擬
所以就不能這樣寫(以下是C++語法)
BaseObject *obj; //宣告成指標
Menu mymenu; //產生一個 mymenu物件,假設 menu繼承 BaseObject
Form myform; //產生一個 myform 物件, 假設 form 繼承 BaseObject
obj=&mymenu; //取得mymenu的位址,指定給obj
obj->activate(); //就可以直接呼叫 menu 的方法
obj=&myform; //取得myform的位址,指定給obj
obj->show(); //就可以直接呼叫 form 的方法
很神奇不是嗎?? 如果你用過強型別的語言
對這種神奇的感覺會很強烈
因為類別不同是不可以隨便指定的!換言之也不能隨意呼叫其他類別的方法
Java, Object Pascal 也都有類似的用法
VFP和VB 所有的變數都是 Variant, 這樣的感覺就不是很強烈
反正怎麼寫怎麼適用
local obj
obj=createobject(“menu”)
obj.activate()
obj=createobject(“form”)
obj.show()
但我就不清楚VFP內部是怎麼去實作的
說到程式看不看的懂
又牽扯到寫作風格的問題
我以前很痛恨這種寫作風格的問題
尤其是學校導師(後來老師因為肝的問題,英年早逝了,很遺憾沒去醫院看他最後一面)教我們COBOL的時候, 他一直不厭其煩的要求我們要這樣子去寫 COBOL 程式
那時候覺得如果強制要求寫作的風格,會很麻煩,而且排版的很累,寫出來的程式碼也會不簡潔,不漂亮
但是後來看過”撰寫0錯誤程式”這本書以及經過歷練之後就不會這樣想了
現在會盡量要求自己留下註解, 使用較清楚的方法去寫程式
假設前兩天寫出這樣的程式
if getanswer()
*do something
else
*do something
end if
隔兩天,我一定忘記我在寫什麼,於是又要去看 getanswer() 在寫什麼,浪費了許多時間
我會盡量這樣寫
*利用 getanswer() 函數詢問使用者的答案, true 表示使用者回答 yes
if getanswer()==true
*do something
else
*do something
end if
這樣至少我自己看程式會知道我之前要幹麼
哇~又打了這麼多
8-p

scriptlet的問題

我解決了這個怪問題~~
由於scriplet元件是由 scrobj.dll 去負責解譯
因此我把我這台電腦(ie5.5)的 scrobj.dll 複製到對方的電腦(ie5.0)中
於是就不會發生此問題了~~
參考http://support.microsoft.com/support/kb/articles/Q247/7/84.ASP
的時候就有想到可能是版本的原因
更新到 ie 5.5 後應該可以解決
但是對方的電腦由於 Ultimus Flow 系統的原因,所以無法更新到 5.5
於是只好嘗試更新單獨的 dll, 一舉成功!!
哈哈哈哈

搜尋CORBA products

除了 inprise 的 visibroker 之外
有許多的corba 產品
http://www.omg.org/technology/corba/corbadownloads.htm
之中,有介紹許多.
以下是我覺得不錯的
http://www.ooc.com 提供免費的corba及其相關產品可供download,適用於各種平台,主要開發語言是 C++ and Java, 產品都實作了omg的標準; 另外也有提供嵌入式系統用的corba
下載網頁; 還有就是須要配合特別的JThreads/C++,是一個轉換C++與Java的東西!!
http://www.ooc.com/ob/download4.html
http://www.ooc.com/obe/download.html
OmniORB 也是一個不措的
omniORB is a robust, high performance CORBA 2.3 compliant ORB with C++ and Python bindings. Features include:
openorb 則是一個 open source 的網站,只是目前還沒有一個標準的package出現
另外還有,暫時先逛到這裡

bluetooth筆記

===== 介紹 =====
Function
L2CAP 允許較高層級的協定以及應用程式傳送和接收L2CAP資料封包,最大可到64Kㄛ
僅支援非同步連結
AUX1 packet是被禁止的,因為不支援資料一致性(no CRC).
L2CAP 的 packet 有兩種格式,一種是 single-slot, 一種是 multi-slot,主要差別是
packet 欄位的長度. 欄位內容及說明可參考 page 250
必須要可以
1.協定多路傳輸,因為 Baseband Protocol(以下簡稱BP) 不支援任何可被辨識型態的欄位,這樣在之上的協定才能多路傳輸.
需要上層的協定像SDP,RFCOMM,TC可以辨識.
2.可被切割和重組
3.服務的品質(QoS)
4.群組
assumption 設想
這個協定建立在三個設想上
1.兩個單位之間的非同步連結預設適用 Link Manager 協定(page185)
baseband 順序提供封包傳送,即使可能有壞的封包或重複的
設備之間只有一個非同步連結
2.baseband提供全雙工的通訊頻道
但這不意味所有的L2CAP通訊都具備雙向的特性
廣播或者不具方向性的交通(如video)就不需要雙工的頻道
3.在baseband之上提供一個可靠的頻道
當要求或重送資料時,baseband會提供資料一致性的檢查直到成功或者逾時為止
因為回音有可能遺失,逾時就可能發生
baseband使用一個 1-bit 的循序號碼來移除重複的情形
baseband broadcast packet是被禁止的,會影響可靠度
Scope
說明一些主要的限制與範圍
===== 一般性運作 =====
建立在channel之上,每個頻道都有一個 頻道識別 來參考
2.1 Channel identifiers (CIDS) 頻道識別
0x0001~0x003F是被保留給特定的L2CAP功能的
0x0000則是被定義為一個不正常的識別
然後可以參考page 253的表格
主要就是說明識別對每個設備而言只能唯一,不會重複
比如 A 連到 B 也連到 C
A 給 B 的號碼是 0x0070
給 C 的號碼是 0x0071
而 B 連到 C 也連到 A
B 給 C 的號碼也是 0x0070
B 給 A 的號碼也是 0x0071
這樣子其實是沒有重複的
2.2 設備間的運作
page 254 的圖說明了如何運作
另外也有一張表提供CID的一些預設值
2.3 Layer間的運作
2.4 分割與組合
分割與重新組合主要是用來增進傳輸的效率
所有的L2CAP packet 可以被分割來在baseband packets之上傳輸
並不執行任何分割和重組的動作,但是packet的格式支援適應去變為更小的實體框架.
一個L2CAP的實作揭露了外出的MTU和分割為較高層次的packets到較大的單位,以便可以經由HCI被傳遞到 link manager
在接受端,L2CAP的實作從HCI接收較大的片,並使用HCI和packet表頭的資訊重組這些較大的片成為L2CAP packets
可以參考page 255的圖,會比較容易瞭解
baseband packet的表頭,前兩個bit,如果是’10’,表示是在L2CAP packet裡的第一個分割.
’01’則是一個順序的分割.(參考page 256的圖)
2.4.1
L2CAP MTU會使用一個特定服務介面的實作來把他批露出來
這是較高層級協定的任務,要限制送給L2CAP層級packet的大小要小於MTU的限制.
如果要送到baseband,就需要轉為 baseband packet
所有與L2CAP packet相關的L2CAP 分割必須在任何其他L2CAP packet到達相同單位之前被送到baseband
2.4.2
baseband協定順序傳送acl packet並且用 16bit的 CRC來保護資料的一致性
同時也使用一個自動重複要求的機械動作來支援可被信賴的連結.
如同baseband控制器接收acl packets, 他同時也在每個baseband packet到達的同時,通知L2CAP 層級.
或者在(buffer滿or逾時發生)的時候累積一定數量的packet
L2CAP時坐必須使用L2CAP packet的”長度”欄位. (refer to page 272)
不符合長度的packet會被靜靜的放棄掉.
為了可被信賴的channels, L2CAP 實作必須告訴上層, channel已經被成不可被信賴的.
藉著擁有一個無限flush的實限數值,我們可以定義可被信賴的channels.(refer to page 290)
page 257有一張解說的蠻詳盡的圖表
3.狀態機器??
定義狀態, 狀態轉移所發生的事件, 和事件回應時被執行的動作.
page 258的圖可以幫助你了解整件事情的始末,下面的文字則是對圖的描述
page 259則是更明確指出上一張圖裡面所謂回應與確認(L2CA_Request, L2CA_Confirm, L2CA_Response, L2CA_Indication)的動作,
並且加上了時序的觀念
當L2CA_Request進來,被接受後,變成L2CA_Indication
於是回應(L2CA_Response),出去成為一個確認(L2CA_Confirm)
3.1 事件
簡單的來說事件區分為: 1.從底層來的Indication 和 Confirms, 2.從高層來的 Request 和 Responses, 3.從同層來的資料, 4.同層來的要求與回應, 5.逾時所觸發的事件
3.1.1 由底層到L2CAP的事件
Lp_ConnectCfm 確認建立lower layer連結的要求.如果認證被需要用來建立實體連結的話,就包括傳遞認證挑戰的工作.
LP_ConnectCfmNeg 建立lower layer連結失敗的時候,可以用來確認失敗的事件,包括裝置沒接觸到,拒絕要求,或者是認證失敗
LP_ConnectInd 指出已經跟lower protocol建立連結了.在baseband的狀況下,這將會是一個ACL Link.一個L2CAP實體會用來追蹤實體連接是否存在
LP_DisconnectInd 指出 lower protocol 已經被 LMP commands 或者是逾時事件所關閉
LP_QoSCfmNeg 因為QoS所造成的要求失敗.
LP_QoSViolationInd 指出 lower protocol 已經偵測到違反QoS規定. 跟上面那個有關喔
3.1.2 L2CAP to L2CAP 警示事件
每個L2CAP實體跟L2CAP警示 PDUs交換時所發生的事件.可參考Section 5
經由lower protocol從lower layer收到事件.此部份也可以參考page 258 的圖
L2CAP_ConnectReq 一個連結要求packet被收到
L2CAP_ConnectRsp 當一個明確指出連結已建立的連結回應packet已經收到
L2CAP_ConnectRspPnd 一個連結回應packet被收到, 並指出遠端端點已經收到 request 並正在執行.
L2CAP_ConnectRspNeg 一個連結回應packet已經被收到,指出連結未被建立.
L2CAP_ConfigReq 一個配置回應packet已經收到並指出遠端端點同意所有洽談過的參數
L2CAP_ConfigRspNeg 類似上一個,不過這個是不同意
L2CAP_DisconnectReq 收到這個, channel必須初始化disconnection的process: L2CAP實體應該傳回對應的CID
L2CAP_DisconnectRsp 一個中斷連結的回應封包被收到. 然後會把相符的CID資料釋放,丟回pool裡面去. 中斷的要求一定會成功.
3.1.3 L2CAP 對 L2CAP 資料事件
L2CAP_Data 一個資料封包已經被收到
3.1.4 上層對L2CAP的 事件
L2CA_ConnectReq 上層來的要求說要對遠端設備Channel的建立
L2CA_ConnectRsp 從上層來的回應說從遠端設備的連接要求表示(可以參考 3.2.4 L2CA_Connectind )
L2CA_ConnectRspNeg 從上層來的回應說連接被遠端設備拒絕的時候(可以參考 3.2.4 )
L2CA_ConfigReq 從上層來的要求說要重新設置channel
L2CA_ConfigRsp 從上層來的回硬說重新設置要求的indication (突然發現indication很難翻)
L2CA_ConfigRspNeg 重新設置要求的indication,從上層來的失敗回應
L2CA_DisconnectReq 為了channel立即中斷連接而從上層來的要求.
L2CA_DisconnectRsp 從上層給中斷連接要求的indication來的回應.中斷指示必須總是被接受!
L2CAP_DataRead 為了從L2CAP實體到上層的接收資料的傳輸而從上層來的回應.
L2CAP_DataWrite 為了從上層到L2CAP實體的資料傳輸而從上層來的要求.
11/20~11/25
3.1.5 Timer events
當一個信號用的要求被送出去的時候,這個timer就開始了.一直到遠端有了回應之後,這個timer才結束.
如果這個timer超過了一定的時間,一個副本的要求訊息會被送出或者CID在這個要求就會被結束掉.
當一個副本訊息被送出,RTX 的timeout數值必須重新設置一個新的數值,至少要是原來數值的兩倍.
實作時必須要去決定在中斷channel之前重新傳播要求的次數.
3.2 Actions
被分成五個主要的部分:向高層級確認與通知, 向低層級要取與回應,同層級間的要取與回應,同層級間的資料傳輸,設定timer.
3.2.1 L2CAP對低層的的動作
LP_ConnectReq L2CAP 要求低層的協定去建立連結,如果與遠端裝置的實體連結不存在,這個訊息必定會被送往低層協定已完成實體連接.
在兩個設備之間,不會超過一個ACL連結, 在兩設備之間的額外L2CAP channels必須與其他相同baseband的acl link共享
遵循這個要求的執行,低層必須回傳一個 LP_ConnectCfm 或者一個 LP_ConnectCfmNeg 去指示目前這個要求是否令人滿意.
LP_QosReq L2CAP要求低層協定去容納一個獨有的Qos參數集.遵循這要求的執行,低層回傳一個LP_QosCfm 或者LP_QosCfmNeg去只是這個要求是否令人滿意.
LP_ConnectRsp 一個確定的回應接受之前連結指示的要求.(可參考 Section 3.1.1 的LP_ConnectInd)
LP_ConnectRspNeg 這個就跟上面相反,是拒絕
3.2.2 L2CAP對L2CAP警示的動作
這一節包含了和Section 3.1.2 相同的名稱識別,除了動作參考了傳輸,而不是接受.
3.2.3 L2CAP對L2CAP資料動作
這一節與Section 3.1.3極為相似,資料傳輸是主要的動作.
3.2.4 L2CAP對上層的動作
L2CA_ConnectInd 指示一個連接要求已經從遠端設備被接受.(參考 Section 3.1.4 的 L2CA_ConnectReq)
L2CA_ConnectCfm 確認連接要求已經被接受(參考 Section 3.1.4 的L2CAP_ConnectReq),
L2CA_ConnectCfmNeg 連結要求的否定確認(參考Section 3.1.4 的L2CA_ConnectReq). 或者是RTX timer逾時發生(參考Section 3.1.5 與L2CA_TimeOutInd的下面)
L2CA_ConnectedPnd 確認連結回應已經被遠端的設備接收.
L2CA_ConfigCfm 指示遵循從遠端裝置的回應安裝要求已經被接受
L2CA_ConfigInd 指示一個裝置要求已經從遠端裝置被接收.
L2CA_ConfigCfmNeg 裝置要求的相反確認. 或者是 RTX timer 逾時發生
L2CA_DisconnectInd 從遠端裝置來的指示中斷連接要求已經被接收.或者遠端裝置已經中斷連接,因為他已經無法回應一個警示要求.
L2CA_DisconnectCfm 確認一個遵循自遠端裝置收到的中斷連接回應的中斷連接要求已經被遠端裝置執行.
L2CA_TimeOutInd 指示RTX或ERTX timer已經逾時. 這個指示將會在L2CAP快放棄時或在送出L2CA_DisconnectInd而發生.
L2CA_QoSViolationInd 指示服務同意品質已經污損.
3.3 Channel Operational States
.Closed 在此狀況下,沒有任何頻道會與CID關聯.這是唯一一個 link level 連結baseband不會存在的狀況. 連接中斷連結強迫所有其他狀態到Closed的狀態
.W4_L2CAP_Connect_rsp 在此狀態,CID呈現一個區域終端和一個已經被送達的L2CAP_ConnectReq訊息
891204~891209
.W4_L2CA_CONNECT_RSP
在這個狀態下,遠端終端點存在,而且一個L2CAP_ConnectReq已經被本地的L2CAP實體所接收.
一個L2CA_ConnectInd已經被送到上層而且一部份正在處理已經收到的L2CAP_ConnectReq的本地L2CAP實體等待一致的回應
回應有可能需要一個安全的防護被執行
.CONFIG
在這個狀態,連接已經被建立,但是兩邊仍然在協商channel參數.
當channel參數被重新談判的時候,配置狀態可能也被進入.
進入配置狀態之前,所有出去的資料傳遞應該被暫停,直到資料傳遞的傳遞參數被重新談判.
直到遠端channel端點已經進入配置狀態之前,進來的資料傳遞都必須被接受.
在配置狀態,兩邊必須發布L2CAP_ConfigReq訊息,如果預設已經被使用,一個null的訊息必須被送出,可以參考Page 280的Section 5.4.
如果大量的參數需要被重新談判,多重訊息可以被送出,以避免任何MTU限制以及多餘的談判,可參考Page289的Section6.
從配置狀態移到開啟狀態,需要兩邊都ok才行.當L2CAP實體收到一個確定的回應發出最後的要求而且也正確的回應遠端裝置最後的要求時,一個L2CAP實體才ready.
.OPEN
在此狀態下,連接已經被建立並被配置,而且資料流可能已處理.
.W4_L2CAP_DISCONNECT_RSP
在此狀態,連接正在關閉,而且L2CAP_DisconnectReq訊息已經送出.此狀態正在等待一致的回應.
.W4_L2CA_DISCONNECT_RSP
在此狀態,在遠端端點的連接正在關閉而且一個L2CAP_DisconnectReq訊息已經被接收.
一個L2CA_DisconnectInd已經送出到上層去通知正在被關閉中的CID的擁有者.
此狀態正在等待從在回應遠端端點之前的上層而來的一致回應.
3.4 對應
這邊則是一份超清楚的對應圖
什麼樣的事情會發生什麼樣的事件
什麼樣的事件跟其他事件又有什麼關係
什麼時候該發生
超清楚
page 266~271
891211~891215
4 資料封包格式
L2CAP以packet為基底,但是遵循以channel為基底的通訊模式.
一個channel呈現一個在遠端L2CAP實體設備間的資料流.
Channels可以是”連接導向傳輸”或者是”無連接傳輸模式”.
所有packet欄位使用小印地安位元排序.
4.1 連接導向傳輸
圖4.1描述包含了連接導向channel的L2CAP packet格式(也參考了 L2CAP PDU)
長度欄位共有2 octets (16 bits)
排除掉L2CAP表頭的長度,其他就是可搭載的資料量.
可搭載的資料量可以到65535 bytes.
傳輸結束時,長度欄位為要重組的L2CAP packet提供了一個簡單的一致性檢查.
Channel ID: 2 octets
Channel ID 識別出packet的目的channel端點.channel ID 的範圍與packet要被送到的設備有關.
Information: 0 到 65535 octets
這包含了從上層協定收到的packet(outgoing packet),或者是傳送到上層協定的packet(incoming packet).
連接導向型(MTUcno)的最小被支援的MTU是在channel配置中被協商出來的.(可看Page 289的Section 6.1)
信號型的(MTUsig)的最小被支援的MTU有48 bytes.(可看Page275 的 section 5 ).
4.2 無連接傳輸模式
附加於連接導向傳輸的channel,L2CAP也提供群組導向channel的概念.
再最好的狀況下,資料被送到 ‘group’ channel 然後會被轉送到所有在此 group 中的成員.
群組(group)沒有任何與它們相關的服務品質.
群組channels是不可被信賴的; L2CAP不提供任何資料會成功送到群組成員的保證.
如果相關的群組轉移是必須的,他必須在更高的層面去實作.
傳播到一個群組必須不可以獨占的送到該群組的所有成員.
本地端設備不能是一個群組中的成員,而且高層協定正預料著回傳任何傳送到本地端設備的資料.
不可以獨占意味著無群組的成員可能收到群組的傳訊而且高層(或連結層)的加密可以被使用來支援私密的通訊.
欄位有:
Length: 2 octets
長度指示資料量的大小,包含PSM欄位的大小,但不包含L2CAP表頭的長度.
Channel ID: 2 octets
Channel ID (0x0002)保留用來作無連接傳輸模式的傳遞.
Protocol/Service Multiplexer(PSM): 2 octets (最小)
PSM 欄位以ISO 3309為主的一個位址欄.
PSM欄位的內容起源於PSM的值,必須是奇數, 最小的指示octet必須是’1′
看 page 278 的 section 5.2,有比較詳細的定義.
資料: 0 到 65533 octets
資料量要被散佈到群組中的每個成員.
實作必須支援最小無連接傳輸MTU 670 octets, 在某些特例下可以小於這個數值.
L2CAP群組服務介面提供基本群組的管理途徑, 包括建立一個群組,為群組增加成員,從群組中移除成員.
沒有任何預先定義的群組.

apcompat

一日在Windows 2000 雜誌10月號中看到 w2k 可以騙過以前的應用程式讓他們以為 w2k 是NT的舊版本或只是Windows的舊版本.
這個工具叫做 apcompat.exe, 可以在 w2k支援工具 的光碟片中的\support找到.
指令列格式如下:
apcompat -v
參數中的 -vVersion Name(版本)可以是:
1-> nt4.0 sp3
2-> nt4.0 sp4
3-> nt4.0 sp5
4-> windows 98
5-> windows 95
參數-x 表示執行的程式路徑與名稱
-d 表示要關閉記憶體堆疊管理程式
-t 則表示使用 \temp 當作暫存資料夾
-g 則是校正偵測到的磁碟空間
-k 表示要儲存特定應用程式相容工具的設定值