October 2024 S M T W T F S « Jan 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 -
Recent Posts
Recent Comments
Categories
Links
Category Archives: Network
json-rpc整理(JSON remote procedure call)
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
Posted in Network
Leave a comment
xml-rpc整理 (XML remote procedure call) – spec
這篇整理的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
Posted in Network
Leave a comment
xml-rpc整理 (XML remote procedure call) – introduction
在跨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
Posted in Network
Leave a comment
WebSocket protocol整理
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