Author Archives: Enrico

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