Posted on

Socket.io錯誤訊息意義

I have found:

  • “ping timeout”: client stopped responding to pings in the allotted amount of time (per the pingTimeout config setting).
  • “transport close”: this appears to happen if the client side stopped sending data at all… or maybe there’s some kind of callback causing this to happen. I can see it happen if I just close a tab or follow a link from a page where I have an active connection to the server. But I’m not clear if this is always a case of the client causing it to happen.

    Sorry for re-opening the issue. Regarding the transport close that is the reason when page is closed/reloaded, it also happens some times in bad network conditions specifically when the ping packets are not delivered to the client. For the latter I need to handle it in the server side by waiting for the client to reconnect. Is there a way to properly distinguish between these two?

  • “Client namespace disconnect”: When the client sends a disconnect packet (client.disconnect())
  • “server namespace disconnect”: Looks to be when the server performs a socket.disconnect() action.
  • “Transport error”: An error occurred, I assume this is a server side error, but I’m not totally clear, as I’ve not been able to trigger one on my own.
  • “io server disconnect” This occurs using a third party library socketIOAuth when authentication fails

Continue reading Socket.io錯誤訊息意義

Posted on

Socket.io介紹

Socket.io

socket.io是基於Websocket的Client-Server實時通信庫

Socket.io承繼了Node.js的事件處理方法,把Client端與Server端的程式統一成一至的操作方式,讓使用者可以只需專注在處理「事件」,就可以快速開發出應用,他也支援『房間』的概念,可以使用同一條WebSocket卻擁有不被彼此干擾的資料傳輸(多種聊天頻道的概念)。另外,他也提供了很好的fallback機制,即使用戶的瀏覽器不支援WebSocket,他還是可以利用Flash、XMLHttpRequest等方式來傳送資訊(速度會比較慢就是了)。這些機制都他都包裝好了,所以寫程式時並不需要知道這些細節,只需要設定好就可以運作。

Socket.io 特性整理

  • Events 自訂事件。
  • Rooms Room 的概念只存在於伺服器端。可以理解為訊息處理時的聽眾分組,可對同一個分組內的聽眾進行廣播。
  • Namespaces 命名空間,我理解為底層連線的分組管理,不同命名空間可以走同一條 Engine.io 連線或是各自連線,每個命名空間可以各自驗證是否接受連線。
  • ACK 回調 如同 HTTP 之於 TCP,HTTP 為 TCP 提供了一套請求與響應的模型。ACK 也為 Socket.io 提供了一套請求與響應的通訊模型。
  • 連線維護
  • 自動斷線重連
  • ping/pong 心跳

Continue reading Socket.io介紹

Posted on

Socket.io自行增加header

伺服器端

範例程式碼:

import express from "express";
import http from "http";

const app = express();
const server = http.createServer(app);

const sio = require("socket.io")(server, {
    handlePreflightRequest: (req, res) => {
        const headers = {
            "Access-Control-Allow-Headers": "Content-Type, Authorization",
            "Access-Control-Allow-Origin": req.headers.origin, //or the specific origin you want to give access to,
            "Access-Control-Allow-Credentials": true
        };
        res.writeHead(200, headers);
        res.end();
    }
});

sio.on("connection", () => {
    console.log("Connected!");
});

server.listen(3000);

Continue reading Socket.io自行增加header

Posted on

Engine.io介紹

Engine.io介紹

Socket.io是在engine.io的基礎上去實作的
Gitlab連結: Engine.IO: the realtime engine
engine.iosocket.io提供跨瀏覽器/跨設備的雙向通信的底層庫。engine.io使用了WebsocketXHR方式封裝了一套socket協議。在低版本的瀏覽器中,不支持Websocket,為了兼容使用長輪詢( polling )替代。

關於長輪詢可參考我的另一篇文章:WebSocket與Ajax的不同
過去WebSocket未出來時,許多聊天室使用的都是長輪詢的方式去實作,而engine.io則可依據客戶端環境兼容使用這兩種方式。
Continue reading Engine.io介紹

Posted on 1 Comment

WebSocket與Ajax的不同

WebSocket與Ajax的不同

WebSocket 是HTML5 開始提供的一種在單個TCP 連接上進行全雙工通訊的協議

WebSocket 使得客戶端和服務器之間的數據交換變得更加簡單,允許服務端主動向客戶端推送數據。在WebSocket API 中,瀏覽器和服務器只需要完成一次握手,兩者之間就直接可以創建持久性的連接,並進行雙向數據傳輸。

在WebSocket API 中,瀏覽器和服務器只需要做一個握手(polling)的動作,然後,瀏覽器和服務器之間就形成了一條快速通道。兩者之間就直接可以數據互相傳送。

現在,很多網站為了實現推送技術,所用的技術都是Ajax 輪詢。輪詢是在特定的的時間間隔(如每1秒),由瀏覽器對服務器發出HTTP請求,然後由服務器返回最新的數據給客戶端的瀏覽器。這種傳統的模式帶來很明顯的缺點,即瀏覽器需要不斷的向服務器發出請求,然而HTTP請求可能包含較長的header,其中真正有效的數據可能只是很小的一部分,顯然這樣會浪費很多的帶寬等資源。

HTML5 定義的WebSocket 協議,能更好的節省服務器資源和帶寬,並且能夠更實時地進行通訊。

下圖是兩種方式的對比圖,我們可以看到Ajax是一直相同頻率的http request,而WebSocket在第一次的握手(http)之後就改走WebSocket的路

WebSocket 屬性

Socket.readyState: 屬性readyState表示連接狀態,可以是以下值:

  • 0 – 表示連接尚未建立。
  • 1 – 表示連接已建立,可以進行通信。
  • 2 – 表示連接正在進行關閉。
  • 3 – 表示連接已經關閉或者連接不能打開。

Socket.bufferedAmount: read only屬性bufferedAmount已被send()放入正在隊列中等待傳輸,但是還沒有發出的UTF-8文本字節數。