WebRTC（Web實時通信）的創(chuàng)建主要是為了視頻和音頻通信，但它也有在兩個瀏覽器之間傳遞二進制數(shù)據(jù)的API。這為創(chuàng)建更多的點對點Web應用程序帶來了許多機會，而且已經(jīng)有許多有趣的應用程序是使用它創(chuàng)建的，如WebTorrent、UberConference。

　　Zohaib Rauf是一名軟件工程師，他正在學習Elixir語言。為了更好地理解WebRTC，他使用它創(chuàng)建了一個P2P文件分享應用程序，目標是實現(xiàn)點對點的文件分享，而不需要任何中間人。文件發(fā)送者添加文件，并將唯一URL分享給接收者。接收者訪問唯一URL就可以看到分享的文件并下載，如下圖所示：

　　在該應用程序中，Zohaib使用Phoenix框架實現(xiàn)了一個用于初次握手的代理。近日，他發(fā)表了一篇博文，簡要介紹了該代理的設計決策過程。

　　代理的作用

　　為了創(chuàng)建點對點的連接，發(fā)起者會創(chuàng)建一個包含其網(wǎng)絡信息和其它媒體相關信息的握手請求。接收者在收到請求后會創(chuàng)建應答和它自己的申請并發(fā)送回發(fā)起者。發(fā)起者接收到應答后完成初次握手。至此，發(fā)起者和接收者就可以進行點對點通信了。在這個過程中，需要有一種方式交換握手請求信息，這就是代理的用途所在了。

　　代理的實現(xiàn)要滿足如下兩個要求：

　　1.它應該能夠通過WebSocket使用對等節(jié)點的ID與其通信；
　　2.它需要維護已接入的對等節(jié)點的信息。

　　每個對等節(jié)點在接入Zohaib的Web應用時都會獲得一個唯一ID，并在收到唯一ID后將自己進行注冊。

　　使用對等節(jié)點ID進行通信

　　對于第一點要求，Zohaib嘗試了兩種方法。第一種方法是為對等節(jié)點ID和與它相關連的Socket維護一個通用的映射。當需要同某個對等節(jié)點通信時，就使用對等節(jié)點的唯一ID檢索出Socket，并將消息推送給它。第二種方法是每個對等節(jié)點連接到一個唯一的主題，當需要向那個節(jié)點發(fā)送消息時，只需將消息廣播到那個主題。有且只有一個對等節(jié)點會注冊到那個主題，所以，其它對等節(jié)點不會獲得這條消息。Zohaib采用了第二種方法，因為第一種方法需要一個Elixir代理存儲映射。這樣，每個通信請求都需要向該代理發(fā)送消息獲取Socket，它會成為瓶頸，而且不可擴展。而在第二種方法中，當向WebSocket注冊時，節(jié)點會連接到唯一的主題（比如peer:20dd48ca-fdcf-41c9-9a3b-f192f77650f9）。這時，就可以使用函數(shù)ApplicationName.Endpoint.broadcast(topic，event，payload)向該主題發(fā)送消息。

　　對等節(jié)點信息維護

　　對于第二點要求，Zohaib同樣嘗試了兩種方法。第一種方法是同上文描述的一樣，保存一個通用的映射。但當Socket連接關閉或Socket進程結(jié)束時，代理需要自己維護映射關系。第二種方法是使用Elixir/Erlang的全局名稱注冊功能。這種方式可以將一個全局名稱注冊到對應的PID。當進程崩潰或終止時，該名稱會自動解除注冊。而且，這種方法可以擴展到多個節(jié)點。因此，Zohaib采用了第二種方法。當節(jié)點注冊時，它會啟動一個簡單的GenServer，后者維護與節(jié)點相關的信息，并為節(jié)點分配一個像peer_state:<UUID>這樣的全局名稱。該進程會鏈接到Socket進程，如果Socket關閉或崩潰，那么該進程也會終止并解除注冊。在這種方式中，代理不需要自己維護映射。

　　交換WinRTC請求

　　有了代理，就可以交換握手請求了。例如，發(fā)送者將一個像http://epicshare.zohaib.me/?peer_id=20dd48ca-fdcf-41c9-9a3b-f192f77650f9這樣URL的分享，其中包含對等節(jié)點的ID。接收者打開該URL后會獲得一個唯一ID，并像上文描述的那樣將自己注冊到代理。那樣，兩個對等節(jié)點就都通過Web Socket連接到代理了。下一步，它們就可以發(fā)送和接收握手請求了，過程如下所示：

　　感興趣的讀者可以試用Zohaib的程序，或者下載源代碼。

　　另外，從Hacker News網(wǎng)友的討論中得知，使用WebRTC在兩個瀏覽器之間交換請求/應答可以不借助任何服務器。