Category Archives: Network

json rpc 類似xml rpc，透過HTTP的方式進行資料交換來達成remote procedure call，最大的差別在data serialization改成JSON，另外json rpc的規範大約在2005-2010年左右，在底層的傳輸協定也不要求使用HTTP，可以是TCP/IP stream。 spec可參考 1.0 https://www.jsonrpc.org/specification_v1 2.0 https://www.jsonrpc.org/specification 概念上跟xml rpc相同，但是將client server的角色模糊了，採用對等peer的概念，當然如果以功能來看，我們可以將make function call那端看成client，function execution那端看成client，只是在json rpc中的連線概念是採用對等，任何一端可能是client，也可能是server，為了清楚的對比xml rpc文章中的範例，以下我將xml rpc中is_even改成在json rpc裡實現，用Node.js當server，python當client 輸入100 回傳結果如下 使用起來簡單直覺，python 可以再利用語言本身的proxy機制，讓呼叫起來比較簡潔 以下整理json rpc 1.0 spec 其中提到 To invoke a remote method, a request … Continue reading →

這篇整理的spec是以 http://xmlrpc.com/spec.md 為參考 在一開始spec說明xml-rpc是Remote Procedure Calling protocol，可以理解成call – return的communication pattern，而HTTP本身的protocol就是request – response，可以非常直覺地直接對應到procedure call的pattern。 spec主要就是在這樣的通訊架構下，定義資料傳輸的交換格式，並且以xml為資料格式的基底。 以前一篇is_even的例子來看 client送出的xml 在http部分 採用POST (送出xml body)，spec要求User-Agent、Host  header field must be required. 值得注意的是 header Host 在HTTP/1.1是required，在HTTP/1.0則沒有要求，nodejs client送出的header sample如下，其中Content-Length是通過計算xml body size得到(在nodejs中，如果不先算好content-length，使用stream write，會導致chunked mode transfer，這部分可能會導致server不相容，因為spec中有寫到: The Content-Length must be … Continue reading →

在跨process或是跨機器溝通上的IPC有許多方式，以http為基底的也有如SOAP、REST相關的實現，並且也發展的滿成熟的。相較之下，xml-rpc比較像是整個過程中的一個開端或是過渡的解決方案， 這篇整理會著重在背景介紹、spec的一些想法 xml-rpc發展的年代大約在1998年，這個時間點是Web開始蓬勃發展的年代，網路的通信普及也使得跨機器的溝通越來越重要，在這之前或同一個時期，其實已經有不少跨機器通信的標準或實現，例如COBRA、Sun RPC等等，在TCP/IP的環境中，加上資料的傳輸格式的定義(marshaling)，其實就可以實現了，因為不難，所以有很多其他像是COBRA、Java RMI、DCOM，都是不同團體或陣營提出的解決方案。xml-rpc就是在當時環境下的一個產物，一方面XML剛出現沒多久，作為一個資料交換的格式，XML的設計在當時跟其他的資料交換格式，更強調human readable以及machine readable，在當時常見的資料交換作法如ASN.1 + DER，常見於其他protocol (如SNMP、LDAP)。將網路+XML作為rpc的想法很自然就出現了。使用XML的代價就是 not compact，資料的大小會膨脹許多，這個對於網路頻寬資源有限的時代或是環境而言，就不是那麼受歡迎。 跨機器通信，其中有一個重點是heterogeneous platforms，因為在1998年時，很多rpc類的protocol是特定陣營提出或使用的，例如DCOM本身基本上只在Windows實現，其他的平台要實作可能會遇到很多瓶頸，例如poor implementation，或是可能架構上已經跟系統的某些元件coupling，所以完整實現很困難。COBRA則是因為本身設計的太完整、太複雜，導致無論是使用或者實現完整都有一定的難度，這個現象在很多系統發展或是標準制定都會看到，當一個設計越想要comprehensive， 想要一個解決方案涵蓋所有的問題時，常常最後會因為過度複雜，導致開發者沒辦法完全掌握。 xml-rpc的spec可以參考: http://xmlrpc.com/spec.md 我們先從實際程式範例來看xml-rpc可以做的事情 server side example: adapted from https://docs.python.org/3/library/xmlrpc.client.html python文件中有client side example 不過為了展示interop，我另外用nodejs寫了一個範例 看起來js的實現很冗長，主要的原因再methodCall要傳入 method name和argument，javascript ES6有Proxy物件，可以動態攔截function call 利用Javascript的Proxy可以讓整個api call變得非常簡潔，很可惜在C++這樣static typing的語言中沒有這樣的機制，因此在C++比較常見的作法是定義interface，再用code generator產生proxy stub

WebSocket作為在HTTP下一個很重要的雙向通信延伸的protocol，HTTP 1.0/1.1的設計是half-duplex，也就是同一個時間只會有單向傳輸(request->response)，雖然HTTP 1.1有支援http pipelining，但本質上他還是單向傳輸的的架構(第二個request不用等到第一個response收到就可以發出，但是response order還是根據request)，並且這項功能在大部分的client/server實作不完整 WebSocket出現於2009年左右(並於Chrome 4開始實作支援)，在此之前要在Web上透過HTTP protocol進行雙向通信，需要用一些技巧模擬出來 因為HTTP 通信是half-duplex，從web browser client的角度，browser可以知道什麼時候要send資料，隨時可以由browser發起http request，而recv則是由server傳來的資料，但是在http request-response的架構下，因為不知道server什麼時候有資料，最簡單的做法就是要定期去polling，這個在早期的聊天室系統都是這樣處理，每隔幾秒鐘就發一次http request更新最新的內容，但是這樣做有個缺點 – 不即時 即時性的問題在後來發展出hidden iframe以及long polling兩種做法，以兩種做法解決問題主要是因為browser的限制(browser只支援單純的http request-response)，雖然在HTTP協定中其實有定義可以做雙向通信的，像是HTTP/1.1 CONNECT(主要用在tunnel proxy情境)，或是HTTP/1.1 Upgrade header，但是tunnel或是upgrade完的通信方式要由app決定。 hidden iframe的做法算是巧妙地利用browser load javascript的行為，他透過inline iframe建立起一個隱藏的iframe，在iframe裡面load一個特別的網頁，那個網頁會一直傳<script>，將要server通知的內容即時透過<script>結合javascript，在裡面嵌code和data，因為browser收到script會立即執行，並且按順序執行，透過巧妙地安排script內容，將訊息傳出來給parent page，因為網頁還沒load完，連線就會一直持續 long polling則是透過http XMLHttpRequest方式，連上server後，在沒有新的event data情況下，server就掛起連線，等有資料再response，當client收完資料後連線結束，再馬上發起新的long polling request，這個好處是可以即時的收到event data，缺點是XMLHttpRequest browser有一些限制(例如cross origin等問題)，以及每次HTTP … Continue reading →