作為一個(gè)軟件開(kāi)發(fā)者,你一定會(huì)對(duì)網(wǎng)絡(luò)應(yīng)用如何工作有一個(gè)完整的層次化的認(rèn)知,同樣這里也包括這些應(yīng)用所用到的技術(shù):像瀏覽器,HTTP,HTML,網(wǎng)絡(luò)服務(wù)器,需求處理等等。
本文將更深入的研究當(dāng)你輸入一個(gè)網(wǎng)址的時(shí)候,后臺(tái)到底發(fā)生了一件件什么樣的事~
導(dǎo)航的第一步是通過(guò)訪問(wèn)的域名找出其IP地址。DNS查找過(guò)程如下:
DNS遞歸查找如下圖所示:
DNS有一點(diǎn)令人擔(dān)憂,這就是像wikipedia.org 或者 facebook.com這樣的整個(gè)域名看上去只是對(duì)應(yīng)一個(gè)單獨(dú)的IP地址。還好,有幾種方法可以消除這個(gè)瓶頸:
大多數(shù)DNS服務(wù)器使用Anycast來(lái)獲得高效低延遲的DNS查找。
因?yàn)橄馞acebook主頁(yè)這樣的動(dòng)態(tài)頁(yè)面,打開(kāi)后在瀏覽器緩存中很快甚至馬上就會(huì)過(guò)期,毫無(wú)疑問(wèn)他們不能從中讀取。
所以,瀏覽器將把一下請(qǐng)求發(fā)送到Facebook所在的服務(wù)器:
GET http://facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: facebook.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]
GET 這個(gè)請(qǐng)求定義了要讀取的URL: “http://facebook.com/”。 瀏覽器自身定義 (User-Agent 頭), 和它希望接受什么類型的響應(yīng) (Accept and Accept-Encoding 頭). Connection頭要求服務(wù)器為了后邊的請(qǐng)求不要關(guān)閉TCP連接。
請(qǐng)求中也包含瀏覽器存儲(chǔ)的該域名的cookies。可能你已經(jīng)知道,在不同頁(yè)面請(qǐng)求當(dāng)中,cookies是與跟蹤一個(gè)網(wǎng)站狀態(tài)相匹配的鍵值。這樣cookies會(huì)存儲(chǔ)登錄用戶名,服務(wù)器分配的密碼和一些用戶設(shè)置等。Cookies會(huì)以文本文檔形式存儲(chǔ)在客戶機(jī)里,每次請(qǐng)求時(shí)發(fā)送給服務(wù)器。
用來(lái)看原始HTTP請(qǐng)求及其相應(yīng)的工具很多。作者比較喜歡使用fiddler,當(dāng)然也有像FireBug這樣其他的工具。這些軟件在網(wǎng)站優(yōu)化時(shí)會(huì)幫上很大忙。
圖中所示為Facebook服務(wù)器發(fā)回給瀏覽器的響應(yīng):
HTTP/1.1 301 Moved Permanently
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Location: http://www.facebook.com/
P3P: CP="DSP LAW"
Pragma: no-cache
Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
path=/; domain=.facebook.com; httponly
Content-Type: text/html; charset=utf-8
X-Cnection: close
Date: Fri, 12 Feb 2010 05:09:51 GMT
Content-Length: 0
服務(wù)器給瀏覽器響應(yīng)一個(gè)301永久重定向響應(yīng),這樣瀏覽器就會(huì)訪問(wèn)“http://www.facebook.com/” 而非“http://facebook.com/”。
為什么服務(wù)器一定要重定向而不是直接發(fā)會(huì)用戶想看的網(wǎng)頁(yè)內(nèi)容呢?這個(gè)問(wèn)題有好多有意思的答案。
其中一個(gè)原因跟搜索引擎排名有關(guān)。你看,如果一個(gè)頁(yè)面有兩個(gè)地址,就像http://www.litfresh.com/ 和http://litfresh.com/,搜索引擎會(huì)認(rèn)為它們是兩個(gè)網(wǎng)站,結(jié)果造成每一個(gè)的搜索鏈接都減少?gòu)亩档团琶6阉饕嬷?01永久重定向是什么意思,這樣就會(huì)把訪問(wèn)帶www的和不帶www的地址歸到同一個(gè)網(wǎng)站排名下。
還有一個(gè)是用不同的地址會(huì)造成緩存友好性變差。當(dāng)一個(gè)頁(yè)面有好幾個(gè)名字時(shí),它可能會(huì)在緩存里出現(xiàn)好幾次。
現(xiàn)在,瀏覽器知道了“http://www.facebook.com/”才是要訪問(wèn)的正確地址,所以它會(huì)發(fā)送另一個(gè)獲取請(qǐng)求:
GET http://www.facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]
Host: www.facebook.com
頭信息以之前請(qǐng)求中的意義相同。
服務(wù)器接收到獲取請(qǐng)求,然后處理并返回一個(gè)響應(yīng)。
這表面上看起來(lái)是一個(gè)順向的任務(wù),但其實(shí)這中間發(fā)生了很多有意思的東西- 就像作者博客這樣簡(jiǎn)單的網(wǎng)站,何況像facebook那樣訪問(wèn)量大的網(wǎng)站呢!
舉個(gè)最簡(jiǎn)單的例子,需求處理可以以映射網(wǎng)站地址結(jié)構(gòu)的文件層次存儲(chǔ)。像http://example.com/folder1/page1.aspx這個(gè)地址會(huì)映射/httpdocs/folder1/page1.aspx這個(gè)文件。web服務(wù)器軟件可以設(shè)置成為地址人工的對(duì)應(yīng)請(qǐng)求處理,這樣page1.aspx的發(fā)布地址就可以是http://example.com/folder1/page1。
所有動(dòng)態(tài)網(wǎng)站都面臨一個(gè)有意思的難點(diǎn) - 如何存儲(chǔ)數(shù)據(jù)。小網(wǎng)站一半都會(huì)有一個(gè)SQL數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)數(shù)據(jù),存儲(chǔ)大量數(shù)據(jù)和/或訪問(wèn)量大的網(wǎng)站不得不找一些辦法把數(shù)據(jù)庫(kù)分配到多臺(tái)機(jī)器上。解決方案有:sharding (基于主鍵值將數(shù)據(jù)表分散到多個(gè)數(shù)據(jù)庫(kù)中),復(fù)制,利用弱語(yǔ)義一致性的簡(jiǎn)化數(shù)據(jù)庫(kù)。
委托工作給批處理是一個(gè)廉價(jià)保持?jǐn)?shù)據(jù)更新的技術(shù)。舉例來(lái)講,F(xiàn)ackbook得及時(shí)更新新聞feed,但數(shù)據(jù)支持下的“你可能認(rèn)識(shí)的人”功能只需要每晚更新(作者猜測(cè)是這樣的,改功能如何完善不得而知)。批處理作業(yè)更新會(huì)導(dǎo)致一些不太重要的數(shù)據(jù)陳舊,但能使數(shù)據(jù)更新工作更快更簡(jiǎn)潔。
圖中為服務(wù)器生成并返回的響應(yīng):
HTTP/1.1 200 OK
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="DSP LAW"
Pragma: no-cache
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Cnection: close
Transfer-Encoding: chunked
Date: Fri, 12 Feb 2010 09:05:55 GMT
2b3????????T?n?@????[...]
整個(gè)響應(yīng)大小為35kB,其中大部分在整理后以blob類型傳輸。
內(nèi)容編碼頭告訴瀏覽器整個(gè)響應(yīng)體用gzip算法進(jìn)行壓縮。解壓blob塊后,你可以看到如下期望的HTML:
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
lang="en" id="facebook" class=" no_js">
...
關(guān)于壓縮,頭信息說(shuō)明了是否緩存這個(gè)頁(yè)面,如果緩存的話如何去做,有什么cookies要去設(shè)置(前面這個(gè)響應(yīng)里沒(méi)有這點(diǎn))和隱私信息等等。
請(qǐng)注意報(bào)頭中把Content-type設(shè)置為“text/html”。報(bào)頭讓瀏覽器將該響應(yīng)內(nèi)容以HTML形式呈現(xiàn),而不是以文件形式下載它。瀏覽器會(huì)根據(jù)報(bào)頭信息決定如何解釋該響應(yīng),不過(guò)同時(shí)也會(huì)考慮像URL擴(kuò)展內(nèi)容等其他因素。
在瀏覽器沒(méi)有完整接受全部HTML文檔時(shí),它就已經(jīng)開(kāi)始顯示這個(gè)頁(yè)面了:
在瀏覽器顯示HTML時(shí),它會(huì)注意到需要獲取其他地址內(nèi)容的標(biāo)簽。這時(shí),瀏覽器會(huì)發(fā)送一個(gè)獲取請(qǐng)求來(lái)重新獲得這些文件。
下面是幾個(gè)我們?cè)L問(wèn)facebook.com時(shí)需要重獲取的幾個(gè)URL:
這些地址都要經(jīng)歷一個(gè)和HTML讀取類似的過(guò)程。所以瀏覽器會(huì)在DNS中查找這些域名,發(fā)送請(qǐng)求,重定向等等...
但不像動(dòng)態(tài)頁(yè)面那樣,靜態(tài)文件會(huì)允許瀏覽器對(duì)其進(jìn)行緩存。有的文件可能會(huì)不需要與服務(wù)器通訊,而從緩存中直接讀取。服務(wù)器的響應(yīng)中包含了靜態(tài)文件保存的期限信息,所以瀏覽器知道要把它們緩存多長(zhǎng)時(shí)間。還有,每個(gè)響應(yīng)都可能包含像版本號(hào)一樣工作的ETag頭(被請(qǐng)求變量的實(shí)體值),如果瀏覽器觀察到文件的版本ETag信息已經(jīng)存在,就馬上停止這個(gè)文件的傳輸。
試著猜猜看“fbcdn.net”在地址中代表什么?聰明的答案是"Facebook內(nèi)容分發(fā)網(wǎng)絡(luò)"。Facebook利用內(nèi)容分發(fā)網(wǎng)絡(luò)(CDN)分發(fā)像圖片,CSS表和JavaScript文件這些靜態(tài)文件。所以,這些文件會(huì)在全球很多CDN的數(shù)據(jù)中心中留下備份。
靜態(tài)內(nèi)容往往代表站點(diǎn)的帶寬大小,也能通過(guò)CDN輕松的復(fù)制。通常網(wǎng)站會(huì)使用第三方的CDN。例如,F(xiàn)acebook的靜態(tài)文件由最大的CDN提供商Akamai來(lái)托管。
舉例來(lái)講,當(dāng)你試著ping static.ak.fbcdn.net 的時(shí)候,可能會(huì)從某個(gè)akamai.net服務(wù)器上獲得響應(yīng)。有意思的是,當(dāng)你同樣再ping一次的時(shí)候,響應(yīng)的服務(wù)器可能就不一樣,這說(shuō)明幕后的負(fù)載平衡開(kāi)始起作用了。
在Web 2.0偉大精神的指引下,頁(yè)面顯示完成后客戶端仍與服務(wù)器端保持著聯(lián)系。
以Facebook聊天功能為例,它會(huì)持續(xù)與服務(wù)器保持聯(lián)系來(lái)及時(shí)更新你那些亮亮灰灰的好友狀態(tài)。為了更新這些頭像亮著的好友狀態(tài),在瀏覽器中執(zhí)行的JavaScript代碼會(huì)給服務(wù)器發(fā)送異步請(qǐng)求。這個(gè)異步請(qǐng)求發(fā)送給特定的地址,它是一個(gè)按照程式構(gòu)造的獲取或發(fā)送請(qǐng)求。還是在Facebook這個(gè)例子中,客戶端發(fā)送給http://www.facebook.com/ajax/chat/buddy_list.php一個(gè)發(fā)布請(qǐng)求來(lái)獲取你好友里哪個(gè)在線的狀態(tài)信息。
提起這個(gè)模式,就必須要講講"AJAX"-- “異步JavaScript 和 XML”,雖然服務(wù)器為什么用XML格式來(lái)進(jìn)行響應(yīng)也沒(méi)有個(gè)一清二白的原因。再舉個(gè)例子吧,對(duì)于異步請(qǐng)求,F(xiàn)acebook會(huì)返回一些JavaScript的代碼片段。
除了其他,fiddler這個(gè)工具能夠讓你看到瀏覽器發(fā)送的異步請(qǐng)求。事實(shí)上,你不僅可以被動(dòng)的做為這些請(qǐng)求的看客,還能主動(dòng)出擊修改和重新發(fā)送它們。AJAX請(qǐng)求這么容易被蒙,可著實(shí)讓那些計(jì)分的在線游戲開(kāi)發(fā)者們郁悶的了。(當(dāng)然,可別那樣騙人家~)
Facebook聊天功能提供了關(guān)于AJAX一個(gè)有意思的問(wèn)題案例:把數(shù)據(jù)從服務(wù)器端推送到客戶端。因?yàn)镠TTP是一個(gè)請(qǐng)求-響應(yīng)協(xié)議,所以聊天服務(wù)器不能把新消息發(fā)給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下服務(wù)器端看自己有沒(méi)有新消息。
這些情況發(fā)生時(shí)長(zhǎng)輪詢是個(gè)減輕服務(wù)器負(fù)載挺有趣的技術(shù)。如果當(dāng)被輪詢時(shí)服務(wù)器沒(méi)有新消息,它就不理這個(gè)客戶端。而當(dāng)尚未超時(shí)的情況下收到了該客戶的新消息,服務(wù)器就會(huì)找到未完成的請(qǐng)求,把新消息做為響應(yīng)返回給客戶端。
希望看了本文,你能明白不同的網(wǎng)絡(luò)模塊是如何協(xié)同工作的。
修改了一些錯(cuò)字,之前不仔細(xì),請(qǐng)大家見(jiàn)諒~
當(dāng)圖片很多的時(shí)候,減少圖片大小是提高下載速度最直接的方法。
1. 使用PNG8代替GIF(非動(dòng)畫圖片),因?yàn)镻NG8在效果一樣的情況,圖片大小比GIF要小。
2. 用fireworks處理PNG圖片,在我們產(chǎn)品中很多PNG圖片是美工直接用photoshop導(dǎo)出的,
后來(lái)讓美工用fireworks處理PNG(大概的方式是選擇保存為PNG8,刪除背景色)。
處理后100K的圖片大小基本減少了3/4,但圖片質(zhì)量也會(huì)有少許降低,要看自己是否能接受。
3. 使用Smush.it(http://www.smushit.com/ysmush.it/)壓縮圖片,Smush.it是YUI團(tuán)隊(duì)做1個(gè)在線壓縮圖片的網(wǎng)站,
該網(wǎng)站在不影響原圖片的質(zhì)量下去掉圖片中一些元數(shù)據(jù),所以可以放心使用該網(wǎng)站進(jìn)行壓縮,
但這個(gè)壓縮比例也是比較有限的。
1. CSS Sprites合并圖片以減少請(qǐng)求數(shù)來(lái)提高性能大家都知道。但不要把圖片合并太多,太多太大了,
就會(huì)因?yàn)檫@1個(gè)圖片影響這個(gè)頁(yè)面的顯示了。
2. 有時(shí)候我們需要把1個(gè)大圖片拆分成多個(gè)小圖片,比如產(chǎn)品首頁(yè)圖片比較少,就1個(gè)很大的banner圖片,
因?yàn)g覽器都可以并發(fā)下載圖片,所以如果不拆分,只使用1個(gè)大圖片的話,下載速度反而會(huì)比較慢
IE6不能顯示透明的PNG圖片,是很多開(kāi)發(fā)人員特別頭疼的事,分別介紹下幾種方式的優(yōu)缺點(diǎn)。
1.使用AlphaImageLoader,IE6支持filter,使用下面的CSS代碼,可以讓IE6支持PNG
#some-element {
background: url(image.png);
_background: none;
_filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='image.png', sizingMethod='crop');
}
優(yōu)點(diǎn):使用簡(jiǎn)單
缺點(diǎn):性能損耗很大,AlphaImageLoader會(huì)花費(fèi)很多資源去處理透明圖片,使用AlphaImageLoader,IE使用內(nèi)存會(huì)迅速上升。
而且AlphaImageLoader所有處理都在同1個(gè)線程中同步進(jìn)行,所以當(dāng)AlphaImageLoader多的時(shí)候,會(huì)阻塞UI的渲染。
使用_filter,IE7也可以識(shí)別,其實(shí)IE7是可以識(shí)別PNG透明圖片的,如果在IE7下使用上面代碼,IE7不會(huì)直接使用圖片,而是使用AlphaImageLoader。
注:個(gè)人建議盡量避免使用AlphaImageLoader
2. JS處理
使用DD_belatedPNG(http://www.dillerdesign.com/experiment/DD_belatedPNG/),可以很簡(jiǎn)單的對(duì)界面上所有的透明圖片進(jìn)行同一處理。
優(yōu)點(diǎn):使用簡(jiǎn)單(比AlphaImageLoader還簡(jiǎn)單)
缺點(diǎn):當(dāng)頁(yè)面上需要處理的圖片比較多的時(shí)候,速度也比較慢,而且不能動(dòng)態(tài)改變圖片。
3. VML
IE6支持VML,VML可以使用透明圖片,代碼如下:
修改html代碼頭部
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v>
<head>
<style type="text/css">
v\:*{behavior:url(#default#VML);}
</style>
</head>
<body>
<v:image src="image.png" />
</body>
</html>優(yōu)點(diǎn):性能好,速度快
缺點(diǎn):使用復(fù)雜,而且不支持firefox等瀏覽器,需要判斷不同的瀏覽器輸出不同的HTML代碼。
因每個(gè)瀏覽器對(duì)同1個(gè)域名同時(shí)只能發(fā)送固定的請(qǐng)求,比如IE6好像是2個(gè),所以可以對(duì)圖片資源開(kāi)通多個(gè)域名進(jìn)行請(qǐng)求,
比如img1.abc.com,img2.abc.com。但域名不要開(kāi)啟太多,因?yàn)榻馕鲇蛎痛蜷_(kāi)新的連接都需要消耗時(shí)間,域名多了,說(shuō)不定反而會(huì)更慢。一般2-4個(gè)域名就夠了。
IE6背景圖片緩存是個(gè)麻煩事,很多人知道使用下面的JS來(lái)讓IE6緩存背景圖片<!--[if IE 6]>
try{
document.execCommand("BackgroundImageCache", false, true);
}catch(e){}
但是這樣做的效果并不是非常好,當(dāng)出現(xiàn)鼠標(biāo)移動(dòng)改變背景圖片的時(shí)候,IE6老是會(huì)發(fā)送1個(gè)圖片請(qǐng)求(盡管該背景圖片已經(jīng)下載),
雖然返回結(jié)果是304,但還是要花費(fèi)不少時(shí)間。在這種情況下,可以使用下面1個(gè)變通的方式來(lái)處理,
在頁(yè)面上直接使用1個(gè)DIV元素來(lái)加載該圖片,這樣加載圖片就能真正被緩存,鼠標(biāo)移動(dòng)也不會(huì)發(fā)送請(qǐng)求了。
使用下面代碼可以在頁(yè)面加載完畢后預(yù)加載下1個(gè)頁(yè)面的圖片,當(dāng)進(jìn)入下1個(gè)頁(yè)面就不用再下載圖片了。
window.onload=function(){
var img = new Image();
img.src = "images/image.png";
img = null;
};
Description
Managing multiple webbugs is no fun. The following is an attempt to unify disparate webbugs into a single, extensible, solution.
How it works
The unified webbug snippet below replaces the need to include a separate webbug for each of analytics services you are using. Simply add the snippet below to your pages, configure your specific account settings, and you're done. This webbug will make (asynchronous) requests to each of the analytics services, without affecting page performance and simplifying the maintanance of your analytics webbug sprawl.
<script type="text/javascript"> function trackerSetup() { var tracker = new Tracker(); tracker.addTracker(new QuantcastTracker("account")); tracker.addTracker(new GoogleAnalyticsTracker("name", "UA-XXXXXXX-X")); tracker.addTracker(new ChartbeatTracker(1234, "domain")); var s_vars = { s_pageName : "pageName", s_server : "www.test.com", s_channel : "IndexPage" } tracker.addTracker(new OmnitureTracker(s_vars, "s_code.js")); tracker.trackPageview(); } (function loadJs(url, callback) { setTimeout(function() { var script = document.createElement("script") script.type = "text/javascript"; if (script.readyState){ script.onreadystatechange = function(){ if (script.readyState == "loaded" || script.readyState == "complete"){ script.onreadystatechange = null; callback(); } }; } else { script.onload = function(){ callback(); }; } script.src = url; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(script, s); },0); })("http://labs.webmetrics.com/webbug/tracker.js", trackerSetup); </script>
DISPLAY=:0.0 |
export DISPLAY=:0.0 |
Xlib: connection to ":0.0" refused by server Xlib: No protocol specified Error: Can't open display: :0.0 |
xhost + |
X11Forwarding no |
ForwardX11 yes |
DISPLAY=localhost:10.0 |
tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN 4827/1 |
exec /usr/bin/X11/X -dpi 100 -nolisten tcp |
exec /usr/bin/X11/X -dpi 100 |
ServerArgsLocal=-nolisten tcp |
ServerArgsLocal= |
DisallowTCP=false |
用命令“echo $SHELL”可以查看當(dāng)前shell是什么。
/bin/bash ------------------- Bash Shell
/bin/csh ------------------- C Shell
/bin/ksh ------------------- Kron Shell
/sbin/sh ------------------- Bourne Shell
7. 安裝后
別以為看到了install successfully 就說(shuō)明沒(méi)事了,還沒(méi)到長(zhǎng)舒一口氣的時(shí)候,還有post installation。
如果你確實(shí)已經(jīng)將shell 改成 C shell 了,后面碰到的問(wèn)題會(huì)少很多。假設(shè)當(dāng)前已經(jīng)是csh 了。
7.1
cd ~
vi .cshrc
添加一行記錄
source /var/loadrunner/env.csh #/var/loadrunner 為loadrunner安裝目錄
logoff and login。 或者開(kāi)啟另一個(gè)terminal.
7.2
cd /var/loadrunner/bin
./verify_generator # 這個(gè)utility將會(huì)檢查當(dāng)前的安裝及配置情況
極有可能會(huì)fail掉。常見(jiàn)錯(cuò)誤是:
a. 找不到.rhosts file.
b. 找不到libstdc++.so.5
c. DISPLAY 沒(méi)有設(shè)
對(duì)應(yīng)的:
a. 簡(jiǎn)單說(shuō)來(lái),.rhosts 是一個(gè)安全驗(yàn)證文件。遠(yuǎn)程機(jī)器(將來(lái)測(cè)試時(shí)的controller)將remote當(dāng)前Linux作為它的generator。將controllor hostname添加在.rhosts里面,這樣remote時(shí)Linux就會(huì)將其做為安全訪問(wèn)而不需要password。此文件應(yīng)在每個(gè)user的home下面,代表controllor以某個(gè)user 訪問(wèn)Linux server. 我們暫時(shí)可以先創(chuàng)建一個(gè)空的文件,等確定controllor之后再添加信息進(jìn)去。
cd ~
touch .rhosts
b. 這個(gè)原因是因?yàn)長(zhǎng)oadrunner 9.0 generator 使用的是 libstdc++.so.5 但當(dāng)前的版本很有可能已經(jīng)是so.6了。可以這樣查看:
cd /usr.lib
ll *libstdc++*so*
如果真的沒(méi)有,那可以到 http://rpm.pbone.net里找到后下載安裝。在UI下面安裝非常方便,雙擊就可以了。
c. 這個(gè)就是DISPLAY 這個(gè)環(huán)境變量沒(méi)有設(shè)的問(wèn)題。
setenv DISPLAY localhost:0.0
echo $DISPLAY
當(dāng)然,這里寫的都是針對(duì)csh來(lái)說(shuō)的。如果用的是K Shell 或者是 Bourne Shell, 則要麻煩一些。必須手動(dòng)的將三個(gè)變量添加到.profile里面去。我沒(méi)有試過(guò)這兩種shell, 倒是試過(guò)bash,redhat 的默認(rèn)shell。 但是怎么都沒(méi)法通過(guò)verify_generator的驗(yàn)證,總說(shuō)M_LROOT 有問(wèn)題,至今不明是不是本來(lái)就不支持bash.
**********************
M_LROOT={replace w/ LR Linux installation path} ; export M_LROOT
LD_LIBRARY_PATH=${M_LROOT}/bin; export LD_LIBRARY_PATH
PATH=${M_LROOT}/bin:${PATH}; export PATH
**********************
寫到這里還沒(méi)有完。還記得之前提過(guò)的.rhosts嗎,那個(gè)實(shí)際上是給rsh (remote shell) 用的。要真正確保這個(gè)安裝在Linux上的generator 能被安裝在Windows上的controllor所調(diào)用就必須確保windows 能夠 rsh Linux 。可惜我到現(xiàn)在還沒(méi)能試通,不知是不是因?yàn)槲业膚indows 和 Linux不屬于同一個(gè)domain的緣故。還得繼續(xù)研究,等有結(jié)果了之后再發(fā)上來(lái)。
http://bbs.dospy.com/viewthread.php?tid=3061548
http://www.hiapk.com/bbs/viewthread.php?action=printable&tid=10159
http://www.hiapk.com/bbs/thread-9751-1-1.html
http://www.hiapk.com/bbs/viewthread.php?tid=2834&page=1&extra=#pid11606
http://www.hiapk.com/bbs/thread-9751-1-1.html
http://www.gphone-cn.com/bbs/viewthread.php?tid=10889&extra=pageD1&page=1