在Django中,默認使用的是HTTP通訊,不過這種通訊方式有個很大的缺陷,就是不能很好的支持實時通訊。若是硬是要使用HTTP作實時通訊的話只能在客戶端進行輪詢了,不過這樣作的開銷太大了。
所以,在1.9版本以後,Django實現了對Channels的支持,他所使用的是WebSocket通訊,解決了實時通訊的問題,並且在使用WebSocket進行通訊的同時依舊可以支持HTTP通訊。javascript
pip install channels
pip install asgi_redis
django-admin.py startproject channels_example
工程目錄以下:
|-- channels_example
| |--channels_example
| |-- __init__.py
| |-- settings.py
| |-- urls.py
| |-- wsgi.py
| |-- manage.py
這裏咱們要在內層的channels_example目錄下建立幾個channels所需的必要文件。
包括:
routing.py
consumer.py
asgi.py
這幾個文件先放着,以後我會一一介紹。
新的目錄以下:
|-- channels_example
| |--channels_example
| |-- __init__.py
| |-- settings.py
| |-- urls.py
| |-- wsgi.py
| |-- routing.py
| |-- consumer.py
| |-- asgi.py
| |-- manage.pyhtml
這裏首先將channels加入到INSTALLED_APPS中,以下:java
INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'channels', ]
而後,添加新的參數CHANNEL_LAYERS,以下:python
CHANNEL_LAYERS = { "default": { "BACKEND": "asgiref.inmemory.ChannelLayer", "ROUTING": "channels_example.routing.channel_routing", }, }
這裏,須要注意的是 ROUTING 參數,他是用來指定WebSocket表單的位置,當有WebSocket請求訪問時,就會根據這個路徑找到相應表單,調用相應的函數進行處理。
channels_example.routing 就是咱們剛纔建好的routing,py文件,裏面的channel_routing咱們下面會進行填充。web
上一步咱們已經瞭解到,routing.py文件其實就是個表單,功能和Django原來的urls.py文件同樣,不過這裏使用的不是URL,而是請求的類型。
redis
from channels.routing import route from channels_example import consumers #導入處理函數
channel_routing = [ #route("http.request", consumers.http_consumer), 這個表項比較特殊,他響應的是http.request,也就是說有HTTP請求時就會響應,同時urls.py裏面的表單會失效
route("websocket.connect", consumers.ws_connect), #當WebSocket請求鏈接上時調用consumers.ws_connect函數
route("websocket.receive", consumers.ws_message), #當WebSocket請求發來消息時。。。
route("websocket.disconnect", consumers.ws_disconnect), #當WebSocket請求斷開鏈接時。。。
]
上一步咱們已經瞭解到,routing.py至關於新的urls.py,而consumers.py就至關於新的view.py。
代碼:django
from django.http import HttpResponse from channels.handler import AsgiHandler #message.reply_channel 一個客戶端通道的對象 #message.reply_channel.send(chunk) 用來惟一返回這個客戶端
#一個管道大概會持續30s
#當鏈接上時,發回去一個connect字符串
def ws_connect(message): message.reply_channel.send({"connect"}) #將發來的信息原樣返回
def ws_message(message): message.reply_channel.send({ "text": message.content['text'], }) #斷開鏈接時發送一個disconnect字符串,固然,他已經收不到了
def ws_disconnect(message): message.reply_channel.send({"disconnect"})
相似於Django本身生成的wsgi.py文件,內容以下:
瀏覽器
import os import channels.asgi os.environ.setdefault("DJANGO_SETTINGS_MODULE", "channels_example.settings") #這裏填的是你的配置文件settings.py的位置
channel_layer = channels.asgi.get_channel_layer()
python manage.py runserver 0.0.0.0:8000
這是一個測試用的JS代碼,可以發送和接收WebSocket請求:websocket
<!DOCTYPE HTML>
<html>
<head>
<meta charset="utf-8">
<title></title>
<script type="text/javascript">
function WebSocketTest() { if ("WebSocket" in window) { alert("您的瀏覽器支持 WebSocket!"); socket = new WebSocket("ws://" + "localhost:8000" + "/channels_example/"); socket.onmessage = function(e) { alert(e.data); } socket.onopen = function() { socket.send("hello world"); } // Call onopen directly if socket is already open
if (socket.readyState == WebSocket.OPEN) socket.onopen(); } else { // 瀏覽器不支持 WebSocket
alert("您的瀏覽器不支持 WebSocket!"); } } </script>
</head>
<body>
<div id="sse">
<a href="javascript:WebSocketTest()">運行 WebSocket</a>
</div>
</body>
</html>
好比,我寫了下面三個函數響應connect,send和disconnectsession
@channel_session def ws_message(message): #送給全組人
print message.channel_session['room'] Group("chat-%s" % message.channel_session['room']).send({ "text": message.content['text'], }) @channel_session def ws_connect(message): room = message.content['path'].strip("/") message.channel_session['room'] = room Group("chat-%s" % room).add(message.reply_channel) @channel_session def ws_disconnect(message): print message.channel_session['room'] Group("chat-%s" % message.channel_session['room']).discard(message.reply_channel)
客戶端我這樣寫:
socket.onopen = function() { socket.send("hello world"); }
這樣就會產生一個問題,當客戶端鏈接到服務端時,服務端執行ws_connect()函數,而後客戶端又send()了數據,服務端就會去調用ws_message()函數,而終止了ws_connect()函數的執行。
此時,個人ws_connect()函數還未對message.channel_session['room']進行賦值,而ws_message()函數就調用了他,因此會報錯。
而後我嘗試了斷開鏈接,運行正常,這就說明ws_connect()函數最終仍是執行完了,不過是在ws_message()函數執行以後。
綜上,當服務端接收到新的請求時,可能會打斷上個請求的執行,這點須要特殊注意一下。