ASP.NET權限不足，無法使用WINDOWS應用程式

最近遇到了個問題
撰寫了一個web service掛載於IIS下，web service會透過SKYPE API呼叫本機電腦裡面的應用程式(SKYPE)作發送簡訊的功能。

未發行至IIS下叫用都是正常的，也寫了一個windows form 來叫用確認是可以執行的
但一發布到IIS下，偵錯時卻發生了.. client端程式 出現wait timeout..

開啟web service 偵錯模式，再來看看web service怎說~
web service先參考skype4com.dll，在程式裡new skypeclass()實體為 myskype都OK，下一步
myskype.sendSMS("+886xxxxxxxxx","hello","") 馬上消失，就像正在處理工作一樣程式碼沒有反紅，看不到偵錯情形。
利用try and catch把runtime error抓出來，錯誤顯示
System.Runtime.InteropServices.COMException (0x80040200): Not attached.
於 SKYPE4COMLib.SkypeClass.SendSms(String TargetNumbers, String MessageText, String ReplyToNumber)
於 Service.HelloWorld() 於 c:\Inetpub\wwwroot\WSsendSKYPE2\App_Code\Service.cs: 行 70

怪哉~GOOGLE了很久，沒有一個解決的方法~
問題可能出在"安全性"問題上~
ASP.NET預設使用者使用資源的安全性與windows應用程式預設安全性不同，所以才會有掛載在IIS下的webservice與windows form使用SKYPE.EXE權限不同!

在MSDN tech提到安全性原則部分
有兩個步驟:
1.讓ASP.NET使用者權限提到最高，可以執行、讀取、寫入等等
2.讓SKYPE檔案降低權限可以被設定的使用者群組執行、讀取等

之後再在web service程式碼裡頭加上
System.Diagnostics.Process.Start("Skype.exe"); 允許讀取到此執行檔


System.Diagnostics.Process.Start("Skype.exe");
錯誤顯示 :
{"System.Web.Services.Protocols.SoapException: 伺服器無法處理要求。 ---> System.ComponentModel.Win32Exception: 系統找不到指定的檔案。\n 於 System.Diagnostics.Process.StartWithShellExecuteEx(ProcessStartInfo startInfo)\n 於 System.Diagnostics.Process.Start()\n 於 System.Diagnostics.Process.Start(ProcessStartInfo startInfo)\n 於 System.Diagnostics.Process.Start(String fileName)\n 於 Service..ctor() 於 c:\\Inetpub\\wwwroot\\WSsendSKYPE2\\App_Code\\Service.cs: 行 15\n --- 內部例外狀況堆疊追蹤的結尾 ---"}

挖哩，還是讀取不到~>~<~ 不知道是使用者群組原則是否沒有設定好，但我已經把權限都改成"完全控制"了呀?! 之後也試過了web.config 組態設定，還沒試"註冊表"修改~畢竟如果轉移網站的話，不好意思把別人的系統弄掛吧>< 如果web service 可以叫用額外寫的windows form(APP1)，而APP1可以使用SKYPE API進行發送簡訊，這樣也許可以完成。只要APP1的路徑掛在IIS下，但不成為ASP.net的成員。不知道這樣的觀念有沒有錯~ 終於找到了這個想法的實現方式~"遠端物件"~~~~~ 利用.net framwork 提供的 remoting namespace把windows application當作遠端物件使用~ 依然要考慮到使用者群組安全性原則~ 但是..這又是一個大議題..依目前程度要花不少時間來看。 想著這個方法的可行性入睡~~~ 也許有另一個方式會比較間接，但可行性有9成!! 利用資料庫當作媒介，讓WEB SERVICE作寫入，另一隻程式做讀取判斷來執行SKYPE 一樣另外寫一個windows application，這隻程式不斷讀取資料庫作判斷。 這樣一來，windows application是在系統管理者的權限下執行而可以使用SKYPE API 再者，移動網站時，也不需要考慮到路徑的問題，只需要多安裝這個application了~ 但，這畢竟是較低級的方法，application 會不斷使用系統資源，還是使用event觸發的方式較能節省系統資源。

網頁問題（暫存）

目前發現的

１.在做歷史軌跡部分，時間比對在０：００～０１：００時間不會顯示。
之前還莫名其妙的在想是不是網站掛了＞＜　因為每次開啟都不一樣問題～不同瀏覽器也有問題～

2. 行動排程 按下區域應該要顯示設定的區域!

3.行動排程應該要加上時間設定(這個頭大)

3.要可以修改會員資料，並顯示資訊以及刪除功能

4.系統說明頁面未寫

5.寄發E-mail驗證未寫

6.歷史軌跡應該從有資訊的時間點開始

7.歷史資訊控制相要加入暫停紐(不知道有沒有thread的功能)

8.區域設定可以加入MRT設定

9.PDA端可以加入POWER節省控制

10.PDA佈署要在自動安裝在最右下角

11.要加入關閉螢幕背光設定

12.網頁控制項應該加入過濾精準度的能力

13.歷史軌跡應該加入畫線速度拉軸 (慢 中 快) 或是 開始/暫停 後快轉 停止 前快轉

scoket傳送封包流過長

趁著從台北開會搭公車回來,測試研究的系統穩定度
發現搭車到到一半時就發生過長時間才收到server的回應
最後一筆有效紀錄(經web server過濾後所顯示)的地圖標點

都來沒走一半呢...
回到研究室看看debug訊息~

怪哉~ 再看console
不知道什麼原因造成多筆記錄在同一筆傳送
socket封包支援到1024byte，一旦超過，傳送的data stream 就會被截斷在下一個封包繼續傳送
如果網路狀況不擁擠(小於1024byte)，那麼頂多只會loss掉幾筆資料..
但如果遇到split(,)，剛好data資料開頭剛好是"," 程式裡頭判斷所欲存之值為空..就會發生錯誤(格式不對)

看看資料庫就知道...多糟了><

看樣子，要避開這種情況目前想到只有

1. 修改每次傳送封包格式的大小，能整除1024(目前一筆資料大小為76byte以下)，這樣就能確保所存資料格式正確
   但server程式部分要限制每個欄位的資料大小，之後如果PDA要新增傳送資料，要再修改 重算能整除值...而對定位而言，更會遺失至多12筆資料(1024/76=13.47)
2. server程式先行判斷所收到資料筆數(依封包大小)，再複雜變數儲存判斷，但好像遇到封包過大，還是有stream被截的問題...
3. 搜尋stream buffer相關.. 迫使程式接收一定是一筆一筆進來分析.

看樣子 方法三應該是比較簡單的，不用修改太多程式碼，要花時間的是找stream buffer部分的知識了~

實驗八 影像傳輸效能分析與評估

實驗目的:了解各種影響影像傳輸的因素

實驗步驟與實驗七差不多

STEP1

使用ffmpeg對yuv檔案做轉換成為m4v檔案，此實驗中使用不同量化程度的視訊串流做比較，參數為qscale,量化階級:2~31

STEP2

接著再用MP4Box將m4v檔案轉成mp4檔案，需注意的是，若之後要使用不同封包大小傳送串流，下面的MP4Box的mtu選項須與之後的NS2模擬環境所使用的封包大小ㄧ致。

STEP3
利用mp4trace將影片中每一個frame相關資訊取出存在foreman_qcif.st檔案中
STEP4
接下來就可以使用ns2模擬工具開始模擬網路效能啦

STEP5

NS2模擬完後產生傳送紀錄檔sd,接收端記錄檔rd,及影片記錄檔foreman_qcif.st and mp4 file,經由etmp4 產生一個有畫面遺失的mp4檔案:

$ ./etmp4.exe sd rd foreman_qcif.st foreman_qcif.mp4 foreman_qcife

STEP6

use ffmpeg.exe to 回復上ㄧ步重建的mp4檔案成yuv檔案

STEP7
使用 avgpsnr.exe獲得重建後的yuv之PSNR value =26.609
影響影像傳輸因素探討

a. 產生GOP length 9的方式:

b.產生GOP length 15 的方式

實驗七 MyEalvid-NT

實驗目的:

了解如何使用MyEvalVid-NT去評量多媒體網路的效能，然後使用MyEvalVid-NT驗證所得知可解畫面比例分析模型。

背景:

為了測是我們提出的網路架構對於多媒體傳輸的效能影響，我們會使用影片做測試，然而因為影片版權問題所以便產生了video traffic trace file 供人下載測試，而為了讓MyEvalVid能夠使用video traffic trace file 去做網路模擬動作，因此便修改MyEvalVid使之成為一個新的工具組MyEvalVid-NT。

修改了什麼呢? 兩者之間的差異在於將MyEvalVid-NT中的Evaulate Trace(ET)做了修改，使其能計算可解畫面比例(Decodable Frame Rate)、封包/畫面遺失率、封包/畫面的端點與端點延遲、封包/畫面的抖動率。

在MPEG編碼中，被編碼的視訊串流被分類為:

Intra-coded frame: 由自己本身畫面做編碼。

Predictive-coded frame:參考先前被編碼的I-frame or P-frame 及自己本身做編碼

Bi-directionally Predictive-code frame:參考先前及後來的I-frame or P-frame 及本身自己的資料做編碼

在一個GOP的I-frame裡，所有屬於這個I-frame的封包都正確被接收到則稱此I-frame可解碼的。同理類推P and B -frame。

為了得到可解畫面比例分析模型，我們要先求得影像檔案中的三個frame可解碼的期望數目

定義: 可解畫面比例 = 所有可解碼的畫面數除以一個影像的所有畫面數


所以囉~可解畫面比例的值越大代表影像品質越好囉!

實驗步驟:

STEP1

到這裡下載video traffic trace file，抓完後打開檔案移除前兩行

存檔放入資料夾lab7裡頭

STEP2

使用NS2進行模擬

模擬結束後，會得到傳送端傳送封包的紀錄檔sd及接收端收到的封包記錄檔rd

STEP3
再進行評估分析前，須先轉換trace file的格式

轉換完會得到Verbose_StarWarsIV.st影片記錄檔

STEP4

使用et這個程式進行記錄檔sd、rd、Verbose_StarWarsIV.st做比較，就可得知在此種情晃下可解畫面數及可解畫面比例的大小為多少

可知，這次網路模擬傳輸中共送出163682 packets,其中 I-frame:28770 p-frame:45339 B-frame:89573

總共遺失:1595 其中I-frame:281 p-frame:433 B-frame:881

可解畫面比例為0.913543
total directly decodable frame 代表的意義為這個畫面所分割出來的封包全部被接收端所接收到的數目

STEP5
經由下面操作可得平均延遲時間及最大延遲時間

STEP6

先把資料收集起來 $awk'{print $1, $2}' delay_pkt.txt > delay_pkt
開始繪圖

畫面平均延遲時間及最大延遲時間

$awk'{print $1, $2}' delay_1.txt > delay_1
STEP7
封包與畫面抖動率

封包抖動率:

$awk'{print $1, $3}' delay_pkt.txt > jitter_pkt

畫面抖動率:

$awk'{print $1, $3}' delay_1.txt > delay_frame

實驗六: MyEvalVid

實驗目的:


Video Server 傳送影像至 Video Receiver，中間經過Internet 、無線網路，我們討論無線連接造成的封包遺失。

我們針對影像使用MyEvalvid 做Peak to Signal Nosie Ratio 評估，PSNR(峰值訊號雜訊比程式)是一種較為被大眾接受的影像品質鑑定客觀指標。 步驟如下

STEP1

我們使用ffmpeg.exe 把工人(foreman)的YUV檔案轉成m4V檔案

-s => set frame size , qcif means 176*144

-vcodec = >指定壓縮方式，如mpeg4

-r =>set frame rate ，這裡設定每秒30個畫面

-g => set the group of picture size，設定每一group有9個畫面

-bf = >use 'frames' B frames， 設定I與P之間or P與P之間有兩個frame

-i = >input file name，輸入來源影片 foreman_qcif.yuv

STEP2

用MP4Box把 .m4v 再轉成 .mp4

STEP3

用mp4trace.exe 將每一個frame的資訊擷取出來存到forman_qcif.st中

其中 192.168.0.2 is destination ip ，destination port number is 12346

(這邊設定不重要，因為沒有真的傳上網)

現在在lab6裡頭有這四檔案
foreman_qcif.st 裡面有400筆資料
between H and P or P and P have 2 B frame (與壓縮時的參數相關)

STEP4

開始用NS2模擬工具模擬網路效能 (lab6_1.tcl)

參數為 :

opt(0) = good->good 的機率
opt(1) = bad->bad 的機率
opt(2) = 在 good state下，封包發生錯誤的機率
opt(3) = 在 bad state下，封包發生錯誤的機率
opt(4) = seed number
opt(5) = 把每一畫面切成多少size大小的封包

傳送端送出659個封包，但接收端只收到652個封包

遺失率為0.0106

STEP5

使用模擬過程產生的TX記錄檔sd、RX記錄檔rd 與影片記錄檔foreman_qcif.st 和 mp4檔案

經由tmp4產生一個畫面有遺失的影片foreman_qcife.mp4

STEP6

再次使用ffmpeg將重建的foreman_qcife.mp4 轉回foreman_qcife.yuv

STEP7

使用avgpsnr針對重建後的 foreman_qcife.yuv 及原始foreman_qcif.yuv，獲得重建後foreman_qcife.yuv的PSNR值為34.839083

STEP8
接下來用YUViwer.exe真正觀察影片差異

左邊為原始影像，右邊為重建影像
因為封包遺失率為0.01 所以好像也不怎麼明顯
不過放大後看就有差了，畫面會比較霧些

gmap進度

終於找到存區域設定端點座標的變數了 ->endPointsMarker[i]

但是這個變數存在於function內，非廣義變數，要看完全部才能確定是否另設成廣義變數
因為endPointsMarker[i]出現在很多函式內，用不同名稱的引數做傳遞。
目前想到兩個方法:
1.用廣義變數，一但對點做任何變動或更新，就改變值(字串)。但是會更動很多地方..
2.也許只要在端點移動結束且勾選已設定好區域在抓函式內的變數就好(物件)。

終於有點進度了~
但是資料庫那邊出現
Warning: mysql_connect() [function.mysql-connect]: Can't connect to MySQL server on '140.115.51.5' (10060) in C:\Inetpub\wwwroot\php_pratice_gmapuser\db.php on line 8

Warning: mysql_select_db() [function.mysql-select-db]: Access denied for user 'ODBC'@'localhost' (using password: NO) in C:\Inetpub\wwwroot\php_pratice_gmapuser\db.php on line 10

連線無法建立，孤狗結果是資料庫server那邊有問題，要重開，再跟他們說吧~

實驗十 無線網路效能分析探討(二) Ad Hoc網路路由協定效能分析

實驗目的
1.了解如在在NS2中建立無線隨意網路(wireless Ad Hoc network)。
2.學習分析無線隨意網路路由協定(Ad Hoc routing protocols)的效能。

背景知識
行動式手提設備(手機、PDA、筆電)，都屬於可移動的無線裝置，而無線傳輸方式可分成兩大類

1. Infrastructure:透過基地台，由中央控制的傳輸模式


2. Wireless Ad Hoc Network:特色是所有節點以對等方式進行無線網路存取，不需透過無線基地台 (wiki. Sony PSP 網路對戰就是這樣一個應用，還沒玩過，殘念~~)

無線隨意網路路由協定 :

• Proactive routing protocol (table-driven protocol)

每個無線節點固定一段時間就會發送路徑訊息，各個無線節點依據收集近來的資料更新自己的路徑表，網路拓樸更動時，所有節點都會收到最新的路徑資訊，這種持續的更新會讓所有節點隨時有完整的路徑。

優點：Proactive routing protocol 讓每個送出的封包立刻得知到達目的地的路徑，沒有任何延遲 缺點：這種協定因為週期性的廣播訊息，浪費大量頻寬與無線網路節點的電源

現存的協定有：

Wireless Routing Protocol Destination-Sequenced Distance-Vector protocol

• Reactive routing protocol (demand-driven routing protocol)

當一個節點要傳送資料給另一個節點時，來源節點會呼叫一個路徑發現程序(route-discovery process)並將此保存在暫存器中，直到過期或路徑無效

優點:只有在有需要時才主動發現路徑，不需要保存對整個網路環境的路由資訊，所以頻寬使用量較小。
缺點:路徑發現程序會造成延遲，平均延遲時間較長，所以尋找路徑時間較長。

DSDV vs. AODV vs. DSR

評估參數(Performance Metrics)

下面列出在此類效能分析實驗中最常用到的幾個評估參數 1.封包送達比例(Packet delivery fraction):CBR 來源端傳送封包數/到達目的地端封包數 2.封包平均點到點延遲時間 (Average end-to-end delay of data packets):所有延遲時間的總和，包括 發現路徑的緩衝時間、MAC層的重傳時間、傳遞時間 等。 3.第一個封包收到的時間 : 用來評估路由表收斂時間，若越早收到則表是收斂速度越快，這樣才能越早把封包從Tx送到Rx 實驗步驟 intruduce tools : cbrgen & setdest cbrgen (~/ns-allinone-2.29/ns-2.29/indep-utils/cmu-scen-gen/cbrgen.tcl): generate TCP flow or CBR flow 用法 ns cbrgen [-type cbrtcp] [-nn node] [-seed seed] [-mc connections] [-rate rate] 舉例: p1