項(xiàng)目中需要用到openfire的文件傳輸,但是客戶端使用flex,官方提供的xiff包中并沒有封裝文件傳輸?shù)墓δ埽瑳]辦法,研究了幾天,在google和官方smock源碼的幫助下終于實(shí)現(xiàn)了xiff下的文件傳輸,在這里做個(gè)總結(jié)。
openfire服務(wù)器是基于xmpp協(xié)議的,XMPP支持兩種文件流傳輸協(xié)議,SOCKS5 Bytestreams和 In-Band Bytestreams,SOCKS5是直接發(fā)送二進(jìn)制流,而IBB是將文件轉(zhuǎn)成base64碼進(jìn)行然后用message的形式進(jìn)行傳輸,我這里僅實(shí)現(xiàn)了SOCKS5的文件代理傳輸。
SOCKS5文件傳輸需要用到兩個(gè)協(xié)議,XEP-0065和XEP-0096
XEP-0096定義文件傳輸協(xié)議,提供了一個(gè)模塊化框架使能交換被傳輸文件的信息以及參數(shù)的協(xié)商,也就是在傳輸文件之前協(xié)商將要傳輸?shù)奈募畔ⅰ?br />XEP-0065定義SOCKS5流傳輸標(biāo)準(zhǔn)協(xié)議,提供用于在任意兩個(gè)XMPP用戶之間建立字節(jié)流并進(jìn)行文件傳輸。
根據(jù)我的理解,文件傳輸?shù)倪^程分為協(xié)商,建立socks5連接,二進(jìn)制傳輸這三個(gè)階段
協(xié)商的過程最復(fù)雜,然后是建立連接,傳輸就比較簡(jiǎn)單,下面一個(gè)一個(gè)來講
協(xié)商包括初始方、目標(biāo)方、代理方,初始方就是發(fā)送文件方,目標(biāo)方即文件接收方,代理方是socks5代理服務(wù)器,
協(xié)商過程就是三方互相發(fā)送xml來交換信息的過程,通俗點(diǎn)就是三個(gè)人溝通一下傳什么文件和怎么傳文件。
首先遵循XMP-0096協(xié)議,初始方給目標(biāo)方發(fā)送包含文件信息的xml
<iq to="android@192.168.1.113/Spark 2.6.3" type="set" id="iq_13" from="iphone@192.168.1.113/xiff">
<si profile="http://jabber.org/protocol/si/profile/file-transfer" mime-type="text/plain" id="82B0C697-C1DE-93F9-103E-481C8E7A3BD8" xmlns="http://jabber.org/protocol/si">
<feature xmlns="http://jabber.org/protocol/feature-neg">
<x xmlns="jabber:x:data" type="form">
<field var="stream-method" type="list-single">
<option><value>http://jabber.org/protocol/bytestreams</value></option>
<option><value>http://jabber.org/protocol/ibb</value></option>
</field>
</x>
</feature>
<file xmlns="http://jabber.org/protocol/si/profile/file-transfer" name="img0545.png" size="152443"><desc>send</desc></file>
</si>
</iq>
目標(biāo)方接收到信息后發(fā)送回執(zhí),表示同意接收文件
這時(shí)進(jìn)入XEP-0065協(xié)議階段
初始方給服務(wù)器發(fā)送信息,請(qǐng)求提供代理服務(wù)器
服務(wù)器回復(fù)信息,告知可用的代理
這里選擇name=“Socks 5 Bytestreams Proxy”的代理,初始方給這個(gè)代理發(fā)送信息獲取代理連接信息
代理方回復(fù)信息,告知初始方代理的jid、IP、端口等信息
初始方收到代理信息后將代理的信息發(fā)送給目標(biāo)方
然后就進(jìn)入連接階段,也就是初始方和目標(biāo)方分別和代理建立socks5連接的過程。(關(guān)于SOCKS5協(xié)議連接,我之后會(huì)補(bǔ)充)。
目標(biāo)方收到代理信息后和代理建立socket連接(使用SOCKS5協(xié)議連接),連接成功后通知初始方使用的代理jid
初始方開始與代理建立socket連接(也使用SOCKS5協(xié)議),連接成功后給代理發(fā)送請(qǐng)求,要求激活文件流
代理回復(fù)激活成功信息
初始方收到回復(fù)信息后就進(jìn)入二進(jìn)制流傳輸階段,這時(shí)就可以開始發(fā)送二進(jìn)制流了
等初始方將流發(fā)送完畢后把socket流關(guān)閉傳輸就完成了文件的傳輸。
注意:type為result的回復(fù)信息使用的id一定要和請(qǐng)求的信息id一樣。
struts2使用FilterDispatcher進(jìn)行url過濾,默認(rèn)是所有的url都過濾,但是項(xiàng)目中有些url是不想用struts2進(jìn)行過濾的,網(wǎng)上搜了不少方法
1.修改web.xml文件。
<filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern>*.action</url-pattern>
</filter-mapping>
只讓過濾器對(duì)加有.action后綴的路徑有效,如果需要攔截.jsp,加上*.jsp就行了。
但是這樣如果有無后綴名的url(如/demo/)就不能過濾了
2.修改struts2核心jar中的default.properties文件
把struts.action.extension=action,,
改為struts.action.extension=action,do,jsp,
但我改了之后發(fā)現(xiàn)根本沒效果,不知為何
3.自定義一個(gè)繼承StrutsPrepareAndExecuteFilter的過濾器,將配置換成自己自定義的過濾器。(推薦此法)
修改web.xml
這種方法試驗(yàn)成功
Hibernate在進(jìn)行數(shù)據(jù)讀取時(shí)會(huì)先在緩存里找,緩存中不存在時(shí)再去數(shù)據(jù)庫(kù)查詢,合理使用hibernate緩存能夠有效的利用內(nèi)存,減少物理數(shù)據(jù)庫(kù)調(diào)用的次數(shù).
ORM緩存策略
1.事務(wù)級(jí)緩存(session level cache)
session生命周期的緩存,關(guān)閉session即消亡
2.應(yīng)用級(jí)/進(jìn)程級(jí)緩存(sessionFactory level cache)
某個(gè)應(yīng)用中的共享緩存,多個(gè)事務(wù)可以共享,在sessionFactory層實(shí)現(xiàn),所有sessionFactory創(chuàng)建的session可以共享.
3.分布式緩存
多個(gè)JVM共享的緩存,通過遠(yuǎn)程機(jī)制實(shí)現(xiàn)緩存數(shù)據(jù)同步,任意實(shí)例修改數(shù)據(jù),所有的JVM都要更新緩存.
Hibernate數(shù)據(jù)緩存
1.內(nèi)部緩存(session level)一級(jí)緩存
是事務(wù)級(jí)的緩存,session中維護(hù)的一個(gè)Map,Map的key是包含了數(shù)據(jù)類型和id,從數(shù)據(jù)庫(kù)加載的數(shù)據(jù)都會(huì)進(jìn)入Map緩存中,通過session加載數(shù)據(jù)時(shí)會(huì)先在session緩存里找,一級(jí)緩存是session的private數(shù)據(jù),session實(shí)例消亡就清除了,在應(yīng)用中就保持在一次請(qǐng)求的開始和結(jié)束之間.
一般由Hibernate自動(dòng)維護(hù),也支持手動(dòng)維護(hù)
session.evit(Object obj) 將持久化對(duì)象從一級(jí)緩存中清除.
session.clear() 清空一級(jí)緩存
session.contains(Object obj) 判斷指定的對(duì)象是否存在于一級(jí)緩存中.
session.flush() 刷新一級(jí)緩存區(qū)的內(nèi)容,使緩存與數(shù)據(jù)庫(kù)數(shù)據(jù)保持同步.
2.二級(jí)緩存(sessionFactory level)
包含了應(yīng)用級(jí)和分布式的緩存,由本sessionFactory的所有session實(shí)例共享,session操作時(shí)會(huì)先查一級(jí)緩存,然后查二級(jí)緩存,最后再查物理數(shù)據(jù)庫(kù).要使用二級(jí)緩存必須要進(jìn)行配置.
適合用緩存的數(shù)據(jù)
1.不會(huì)被其他應(yīng)用修改
包括直接用JDBC修改等,因?yàn)槠渌麘?yīng)用修改了數(shù)據(jù)之后hibernate并不知道,不能自動(dòng)更新緩存,不過可以手動(dòng)更新緩存
2.數(shù)據(jù)大小可以接受,畢竟內(nèi)存資源也不多
3.數(shù)據(jù)更新頻率低(比如數(shù)據(jù)字典等常量數(shù)據(jù))
4.可能被系統(tǒng)頻繁使用
5.非關(guān)鍵的數(shù)據(jù)
6.不會(huì)被并發(fā)訪問的數(shù)據(jù)
常用的二級(jí)緩存插件
EHCache org.hibernate.cache.EhCacheProvider
OSCache org.hibernate.cache.OSCacheProvider
SwarmCahe org.hibernate.cache.SwarmCacheProvider 提供了分布式
JBossCache org.hibernate.cache.TreeCacheProvider 提供了分布式
EHCache二級(jí)緩存配置方法
1.啟用二級(jí)緩存首先要在hibernate.cfg.xml配置
<hibernate-configuration>
<session-factory>
<!-- 配置二級(jí)緩存插件EHCache的Provider類-->
<property name="hibernate.cache.provider_class">
org.hibernate.cache.EhCacheProvider
</property>
<!-- 啟動(dòng)"查詢緩存" -->
<property name="hibernate.cache.use_query_cache">
true
</property>
</session-factory>
</hibernate-configuration>
2.然后配置cache的配置文件ehcache.xml
<ehcache>
<!-- maxElementsInMemory為緩存對(duì)象的最大數(shù)目,
eternal設(shè)置是否永遠(yuǎn)不過期,
timeToIdleSeconds對(duì)象處于空閑狀態(tài)的最多秒數(shù),
timeToLiveSeconds對(duì)象處于緩存狀態(tài)的最多秒數(shù),
overflowtodisk內(nèi)存不足時(shí)是否啟用磁盤緩存 -->
<diskStore path="java.io.tmpdir"/>
<defaultCache maxElementsInMemory="10000" eternal="false" timeToIdleSeconds="300" timeToLiveSeconds="600" overflowToDisk="true"/>
</ehcache>
3.最后要在映射文件***.hbm.xml中指定實(shí)體的緩存同步策略
<?xml version="1.0" encoding='UTF-8'?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd" >
<hibernate-mapping>
<class>
<!-- 設(shè)置該持久化類的二級(jí)緩存并發(fā)訪問策略-->
<cache usage="read-write"/>
<set name = "xxx">
<cache usage="read-only" />
</set>
</class>
</hibernate-mapping>
hibernate提供的緩存同步策略,可以在usage中設(shè)置
read-only
只讀
nonstrict-read-write
更新頻率不高
read-write
嚴(yán)格可讀寫
transactional(Ecache不支持)
事務(wù)型緩存