不是東西的東西

Bidirectional-streams Over Synchronous HTTP (BOSH) 網址: http://www.xmpp.org/extensions/xep-0124.html 一何謂bosh? 雙向性的Http串流,利用http protocol post transport xmpp stream 二why http protocol? 一般防火牆都會允許tcp 80 prot 的對外窗口,某些少數的防火牆甚至允許任何的通訊協定通過這個port, 但是更多的proxy,filter 會確認通過的串流是否為http 三技術名詞 1pull: client use http request from server,是一種以網路為基礎的溝通方法 2 push: server response data to client,是一種以網路為基礎的溝通方法,server主動將資料傳給client 四compare other bidirectional http-base transport protocol 1http polling :週期性的詢問server是否有資料 2 ajax(Asynchronous JavaScript and XML) 3 comet :是長時間連線要求的web 應用的模式,server在有資料要傳送時透過此連線push資料至用戶端. 利用ajax with long polling or iframe or htmlfile activex 的技術去探測server是否有新的訊息 4bosh:採用多個http request / response 對,非polling,自稱可高效率低延遲的傳輸訊息及節省網路頻寬 五要求 1相容於受約束的執行環境(如行動電話或流覽器的用戶端)**. 2可以讓流覽器的用戶端建立跨網域的連接* 3相容部份緩衝的http代理回應* 4有效率的通過http回應時間限制的代理* 5完全相容http 1.0* 6相容受限的網路連線(如防火牆.代理.閘道) 7容錯性 8擴展性 9使用的頻寬遠低於輪詢機制的protocols 10回應的時間遠低於輪詢機制的protocols 11支援輪詢 1...

--- 電子發票系統 /電子發票整合方案  http://rd-program.blogspot.com/2012/03/blog-post.html --- 沒想到進度超前,在今天釋出第一個版本,只要在gmail 或是gtalk 邀請 en2zhtw@gmail.com 設定成為聯絡人,送出整段英文訊息給en2zhtw@gmail.com,機器人就會翻譯 英文-->繁體,實作過程中,最複雜的還是TLS的實作,其他並沒有太多的阻礙,另外xmpp 的訂閱聯絡人協定做的有點不是很好,連gtalk 都沒有完整實做,這在幾種不同的SERVER測過,目前最標準的是openfire,其餘或多或少都有部分不太符合rfc3921,相較於msn protocol,在做聯絡人的部份既簡單又清楚,這是xmpp美中不足之處 ps.msn開發套件 http://rd-program.blogspot.com/2008/10/msnsdk.html ps.http://blog.serv.idv.tw/2007/12/19/744/ 這是google 原始釋出的翻譯機器人,不過獨缺 英文-->繁體 , 只有英文->簡體 ps.如果有任何想法/合作,可洽sonet.all@gmail.com --- 電子發票系統 /電子發票整合方案 http://rd-program.blogspot.com/2012/03/blog-post.html ---

目前正在進行gtalk 的機器人實作,我想把google的(英翻中)翻譯做在gtalk 上,這當然不是什麼新鮮的事,而且目前google 已經釋出相關的功能,不過;獨缺英文->繁體中文,沒錯! 我就是想做世界第一個英翻中(繁體)的機器人,事實上我只是想展示公司在xmpp 上的應用能夠做到什麼程度,如果我們撇開rfid middle 的xmpp server應用,這應該是我第一次在gtalk 上做相關應用 目前;已經突破gtalk 使用TLS 的認證部份,整個工作大概完成了40%,希望能夠在這個星期前釋出第一個版本

Xmpp Rfc3920 10-~15章 研討會報告 10. 伺服器處理XML節的規則 (Server Rules for Handling XML Stanzas) 相容的伺服器實做必須（MUST）確保兩個實體之間的XML節按次序處理. 除了按次序處理的需求之外, 每個伺服器實作將包含它自己的遞送樹"delivery tree"以處理它接收到的節.這個樹決定一個節是否需要路由到其他域, 在內部處理, 還是遞送到和一個已連接的節點相關的資源. 以下規則適用: ________________________________________ 10.1. 沒有'to'地址 (No 'to' Address) 如果這個節沒有'to'屬性, 伺服器應該(SHOULD)為發送它的實體處理這個節. 因為所有從其他伺服器收到的節必須(MUST)擁有'to'屬性, 這個規則僅適用於從一個連接到這台伺服器的已註冊實體(如一個用戶端)收到的節,如果這個伺服器收到一個沒有'to'屬性的出席資訊節, 伺服器應該(SHOULD)向那些訂閱了這個發送實體的出席資訊的所有實體廣播它, 如果可能的話(即時消息和出席資訊應用程式中出席資訊廣播的語義定義在XMPP-IM). 如果伺服器接收到一個IQ類型為 "get" 或 "set" 且沒有'to'屬性的節並且它理解這個節的名字空間下的內容, 它必須(MUST)為這個發送實體處理節(在這裏"處理"的含義是由相關的名字空間的語義所決定的)或返回一個錯誤給發送實體. #c to s 可以不用有 to 屬性 ,因為c to s 預設的 to 即是 server #若是出席訊息＜presence＞沒有to屬性,即為廣播給所有訂閱者,rfc3921第五章說明如下: (5.1.1初始化出席資訊 : 建立起一個會話之後, 一個用戶端應該(SHOULD)發送初始化出席資訊給伺服器來通知它的通信可用性.如這裏定義的, 初始化出席資訊節 (1) 必須(MUST) 不擁有'to'屬性(這表示它是由伺服器代替用戶端發送的廣播) 並且 (2) 必須(MUST) 不擁有'type...

1. 繼續分享xmpp的討會 3.5 地址的確認 在SASL(見第六章)握手之後(如果必要的話,也在資料綁定(見第七章)之後,正在接收信息的實體必須(MUST)確認初始實體的ID 對於服務器間的通信,在SASL握手時,如果沒有指明授權的ID,這個初始的實體應該(SHOULD)是經過認證實體(參見簡單認證和安全層協議[SASL]中的定義)授權的ID(見第六章) 對於客戶端和服務器的通信, 在SASL握手時, 如果沒有指明授權的ID, “純JID” (＜node@domain＞)應該(SHOULD)是經過認證實體(參見[SASL]中的定義)授權的ID, “全JID”(＜node@domain/resource＞)的資源ID部份應該(SHOULD)是由客戶端和服務器在資源綁定的時候商定的(參見第七章) 4.1 XML流 / XML節概覽 XML流(XML Stream)的定義: 一個XML流乃是一個容器, 包含了2個實體之間通過網絡交換XML元素, 一個XML流乃由一個＜stream＞標籤開始的(該標籤需包含適當的屬性及名字空間聲明), XML流的結束則是由＜/stream＞標籤做為結束, 在XML流的整個生命週期中, 初始化它的實體可以通過流來發送大量的XML元素, 例如:TLS協議(第5章),SASL協議(第6章)或XML節(在這裡指的是符合預設名字空間的元素, 包括＜message/＞,＜presence/＞,＜iq/＞元素), “初始的XML流"由初始實體(通常是一個客戶端或服務器)和接收實體(通常為一個服務器)協議, 從接收實體來看, XML流就是那個初始實體對接收實體的 “會話”, 接收實體則必需回覆一個相同的應答流給初始實體 Ex: ＜stream＞ è xml流開始 ………………………………. ………………………………. ＜/stream＞ è xml流結束 XML節(XML Stanzas)的定義 : 一個XML節是一個實體通過XML流向另一個實體發送結構化信息中的一個離散語意單位, 一個XML節乃直接存於根元素＜stream/＞之下, 也就是說任何XML都是從一個XML流的下一級的某個OPEN標籤(如: ＜presence＞)開始的, 並相對應到其CLOSE標籤(如: ＜/presence＞)做為結束, 一個XML節可以包含子元素(例如: 屬...

XMPP協定導讀 一. 什麼是jabber? 什麼是xmpp? The Extensible Messaging and Presence Protocol (XMPP) is an open Extensible Markup Language XML [XML] protocol for near-real-time messaging, presence, and request-response services. The basic syntax and semantics were developed originally within the Jabber open-source community, mainly in 1999. In 2002, the XMPP WG was chartered with developing an adaptation of the Jabber protocol that would be suitable as an IETF instant messaging (IM) and presence technology. As a result of work by the XMPP WG, the current memo defines the core features of XMPP 1.0; the extensions required to provide the instant messaging and presence functionality defined in RFC 2779 [IMP REQS] are specified in Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence [XMPP IM]. 二. Socket/XMPP 程式需注意的幾個重點 1.架構(select poll epoll AIO kqueue IOCP / Thread / Process / LWP) 2.setsockopt比較值得討論的參數 setsockopt( $listen,SOL_SOCKET,SO_REUSEADDR,1); 伺服端 setsockopt( $sockfd...

http://wiki.jabbercn.org/space/start 另一個不錯的相關網站 http://hi.baidu.com/jabber/blog/category/Jep iq:roster 的交易過程真是複雜的可以 http://64.233.179.104/translate_c?hl=zh-TW&sl=zh-CN&u=http://www.linuxboy.net/jabber/004.html&prev=/search%3Fq%3Diq:roster%26complete%3D1%26hl%3Dzh-TW%26pwst%3D1

最近在寫jabber server, jabber 是建構在xmpp protocol 上的一個IM,因為RFC的規格制定曠日費時,所以;jabber 以xmpp 為基礎,自己又定義了約200 個協定XEP-0001~0214,而 xmpp 主要由五個protocol所組成,分別是RFC-3920~3923 RFC-4622 我目前的進度已經可以讓像 Exodus or Pandion(IM Client) 連接上我自己實做的jabber server,預計下星期我就能讓im client 直接在上面talk,且訂閱彼此的狀態...在寫的過程成中越來越覺得他的複雜,其實,這大概是我目前寫過最複雜的伺服器,不過有一點心得可以先分享給大家,其實有一些人有一個疑問,jabber長的像什麼? 如果我們撇開他在IM的實做(處理訊息的傳遞也是一種運算資源),我們可以把它看成是一家公司,一家公司會有他對客戶的服務,而當產品要製作時,它需要資源,需要應徵人員,每個應徵的人員需要依照公司的制度來運行(component plug-in),每個人員應徵後需要報到,然後正式工作,依照給個人的專業知識分派工作 ....循環不已,當新的產品要製作時,這個公司可以再應徵新的 不同專業領域的資源,而且可以重新制定新的工作規則...而公司組織裡的這些運行其實都是靠制度,而這個制度相對於jabber 就是他的protocol,所以我把xmpp形容成是一個資源/運算的分散者,因此他可以建構一個基本的Grid Computing 環境,把每個運算工作分散到無限台機器上....如果你要問他可以做什麼? 事實上在jabber 的protocol 裡幾乎定義了絕大部分 的應用,voip 影音...,所有的運算資源都可以在事後 plug in 進去,google_talk 所實做的部份可能還不到整個jabber 的1/20,由此;我們可以看出他的規模/擴充性之大... 總之把他想成是一個有組織的公司,只是公司的規模有大有小罷了,xmpp 的工作資源分配真的跟這個描述很像,有機會自己實做一次體會一下囉!

http://article.pchome.net/140922.html http://info.china.alibaba.com/news/detail/v5000441-d5976713.html http://www.microsoft.com/presspass/features/2002/nov02/11-17SPOT.mspx http://www.msndirect.com/ 思考一下jabber能做什麼? 或許比想像中的更多

Jeremie Miller於1998年開始了這個項目。第一個公開版本於2000年5月發行。這個項目的主要產品是jabberd，Jabber的伺服器端軟體。它既可以創建私人的Jabber網路，也可以加入全球的公共Jabber網路。Jabber的關鍵特色是，分散式的即時通訊系統，以及使用XML串流。 Jabber協定目前由Jabber軟體基金會管理，而Jabber協定的主要基礎已經在RFC3920當中以XMPP之名被網際網路工程工作小組（IETF）接受為網際網路標準。Jabber和以SIP協定為基礎的SIMPLE常被視為為即時通訊及Presence告知領域的競爭對手，然而XMPP的設計更傾向提供一個一般用途的、應用程式之間的中介軟體設施。 2005年，Google發佈了Google Talk，這是一個IP電話及即時通訊的服務，即時通訊功能採用了開放的Jabber/XMPP。預計這將對Jabber社區起很大的推動作用。初期此服務不支援伺服器到伺服器的通訊功能，所以未能完全發揮Jabber的分散式特色。2006年1月17日起，伺服器到伺服器的通訊啟用了，Google Talk用戶可與其他Jabber公共網路的用戶對談。

最近在思考 message center 所使用的 jabber server要自己寫還是用現成 的server,自己寫不是不可能只是可能要花的時間可能會比較久,於是參考了 ejabberd 他的網站提到 ejabberd is a free and open source instant messaging server written in Erlang. 從來沒聽過語言,查了一下 Erlang is a programming language designed at the Ericsson Computer Science Laboratory. Open-source Erlang is being released to help encourage the spread of Erlang outside Ericsson. 看來是一種非oo 非程序 的functional programming language,有點類似 Haskell,最有趣的是他是跨平台的語言,而讓我驚奇佩服的是,ejabberd 居然可 以把功能做的這麼完善,真是高手中的高手