「技術的原理,」mDNS

最近遇到一個問題，7688為什麼可以mylinkit.local 就連上呢，而不用先知道IP。

週邊有一些Device，也是用類似的方法，網域都是xxxx.local  。 

研究了一下，發現原來有一個東西叫做mDNS （Multicast DNS ）。

一般我們在一個WiFi的區網內，需要先探知對方的IP，才能夠和對方進行溝通，

不然就必須使用broadcast  或是  Multicast 的方式，使對方收到封包後主動回應。


以下是mDNS的簡介

mDNS協議適用於區域網內沒有DNS伺服器時的域名解析，設備間通過群播(Multicast)

的方式交互DNS記錄來完成域名解析，約定的組播地址是：224.0.0.251，

埠號是5353，mdns協議使用DNS協議一樣的封包格式。

mDNS協議和DNS協議還有些不同，mDNS只能用於區域網內部，並且它只接受

解析主機名前綴為.local的域名，因此mDNS也是可以和DNS在同一台設備上共存的，

以及它們存儲記錄的區域是分開的。

windows和android預設是不支援mDNS的，windows額外安裝軟體才能支援，

Android暫時還沒頭緒，找到再和大家分享。

參考來源：

區域網設備發現之Bonjour協議
https://kknews.cc/zh-tw/tech/o4ybmm.html
Multicast DNS
http://www.ietf.org/rfc/rfc6762.txt

「技術的原理」8*8 LED 矩陣顯示原理

我買了一個8*8的LED 矩陣，總共只有16隻腳控制，爬文之後發現，其實它並不是

一次讓你要顯示的內容全部顯示出來，而是利用視覺暫留，一列一列的顯示。

例如我要顯示一個A，則是在快速掃描的情況下，做了以下八個畫面

視覺暫留的結果看起來就是一個A囉

[技術的原理, ]實現Http斷點續傳

斷點續傳的原理，其實HTTP協定內已經有了，視Browser支援與否。

---

首先我們要下載一個 http://192.168.1.203/test.7z

透過Chrome 開發人員工具來看一下，一般我們直接下載一個檔案

head內容是什麼。

Request Head

GET /test.7z HTTP/1.1 Host: 192.168.1.203 Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: zh-TW,zh;q=0.8,en-US;q=0.6,en;q=0.4,zh-CN;q=0.2

Response Head

HTTP/1.1 200 OK Date: Tue, 07 Apr 2015 00:34:58 GMT Server: Apache/2.2.15 (Oracle) Last-Modified: Tue, 07 Apr 2015 00:33:02 GMT ETag: "1804d0-98e8754-513178ea80d56" Accept-Ranges: bytes Content-Length: 160335700 Connection: close Content-Type: text/plain; charset=UTF-8

首先我們發現到伺服器收到Requset之後，回應回來的狀態碼是 200，跟據WIKI上的解釋

200 OK  : 請求已成功，請求所希望的響應頭或資料體將隨此響應返回。

也就我們要下載的teset.7z 會整包下載回來，但這樣就無法達成續傳的要求。

---

查閱網路上資料，其實整包下載與"部份" 下載只差在Request Head 中需要多一行

Range: bytes 20-40

20-40指的是從第20個byte到40個byte (共21個)。

你可以用curl指令來測試伺服器是否支援 Range byte

範例如下，請將網址換成實際上用的URL

curl --silent --range 20-40 http://curl.haxx.se/docs/manpage.html | wc -c

以上述例子，如果輸出為21，表示伺服器支援，若回傳值為檔案完整大小，表示不支援。

若要開啟伺服器支援rangle byte，修改Apache 設定檔

  <Directory "/opt/local_htdocs">
       Options FollowSymLinks Indexes
       AllowOverride None
       Order allow,deny
       Allow from all
       Header set Accept-Ranges bytes
    </Directory>

參考來源：

http://www.unidata.ucar.edu/software/thredds/current/netcdf-java/reference/HTTPservice.html

「技術的原理」iBeacon 計算距離

protected static double calculateAccuracy(int txPower, double rssi) {
  if (rssi == 0) {
    return -1.0; // if we cannot determine accuracy, return -1.
  }

  double ratio = rssi*1.0/txPower;
  if (ratio < 1.0) {
    return Math.pow(ratio,10);
  }
  else {
    double accuracy =  (0.89976)*Math.pow(ratio,7.7095) + 0.111;    
    return accuracy;
  }
} 

參考資料：

http://stackoverflow.com/questions/20416218/understanding-ibeacon-distancing

[玩具]顏色傳感器（Color sensor)

1、TCS3200 識別顏色的原理:
    TCS3200 識這種可編程的彩色光到頻率轉換器適合於色度計測量應用領域,如彩色打印、醫 療診斷、計算機彩色監視器校準以及油漆、紡織品、化妝品和印刷材料的過程控制和色彩配合。 本文以 TCS3200 識在液體顏色識別中的應用為例,介紹它的具體使用。

2、 三原色的感應原理
    通常所看到的物體的顏色,實際上是物體表面吸收了照射到它上面的白光(日光)中的一 部分有色成分,而反射出的另一部分有色光在人眼中的反應。白色是由各種頻率的可見光混 合在一起構成的,也就是說白光中包含著各種顏色的色光(如紅 R、黃 Y、綠 G、青 V、藍 B、紫 P)。根據德國物理學家赫姆霍茲(Helinholtz)的三原色理論可知,各種顏色是由不同比例的三 原色(紅、綠、藍)混合而成的。


3、 TCS3200 識識別顏色的原理 

    由上面的三原色感應原理可知,如果知道構成各種顏色的三原色的值,就能夠知道所測試物體的顏色。對於 TCS3200 識來說,當選定一個顏色濾波器時,它只允許某種特定的原 色通過,阻止其它原色的通過。例如:當選擇紅色濾波器時,入射光中只有紅色可以通過, 藍色和綠色都被阻止,這樣就可以得到紅色光的光強;同理,選擇其它的濾波器,就可以 得到藍色光和綠色光的光強。通過這三個值,就可以分析投射到 TCS3200 識傳感器上的光 的顏色。


4、白平衡和顏色識別原理 

    白平衡就是告訴系統什麽是白色。從理論上講,白色是由等量的紅色、綠色和藍色混合而成的;但實際上,白色中的三原色並不完全相等,並且對於 TCS3200 識的光傳感器來說, 它對這三種基本色的敏感性是不相同的,導致 TCS3200 識的 RGB 輸出並不相等,因此在 測試前必須進行白平衡調整,使得 TCS3200 識對所檢測的“白色”中的三原色是相等的。進 行白平衡調整是為後續的顏色識別作準備。在本裝置中,白平衡調整的具體步驟和方法如下: 將空的試管放置在傳感器的上方,試管的上方放置一個白色的光源,使入射光能夠穿過試 管照射到 TC3200 識;根據前面所介紹的方法,依次選通紅色、綠色和藍色濾波器,分別測 得紅色、綠色和藍色的值,然後就可計算出需要的三個調整參數。


當用 TCS3200 識識別顏色時,就用這三個參數對所測顏色的 R 、G 和 B 進行調整。這里有兩 種方法來計算調整參數:1依次選通三種顏色的濾波器,然後對 TCS3200識的輸出脈沖依 次進行計數。當計數到 255 時停止計數,分別計算每個通道所用的時間。這些時間對應於實 際測試時 TCS3200 識每種濾波器所采用的時間基準,在這段時間內所測得的脈沖數就是所 對應的 R 、G 和 B 的值。2設置定時器為一固定時間(例如 10ms ),然後選通三種顏色的濾波 器,計算這段時間內 TCS3200識的輸出脈沖數,計算出一個比例因子,通過這個比例因子 可以把這些脈沖數變為 255。在實際測試時,使用同樣的時間進行計數,把測得的脈沖數再 乘以求得的比例因子,然後就可以得到所對應的 R 、G 和 B 的值


資料來源：

http://www.ltc.com.tw/images/mtardtcs3200.rar

[技術的原理] 繼電器

簡單紀錄一下繼電器的工作原理

繼電器（Relay），也稱電驛，是一種電子控制器件，它具有控制系統（又稱輸入迴路）

和被控制系統（又稱輸出迴路），通常應用於自動控制電路中，

它實際上是用較小的電流去控制較大電流的一種「自動開關」。

故在電路中起著自動調節、安全保護、轉換電路等作用。

繼電器工作原理動畫（圖片來源）

講簡單一點，我可以一個給一個5V的電壓，去啟動電磁鉄，把"大電壓"那一端接通，

當我的控制端輸出為0V時，"大電壓"那一端就不會連通 ，小電壓就像是將軍，

大電壓就像是軍隊，將軍手上一半的兵符與皇帝發出的兵符相接那一刻，

軍隊就出征了。


參考資料：
http://zh.wikipedia.org/wiki/%E7%BB%A7%E7%94%B5%E5%99%A8

[技術的原理]DHCP

動態主機設定協定（Dynamic Host Configuration Protocol, DHCP）

是一個區域網路的網路協定，使用UDP協定工作，主要有兩個用途：

• 給內部網路或網路服務供應商自動分配IP位址給用戶
• 給內部網路管理員作為對所有電腦作中央管理的手段

DHCP於1993年10月成為標準協議，其前身是BOOTP協議。當前的DHCP定義可以在

RFC 2131 中找到，而基於IPv6的建議標準（DHCPv6）可以在 RFC 3315 中找到。

運作原理： 

Step 1. Client ---DISCOVER---> Server            （Client廣播說 Server請回答）

Step2. Server ---DHCPOFFER---> Client          （一個或多個Server 廣播自己的資訊）

Step3 . Client ---DHCPREQUEST---> Server      （Client廣播說我要跟XX Server 要IP）

Step4. Server ---DHCPACK---> Client              （被選中的Server廣撥Client的IP資訊）

---

當IP租約快到期時 ，必須再發送一次DHCPREQUEST 給DHCP Server，否則IP將被收回。

Server Listen 67 port

Client Listen 68 port

資料來源：

http://zh.wikipedia.org/wiki/%E5%8A%A8%E6%80%81%E4%B8%BB%E6%9C%BA%E8%AE%BE%E7%BD%AE%E5%8D%8F%E8%AE%AE

「技術的原理」VNC(RFB 協定）

本篇是俺以過去的一些經驗，加上網上找到的資料做個紀錄，若有錯誤請不吝指正。

WIKI 上的解釋（截錄一小部份）

VNC（Virtual Network Computing），為一種使用RFB協定的螢幕畫面分享及遠端操作軟體。VNC由Olivetti & Oracle研究室所開發，此研究室在1999年併入美國電話電報公司（AT&T）。AT&T於2002年中止了此研究室的運作，並把VNC以GPL釋出。

原來的AT&T版本已經不再使用，因為更多有重大改善的分支版本已經出現， 像是RealVNC， VNC tight 和UltraVNC， 他們具有全面的向後兼容。至少對於基本的遠程控制功能而言。 Real VNC 是當前最活躍和強大的主流應用。

上圖是VNC的運作概念，RFB Server，也就是所謂的被控端，傳送有變化的螢幕區塊到RFB Client端，然候RFB Client則傳送滑鼠，鍵盤指令過去。而RFB對Client硬體要求不高，它只是把傳送過來的區塊資料繪圖在螢幕上 ，而把變化的區塊計算、壓縮等等的工作都落在Server身上。

基本上區塊的內容並不是固定的大小，視不同的範圍以及壓縮方法不同可能有所改變。區塊內的內容會包含區塊內容（可能是經過壓縮運算或RAW）、區塊左上角的X、Y位置（相對於Server螢幕)，區塊的長寬高。

關於畫面的更新機制，其實Server並不是一直傳送更動區塊給Client，而是由Client端所驅動。（The update protocol is demand-driven by the client.）這樣有一個好處，當遇到Client端硬體較弱或是網路很差時，可以在client己繪完圖後再要求更新，或是依網路情況調整更新速度，給予RFB協定一定程度的彈性。值得注意的是，Server可能會合併數個FrameUpdateRequest，然候只回傳一次畫面更新。

輸入的協定為標準的鍵盤以及滑鼠（支援滾輪，左、右鍵），當然你也可以用手寫，經過識別後再模擬成鍵盤事件傳送過去(需自行實作或現有的資源做開發，例如我在手寫皮上手寫個C，被識別後就當做我按下C這個鍵傳送出去）。

在區塊資料上其實支援了幾種方式（編碼），Client會提交所支援的數種方法供Server端選擇，Server端會選擇對Server端最有利的方式處理。（However  if the client is able to cope equally with several different formats or encodings, it may choose one which is easier for the server to produce.）
當然您也可以自己實作編碼方式，只要Server端以及Client都實作支援自訂編碼即可。

-----------------------------------------------------------------------------------------------------------

像素格式常見有 8 位元的 colour map ，以及 16位元以及24位元的true colour 。
編碼的方式，主要有以下幾種，詳細在最後一節有說明。

 1.Raw encoding

2.Copy Rectangle encoding

3. RRE encoding

4.Hextile encoding


資料來源 http://greatcreatcreate.blogspot.tw/2009/09/rfb-vnc.html

5. ZRLE encoding

資料來源 http://greatcreatcreate.blogspot.tw/2009/09/rfb-vnc.html

Pseudo Encodings

編碼資料中對於偽編碼(Pseudo Encodings)，Client可以對Server要求“pesudoencoding”，宣告其本身支援這一類型的擴充協定；假若Server不支援”pseudo-encoding”則會略乎此編碼。該注意的是Client必需假設Server不支援這類的擴充，直到Client從Server取得真正完成擴充認證。

資料來源 http://greatcreatcreate.blogspot.tw/2009/09/rfb-vnc.html


下列圖表是各種VNC軟體對編碼的支援程度。可以注意到其實有些編碼方式並不在上述列表中，例如像tight, Ultra  等等，皆是後來分支新增的編碼方式。

Feature Matrix

Software	Raw	CopyRect	RRE	CoRRE	Hextile	ZRLE	ZYWRLE	zlib	tight	zlibhex	Ultra	UltraZip
libvncclient	y	y	y	y	y	y	y	y	y	y	y	y
libvncserver	y	y	y	y	y	y	y	y	y	y	y	y
tigervnc	y	y	y	y?	y	y	n	n	y	n	n	n
ultravnc	y	y	y	y	y	y	y	y	y	y	y	y
tightvnc	y	y	y	y?	y	y	n	n	y	n	n	n
realvnc
qemu	y	y	n	n	y	n	n	y	n	n	n	n
gtk-vnc	y	y	y	n	y	y	n	n	y	n	n	n

資料來源 http://wiki.qemu.org/Google_Summer_of_Code_2010/VNC#RRE


RFB協定可以依任何可靠的定協傳送資料 (如TCP/IP)，即使byte-streamor。正常來說RFB主要透過TCP/IP達成連線。完成一個RFB協定有三個步驟：第一步為「handshaking phase」，此階段主要是去同意協定的版本及使用的安全型態；第二步為「initialization phase」，即對Server與Client互相交換「ClientInit」及「ServerInit」的訊息。第三步為「normal protocol interaction」，Client將能夠傳送任何它想傳送的訊息，然後接受Server回傳的結果。

資料來源 http://greatcreatcreate.blogspot.tw/2009/09/rfb-vnc.html

Protocol Messages

首先我們先了解RFB中使用的資料型別， 
U8, U16,U32  表示不帶正負號 8 ，16 ，32 bit
 INT8, INT16, INT32  表示帶正負號 8 , 16 ,32 bit. 

除了pixel本身的值以外，所以協定中用到的byte 皆使用big endian order 



會有Byte order的問題主要在於當需要表現超過255的數字時，需要兩個以上的Byte。此時，究竟要以代表比較小的數字的byte先放，還是代表比較大的數字 先放呢？以小的數字的Byte先放的作法就稱為little-endian。反之，以大的數字的byte先放的就稱為big-endian。 例如下列4組2進制 表示10進制的66051， 最高位元組先存，則為big-endian ,

00000000 00000001 00000010 00000011


若存成下列這副模樣，則為little-endian

先 00000011 然後 00000010 然後 00000001 最後 00000000


資料來源 http://www.dev.idv.tw/mediawiki/index.php/%E5%90%84%E7%A8%AE%E7%B3%BB%E7%B5%B1%E7%9A%84Byte_order

http://jyhshin.pixnet.net/blog/post/26587992-big-endian-(%E5%A4%A7%E9%A0%AD%E6%B4%BE)%EF%BC%8Clittle-endian-(%E5%B0%8F%E9%A0%AD%E6%B4%BE)




RFB 從交握到開始傳送畫面的運作模式如下圖

協定版本
「Handshaking　Phase」開始前，Server會傳送ProtocolVerstion的訊息給Client，好讓Client能夠知道Server端支援RFB的最高版本，隨而Client回應Server可使用的版本號碼(不一定與Server的版本號碼相同)，正常來說，Client不該要求高於Server端RFB的版本。

ProtocolVersion message 內容是 12 bytes  ASCII characters  格式為  "RFB xxx.yyy\n" ，XXX為主要版本號，而yyy為次要版本號。 目前有以下三種可能。

No. of Byte	Value	Remark
12	“RFB 003.003\n” (hex 52 46 42 20 30 30 33 2e 30 30 33 0a)	3.3
12	“RFB 003.007\n” (hex 52 46 42 20 30 30 33 2e 30 30 37 0a)	3.7
12	“RFB 003.008\n” (hex 52 46 42 20 30 30 33 2e 30 30 38 0a)	3.8

安全性
一定協定版本確認後，Client、Server在連線時，必需協議共同的安全性標準。假若Client支援的安全性協定有在Server列舉的安全性協定清單中，Client會回傳單一byte的訊息告知Server某安全性協定可被用於這次的連結。　　在進行Handshaking Phase時，不論這一階段的連成是否成立，Server都會傳送一個字串通知Client，假若連線成立，RFB協定即進行下一階段──Initialization Phase.
假若安全性連線失敗，Server則傳送一則字串描述此異常，隨後終止連結。

Server 必須傳送所支援的安全性清單，格式如下表

No of bytes	Type                         [Value]	Description
1 number-of-security-types	U8 U8 array	number-of securitry-types security-types

如果 number-of security-types 為零，或發生版本無法支援等等，則Server端必須回應一個理由給Client後中斷連線

No.  of bytes	Type            [Value]	Description
4 reson-length	U32 U8 array	reason-length reason-string

下列是安全性認證的列表

Number	Name
0	Invalid
1	None
2	VNC Authenication
5	RA2
6	RA2ne
16	Tight
17	Ultra
18	TLS
19	VenCrypt
20	GTK-VNC SASL
21	MD5 has authentication
22	Colin Dean xvp

Client回應選擇認證類型

No. of bytes	Type     [Value]	Description
1	U8	security-type

VNC認證
連線時，隨送傳送16位元的VNC認證，而協定資料不做加密的動作。Server會隨機產生一個16 byte的要求Client回應特定的訊息。Client依據Server傳送過來的16 byte編碼為金鑰，並加密回傳此金鑰以回應Server。而此更協定依據項些安全性協定的回應持續進行下去。

Server 16 byte 金鑰

No. of bytes	Type     [Value]	Description
16	U8	challenge

Client回覆內容

No. of bytes	Type     [Value]	Description
16	U8	response

Server回覆

No. of bytes	Type     [Value]	Description
4	U32	status: OK failed

在3.8版開始，如果Client回覆的認證Server不接受，則亦回覆一個錯誤原因

No.  of bytes	Type            [Value]	Description
4 reson-length	U32 U8 array	reason-length reason-string

訊息初始化
當Client、Server建立安全性連結後，接著會進行初始化層段(initialsation phase)
這個階段，在Client傳送一個「ClientInit」，Server隨即會傳送「ServerInit」訊息。


ClientInit：
Client回應的訊息只有一個「shared-flag」參數，若值非「0」(true)，則表式Server試著去持續共享桌面而不對其他的Client端做終止連線的動作，反之，若值為「0」(false)，則表示終止其他連線，僅對某Client端提供桌面分享的服務。

No. of bytes	Type     [Value]	Description
1	U8	shared-flag

ServerInit：
Server 接受ClientInit訊息後，會接著發送ServerInit訊息，此訊息會告知Client端Framebuffer的長、寬、像素格式以及此桌面相關名稱。

No. of bytes	Type     [Value]	Description
2	U16	framebuffer-width
2	U16	framebuffer-height
16	PIXEL_FORMATR	server-pixel-format
4	U32	name-length
name-lenght	U8 array	name-string

PIXEL FOMAT

No. of bytes	Type     [Value]	Description	Remark
1	U8	bit-per-pixel	只能是8,16,32
1	U8	depth	位元深度（<= big-per-pixel)
1	U8	big-endian-flag	是否為big endian
1	U8	true-color-flag	是否使用true - color
2	U16	red-max	紅色最大值
2	U16	blue-max	藍色最大值
2	U16	green-max	綠色最大值
1	U8	blue-shift	在一組位元中，藍色必須位移多少
1	U8	red-shift	在一組位元中，紅色必須位移多少
1	U8	blue-shif	在一組位元中，綠色必須位移多少
3		padding

資料來源 http://greatcreatcreate.blogspot.tw/2009/09/rfb-vnc.html
                  http://www.realvnc.com/docs/rfbproto.pdf

Client to server messages ( 由Client傳給Server的封包格式）


Client傳給Server的Message有以下幾種，下面會分別介紹各種Message的封包結構，Server依此表格Number做為識別封包是何種類型，才有辦法正確解毒（每一封Message的封包格式長度都不同）

Number	Name	Remark
0	SexPixelFormat	設定PixelFormat
2	SetEncodings	設定編碼
3	FramebufferUpdatReauest	要求更新畫面資訊
4	KeyEvent	鍵盤事件
5	PointVent	滑鼠事件
6	ClientCuText	剪貼簿

 SetPixelFormat

No. of bytes	Type     [Value]	Description
1 3 16	U8            0 PIXEL_FORMAT	message-type padding pixel-fromat

PIXEL_FORMAT

No. of bytes	Type     [Value]	Description	Remark
1	U8	bit-per-pixel	只能是8,16,32
1	U8	depth	位元深度（<= big-per-pixel)
1	U8	big-endian-flag	是否為big endian
1	U8	true-color-flag	是否使用true - color
2	U16	red-max	紅色最大值
2	U16	blue-max	藍色最大值
2	U16	green-max	綠色最大值
1	U8	blue-shift	在一組位元中，藍色必須位移多少
1	U8	red-shift	在一組位元中，紅色必須位移多少
1	U8	blue-shif	在一組位元中，綠色必須位移多少
3		padding

SetEncodings

No. of bytes	Type     [Value]	Description
1 1 2	U8            2 U16	message-type padding number-of-encodings

number-of-encodings repetitions

No. of bytes	Type     [Value]	Description
4	S32	encoding-type

FramebufferUpdateRequest

No. of bytes	Type     [Value]	Description
1 1 2 2 2 2	U8        3 U8 U16 U16 U16 U16	message-type incremental x-position y-position width heigtht

在此值得注意的是，incremental這個值，如果你並未擁有或是遺失某一區塊的畫面資料時

你在呼叫FramebufferUpdateRequest 必須把incremental設為0 ，這樣Server才會傳送整塊的畫面過來，或incremental設為非零的值，Server傳來的可能是CopyRect encoding ，要你參照某一塊的頻色，以減輕網路傳送的資訊量。

KeyEvent

當您的鍵盤有輸入東西時，您可以透過key Evnet把您所輸入的內容傳輸過去

No. of bytes	Type     [Value]	Description
1 1 2 4	U8             4 U8 U32	message-type down-flag padding key

值得注意的是down-flag, 當某個鍵被按下時，down-flag為非0的值，當此鍵被釋放後，down-flag為

0值。以下是key所代表的值。 除了部份的功能鍵（F1~F12 ，CTRL ，ALT等等），都相同於ASCII CODE，下面列出功能鍵的碼。值得注意的是shift 鍵只有在被按下時才會傳送。

Key Name	Keysym value
BackSpace	0xff08
Tab	0xff09
Return or Enter	0xff0d
Esc	0xff1b
Insert	0xff63
Delete	0xffff
Home	0xff50
End	0xff57
Page Up	0xff55
Page Down	0xff56
Left	0xff51
Up	0xff52
Right	0xff53
Down	0xff54
F1	0xffbe
F2	0xffff
F3	0xffc0
F4	0xffc1
---	---
F12	0xffc9
Shift(left)	0xffe1
Shift(right)	0xff22
Control(left)	0xffe3
Control(right)	0xffe4
Meta(Left)	0xffe7
Meth(Right)	0xffe8
Alt(left)	0xffe9
Alt(right)	0xffea

PointerEvent

button-mask 是一個8bit位元組，支援了滑鼠8個按鈕，1表示按下 ，0表示此按鈕沒有被按下，

但預設button 1表示左鍵，button 2表示中鍵，button 3 表示右鍵，而滾輪的滾動則由button 4及button5表示，例如button4按下表示滾輪向上滾動，button5按下表示滾輸向下滾動。

No. of bytes	Type     [Value]	Description
1 1 2 2	U8        5 U8 U16 U16	message-type button-mask x-position y-position

ClientCutText

這東西就類似一個剪貼簿，在文字內容最後面必須要補一個AscII 10 ( 13免）

No. of bytes	Type     [Value]	Description
1 3 4 length	U8         6 U32 U8 array	message-type padding length text