寫完《關於remoting》之後，算是把這幾天學習remoting的思路理了一下。remoting的基本知識是很簡單的，但一旦深入，就會發現博大精深。昨天看到微軟社群的一貼廣告，說台灣的某個mvp寫了一本書，是專門講iis的安全知識的。於是想到，如果要把微軟產品的每一項功能去窮盡，可能每個看似很小的模組都能寫成一本大部頭書吧。remoting也是如此，要把每個細節都弄清楚，談何容易。
我之學習remoting是帶著目的而來的，起因還是公司要做的專案。最初在webservice和remoting之間權衡，最後因為專案主要應用在區域網中，而remoting在區域網內的效能優勢是webservice不可比肩的。所以選定了它。remoting是乙個分布式處理服務。我們的想法是要在伺服器上部署多個服務，而客戶端則接收服務處理具體的業務。在remoting中，我們可以簡單地將它要傳送的遠端物件看成是乙個服務。接收服務，就是例項化這個遠端物件，再呼叫其方法就ok了。
看似簡單，但問題也接踵而至。首先，我們在伺服器端提供的服務是可以定製的。這裡所謂定製，即管理員可以在伺服器端關閉或啟動指定的服務，同時可以檢視其當前狀態。也就是說，要提供類似windows作業系統下的「服務」系統。然而這就是問題的關鍵。windows服務中，每一項服務就是乙個程序，關閉該服務，其實就是關閉其程序。而在remoting中，我們也可以將其通道看作乙個程序，乙個通道又占用乙個埠。
設想一下，如果我們要提供多個服務，且將乙個服務當作乙個程序的話，在remoting中，就將占用多個通道和埠了。產生的問題是：
1、埠占用過多，是否會影響系統的效能？
2、不能只使用80埠。那麼如果使用了其他埠，怎樣通過防火牆？
如果大家還不太清楚這個問題，可以設想webservice。在webservice中，每提供乙個服務，都將在iis下建立乙個虛擬目錄來指向它。我仔細看了iis的sdk，不管是用程式設計的方式，還是直接在作業系統下操作iis，都沒有關閉乙個虛擬目錄的功能，除非將其刪掉。也就是說，要關閉這個指定的web服務是不行的。唯一的方法就是關閉其web站點。預設情況下，你建立了多個web服務，都會放在預設的web站點下。這樣，你關閉了web站點，事實上就關閉了所有的服務。這與remoting何其相似！remoting中，你也能夠關閉通道，那麼這個通道所承載的所有遠端物件（即服務）也就被關閉了。
好，那麼我們就退而求其次吧，就用關閉通道的方式來停止服務。我們有兩個方案來選擇。一是並不關閉通道，而是關閉其對客戶端的監聽，方法是stoplistening()。這樣有個好處，就是通道仍然存在，一旦你需要使用，還可以開啟通道，方法是startlistening（remoting中，一旦註冊了通道，預設就開啟了監聽）。第二個方案是登出通道，方法是unregisterchannel()。一旦登出了該通道，通道就不能使用了，而通道所占用的埠也將被釋放。
這兩個方案都很有用。如果我們要暫停服務，可以使用第一種，它便於我們重啟。如果要徹底停止服務，可以使用第二種。看來問題以一種妥協的方式解決了！？遺憾的是，我們在做測試的時候，發現這兩種關閉通道的方法是由延遲的。當我們在客戶端關閉通道後，客戶端呼叫遠端物件方法，發現仍然可以正常使用。起初我們懷疑是啟用方式的問題。因為我們最初採用的是singlecall方式，它是無狀態的。但改為客戶端啟用方式，仍然如此。為物件加上生命週期，還是照舊。
那麼什麼時候它才真正關閉呢？老實說我不知道。在測試時，我們大約過了一分鐘，再在客戶端呼叫遠端物件方法，這時才出現異常，提示目標不能正常連線。
即時這個方案能實現，仍然不符合我們要求的。我們理想的答案，還是希望能操作每個指定的物件。了解了一些remoting的知識，發現remoting的乙個通道註冊多個遠端物件，它的管理方式是把這些遠端物件放在乙個雜湊表中，然後為每個遠端物件指定乙個唯一標識，作為雜湊表的鍵值。當客戶端發出請求後，可以根據這個鍵值來找到請求的物件，然後例項化它。我們看通道註冊物件的方法，registerwellknownservicetype()，這個register大概就是將其新增到這個雜湊表中吧。遺憾的是，沒有找到對應的unregister（）方法。因為我們的想法是，如果能夠把物件從這個雜湊表中移出，客戶端發出請求時，自然找不到該物件，此時會丟擲異常，不就等同於關閉了該服務嗎？沒有unregister()方法，我也沒有能找到得到這個雜湊表的方法，那麼這個idea也只能夭折了。真是不甘心啊！
總結我的疑惑就是：
1、怎樣將已註冊的物件從通道中登出（或移出）？
2、退而求其次的方案，那麼為什麼關閉了監聽或關閉了通道，會有乙個時間上的延遲？延遲又是多少？
Scala初學的幾個疑惑
以scala的bigint為例，呼叫 val v bigint 12321 實際呼叫 是 另外乙個例子寫的很好就直接拿來用了 packagecom.robin.study created by robinmac on 15 7 22.classdefvalv3 bigint 123121 def d...
關於ARP欺騙實驗的幾個疑惑點
上次寫了篇文章，說了關於arp欺騙後擷取內網流量的實驗。經後來反覆驗證，發現實際成功率很低，而且對於手機端似乎還並不怎麼起作用。這讓我很是疑惑，於是今天又針對drifnet進行了一點探索。探索發現了以下幾點 1 在進行了arp欺騙之後，我的電腦並不能擷取到我手機的，但是我的手機卻實實在在地已經被ar...
關於幾個疑惑記錄在這裡
一 linux下的網絡卡驅動有固定的資料結構，比如struct net device 如果只是填充struct net device是不是就可以驅動乙個網絡卡呢？看了e1000網絡卡驅動的probe函式，發現主要的資料結構包括struct e1000 adapter和struct e1000 hw，...