Server端的資料

有關於Server端的資料，都放在 ftp://tw-yen.no-ip.org/server裡
推甄有需要用到的，請自行前往下載。
如果需要的資料不在上面，可以跟我要。
如果有要補充的資料，請自行放上去。(可匿名登入)

目前行數:3288行(含註解與空行), 2245行(不含註解)
Server端使用之平台(Windows Server 2003)...比較不會當機
CPU: Intel core 2 E6300, 1.86GHZ
Memory: 4GB

Server端的設計理念是：必須能承受同時多個請求又不過度取用資源，功能方面也必須能夠簡單地擴充。

目前曾對Server端做過5000筆資料的壓力測試，執行至今軟體本身沒有發生過異常(作業系統當機除外)。(可參考之前阿汶做的測試)

曾遇到比較有趣的問題：

1. 多執行緒同步問題。
2. 資料編碼格式問題。(編碼為UTF-8，然而在傳輸時常忘記轉碼)
3. 功能擴充問題。(在軟體設計上獲得解決)
   目前的軟體設計，予許在只更動 MarketRequestType的狀況下，就能新增一個可處理的請求型態。想要新增一個請求型態，只需要先把特定的Responder寫好(實作Responder介面)，並在MarketRequestType類別裡註冊請求型態與處理該型態的Responder即可。

由於處理請求的Responder實作類別還可以不斷擴充，我沒有把這些類別畫進類別圖裡。FTP裡的類別圖只是初稿，後來有經過一些細微修改，但大致上無太大改變。

有問題可以提出。

RFID定位目前計畫

1. 
   在資料庫儲存商品在地圖上的x,y座標位置 (假定同樣商品都會放在固定的位置)
   


2. 
   搜尋商品，先讀取兩個商品，以arc_tan((start1.y - start2.y) / (start1.x - start2.x))找出目前行進角度與方向，運算出到達目標商品的最短路徑。 (目前是假定無wifi，等wifi定位完成再想辦法整合)
   


3. 
   在地圖上標示可行進的點，作為計算最短路徑的依據。(須討論地圖的資料表示方式)
   


4. 
   Client將兩個起點與一個終點的座標傳至Server端運算出路徑，並傳回最短路徑陣列(以起點與終點表達單一直線路徑(start, end)，多個直線路徑組成一個完整路徑)。例如，傳入 start1(0,0), start2(0,10) , dest(10, 20)(螢幕左上角為 0,0)，假設走斜線有障礙物，只能走直線與橫線，則傳回 {Path[start(0,0), end(0,20)](先走直線，因目前方向為向南方走), Path[start(0,20), end(10,20)]}
   


5. 
   client請求格式:
   

   <Request type="findpath">
     <Start1 x="XX" y="XX" />  -> 第一個商品的位置
     <Start2 x="XX" y="XX" />  -> 第二個商品的位置
     <Desination x="XX" y="XX" />  目標商品的位置
   </Request>
   

   request回應格式:
   

   <Response type="findPath_success">
      <Path>
             <Start x="XX" y="XX" />
             <End x="XX" y="XX" />
      </Path>
      <Path>
             <Start x="XX" y="XX" />
             <End x="XX" y="XX" />
      </Path>
       ...
   </Response>
   

這是目前的計畫，有問題可以提出。

目前於PDA上開發的諸點困難

RFID Reader -
目前大部份的 Rfid 專案是使用 PC 作為平台，且市面上所見書籍也幾乎是以PC為例

Mysaifu( Java 虛擬機器 )
Mysaifu和原本PC的Java虛擬機器相比，功能有相差或欠缺之處

性能 -
PDA無法完美地使程式運行順暢，記憶體的限制使得程式無法載入所需的複數圖片

連線 -
目前借到的PDA未能解決連線問題

RFID Reader 賣場搜索

===使用SDIO介面(可裝置在PDA上)=====

reader
HF
$13500

===使用USB介面(可能無法裝置於PDA上)=====

reader
HF
$3900

reader
HF
$3150
備註 : 友鵬科技

Production XML 回覆格式變更

增加 "photo"

<Response type="product_found">
    <account level="3" />
    <product id="01010001" name="商品1" onsale="true" price="1000.0" expiration="30" manufacturer="NTUST" detail="" >
         <photo> 編碼 </photo>
    </product>
</Response>

參考用網址(感謝 Yen )

結帳XML(暫定)

<Request type="checkout">
<account id="??" />
<product id="??" amount="數量"/>
</Request>

傳送帳戶ID與商品ID即可。
同樣的商品若有多個，則設定amount屬性。

確認結帳的必要性再討論。
取消結帳則發送不含商品資料的結帳request即可。

定位組目前規劃

以先前所找到的paper定位方法進行實作:

架構如左圖
由client端偵測user AP強度傳給server端做定位計算

server端程式:
處理定位以及回傳位置的main
三個演算法各一class
以及一個紀錄參考點的database







三個演算法的整合想法如下:
P(x,y) = α Fun(knn) + β Fun(PDF) + γ Fun(RBFS)

目前大概模擬為 γ > α > β

(RBFN耗費以及定位精確度皆為中等 故假設加權最大，PDF計算時間最常精準度最低，到時可能會捨棄)

計劃表:
1.模擬一個database始可模擬演算法
2.先著手 KNN 以及 RBFN 演算法程式 最後PDF
(因RBFN算式較複雜，視狀況而定 可能僅採用KNN演算法( KNN是三者中定位效果最好的))
3.做好計算的main
4.做測量AP的程式(用於建立sample node 以及user的AP偵測)
5.建置sample node，完成database
6.實際測試再行修改

觸發程式時機:
定位系統發現所屬區塊變化時跳出新區塊的特價訊息(選擇性)
---為達此功能 須自動定偵測位置
使用者要求
---傳送要求時執行

結帳XML (構想)

結帳
-商品列表(裡頭的商品可能會有重覆)

確認結帳
- 交易No. ( 確認身份和取消用 )

取消結帳
- 交易No.

有問題用MSN討論

Catelog XML規格(修改)

• Request
  

  <request type="category_query" >
  <category id="10000000" page="1"/> 
  #page屬性若沒有，就預設1
  </request>

• Response
  成功找到：
  

  <Response type="category_found">
   <page current="1" all="12" />
   <category id="10010000" name="汽水"/>
   <category id="10020000" name="果汁"/>
  </Response>

  沒有找到：
  

  <Response type="category_not_found">
   <category id="10000000" page="1"/>
  </Response>

  
  

RFID Reader

http://tw.page.bid.yahoo.com/tw/auction/d41049462
為Reader
頻率 125hz
讀取距離 8~15cm
$1800
使用USB


http://tw.page.bid.yahoo.com/tw/auction/b48673433?r=1242889954
為Tag
頻率 125hz (適用上面的Reader)

有看到新的還會再更新