unity3d網(wǎng)絡(luò)交互的方法

unity3d--網(wǎng)絡(luò)交互的方法RemoteProcedureCalls(RPC)也叫RPCs，遠(yuǎn)程過程調(diào)用通過網(wǎng)絡(luò)在不同的機器上調(diào)用函數(shù)。這也包括玩家本地游戲?qū)嵗齩CIient可以傳送RPCs到Server,Server也可以把RPCs傳到一個或者多個Client上。最普遍的情況是，RPCs用于不是很頻繁發(fā)生的動作。比如客戶端開了一個開關(guān)想要開門，它可以傳送一個RPCs到Server告訴Server門已經(jīng)打開了。然后Server可以傳送另一個RPCs給所有Client,執(zhí)行它們本地的函數(shù)將同一扇門打開。RPCs用于管理和執(zhí)行獨立的事件。調(diào)用RPCs幾乎和調(diào)用普通函數(shù)一樣簡單，但是仍然有一些重要的區(qū)別需要理解。1.一個RPC調(diào)用可以有任意多的參數(shù)。所有的參數(shù)當(dāng)然都會被通過網(wǎng)絡(luò)傳送。越多的參數(shù)會讓帶寬使用越多。所以應(yīng)該盡量減少參數(shù)。2.需要指定誰將要接收正在被送出的RPC。有幾種RPC調(diào)用模式，概括了所有常見的情況。你可以在以下這些模式執(zhí)行RPC函數(shù)：everyone,僅在server,除了自己外的everyone,—個指定的Client或玩家。狀態(tài)同步(StateSynchronization)狀態(tài)同步用于共享不斷變化的數(shù)據(jù)。最好的例子就是在一個動作游戲里一個玩家的位置信息。這個玩家總是移動，來回跑、跳躍、等等。即使是不需要控制他的網(wǎng)絡(luò)中的其他玩家，也需要知道他在哪，在做什么。通過不斷的傳送關(guān)于這個玩家的位置信息，其他玩家就可以精確的表示這個玩家的位置。這種數(shù)據(jù)通常定期的、頻繁的通過網(wǎng)絡(luò)傳送。因為這種數(shù)據(jù)是時間敏感的，而且需要通過互聯(lián)網(wǎng)管道從一個機器傳到另一個機器上，所以盡可能的減少這種數(shù)據(jù)的傳送量是非常重要的事情。簡單的說，狀態(tài)同步一般需要很多帶寬，所以你應(yīng)該做一切可能的盡可能減少帶寬的使用量。狀態(tài)同步目前支持兩種類型的傳輸?shù)目煽啃员ＷC(reliability)。可靠的差值壓縮(ReliableDeltaCompressed)和非可靠(Unreliable)的方式?？煽康幕诓钪祲嚎s的方式(ReliableDeltaCompressed)可靠的差值壓縮(ReliableDeltaCompressed)模式會自動比較上次客戶端接收到的消息。如果相對上次消息沒有數(shù)據(jù)發(fā)生變化，就不傳輸數(shù)據(jù)。但是在它之上數(shù)據(jù)將在每個屬性的基礎(chǔ)上進行比較。舉例來說就是，如果你的位置發(fā)生了變化但是方向沒有變化。只有位置會被傳送過來。在這種模式下，Unity內(nèi)部打包時在每個屬性前增加1位決定是否發(fā)生了改變。如果沒有改變，這個屬性并不會包含在序列化的數(shù)據(jù)中從而節(jié)省了很多帶寬。Unity也會保證每個被送出的封包都會到達，在UDP丟包的情況下，它會重發(fā)這個封包，直到封包被接收到。這意味著如果一個包丟了，之后送出的封包在丟包重發(fā)并且收到之前不會被應(yīng)用。在那以前，所有之后送出的封包將會放到一個緩沖中等待。非可靠(Unreliable)在非可靠的模式下，Unity不管當(dāng)前的狀態(tài)是否改變都會將其送出。狀態(tài)不會被差值壓縮傳送,因為并不會知道送出的數(shù)據(jù)是否會實際到達接受者。文章出處：(狗刨學(xué)習(xí)網(wǎng)決定使用哪種方式Unity的網(wǎng)絡(luò)層使用UDP非可靠無序協(xié)議，但是卻可以像TCP—樣發(fā)送有序的可靠的封包。它內(nèi)部使用ACKs和NACKs控制封包的傳輸，確保沒有丟包。但使用有序可靠的封包的缺點是如果一個封包丟了或者延誤，所有東西都會停下等待直到那個封包安全到達。這在延時敏感的網(wǎng)絡(luò)中傳輸時，會導(dǎo)致明顯的延時。非可靠的傳輸一般用于，你明確知道無論怎樣每幀都會改變的數(shù)據(jù)。舉例來說，在一個賽車游戲中，你可以認(rèn)為玩家的車一直在運動。這種情況下，基于差值壓縮的可靠傳輸除了增加了消耗并沒有帶來什么實質(zhì)性的利益。一般而言，當(dāng)你知道數(shù)據(jù)一直在改變并且減小延時是至關(guān)重要的事情時，你應(yīng)該使用非可靠的傳輸。如果被被NetworkView跟蹤的數(shù)據(jù)并沒有每幀都在改變，并且?guī)拰δ銇碚f很重要時，基于差值壓縮的可靠傳輸更好。明白延時和帶寬不是同一件事情是十分重要的。它們是你在不同情況下想要優(yōu)化的不同的屬性。使用C#的Socket類因為Unity支持C#語言，所以可以在一個腳本對象中使用C#提供的套接字類，實現(xiàn)自定義的數(shù)據(jù)傳輸。這樣做提供了很高的靈活性和控制能力，可以用Unity的客戶端連接非Unity的服務(wù)器程序，反之亦然。其他相關(guān)知識MasterServerMasterServer是一個當(dāng)前正在尋找客戶端的活動的游戲與正在想要連接到游戲中的玩家客戶端見面的場所。它的另一個目的是隱藏IP地址、端口等細(xì)節(jié)信息，進行一系列的技術(shù)性操作工作，配置網(wǎng)絡(luò)連接，有時候也可以在一些不太可能進行連接的情況下配置連接，比如說處理防火墻，或者NAT洞穿。每個單獨運行的游戲服務(wù)器為MasterServer提供一個游戲類型(GameType)。所有具有相同游戲類型的游戲服務(wù)器被收集到一起，使得與他們兼容的客戶端可以很方便的看見它們。當(dāng)一個玩家連接并且請求MasterServer一個匹配的游戲類型時，一些服務(wù)器上有用的信息就顯示給這個玩家看。這就幫助玩家決定連接到哪個服務(wù)器。這些有用的信息包括：游戲名稱(GameName)，玩家數(shù)量和是否需要密碼。有兩個傳輸這些信息的函數(shù)：Server的是[url=]MasterServer.RegisterHost()[/url],Client端的是[url=]MasterServer.RequestHostList()[/url].

NetworkViewsNetworkViews是通過網(wǎng)絡(luò)共享數(shù)據(jù)的組件。它們允許兩種網(wǎng)絡(luò)交互類型：狀態(tài)同步(StateSynchronization)和遠(yuǎn)程過程調(diào)用(RemoteProcedureCalls)。當(dāng)你有很多客戶端運行同一個游戲的時候，每個客戶端有一組組成整個游戲的物體。為了讓兩個或更多的客戶端看起來一樣，這些物體需要通過共享數(shù)據(jù)來同步。這就叫狀態(tài)同步。同步每個物體的狀態(tài)需要海量的數(shù)據(jù)，太多的需要通過網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)，讓你的游戲無法運行。為了解決這個問題，NetworkViews通常指定什么數(shù)據(jù)需要被共享，什么物體需要同步。每一個NetworkViews監(jiān)視一個物體的指定的一部分，保證它用其他客戶端相同的物體同步。OIn&pect-nrMVGameObjtctTagUnta-gg&d$Layer'D&fau