有没有办法通过反向 WebSocket 获取语音文件内容

[ImSingee]

目前好像只能获取到语音文件名，获取 data 目录下文件的 api 也没有找到反向 websocket 怎么使用…

[stdrc]

目前确实没有办法通过正向和反向 WebSocket 来获取 data 目录的内容，这可能需要考虑一下

不知道 WebSocket 在一个很大的 message 在连接上传输的情况下能不能同时传输其它内容，如果能的话，可以做一下，不能的话这可能会造成在获取语音文件的时候无法处理其它请求

[stdrc]

还有一个问题，用 WebSocket 往回发文件，似乎无法标记对应的请求了？除非把文件 Base64 之后放在 JSON 里，或者还有另一种办法，让插件直接给某个指定的 HTTP 地址上传文件，这个还需要想一想。

[momocow]

最近剛好對 WebSocket 有些許著墨。

不知道 WebSocket 在一个很大的 message 在连接上传输的情况下能不能同时传输其它内容，如果能的话，可以做一下，不能的话这可能会造成在获取语音文件的时候无法处理其它请求

如果能理解 TCP Flow control 應該就不難理解，TCP 封包是有序的，語音文件的封包發完之前，只有同一個 receive window 下的封包可以發的吧。

不過語音文件發送的方向是由插件到用戶後端，不應該影響到處理請求（後端向插件）的吧？除非插件端用的是阻斷式 socket，必須等待文件寫入底層 buffer，才能回頭來處理請求？

除非把文件 Base64 之后放在 JSON 里

或是把 JSON 資料轉成二進制跟文件一起發（這肯定困擾很多開發者 😆）
畢竟 WebSocket 封包類型依編碼分為 utf8 或是二進制，只能選一個。

也可以參考 socket.io 的思路。

socket.io 在發送含有二進制內容的 JSON 時，會先用一個對象當作佔位符頂替二進制的部分（如：原先要發送的對象為["bin", <binary_data>]，則替換為 ["bin", { num: 0, _placeholder: true }]），並在下一個封包發送二進制內容（TCP 是有序的，只要確保 socket.write 的調用順序就沒問題的吧）。

[stdrc]

不過語音文件發送的方向是由插件到用戶後端，不應該影響到處理請求（後端向插件）的吧？除非插件端用的是阻斷式 socket，必須等待文件寫入底層 buffer，才能回頭來處理請求？

我隐约记得 WebSocket 是会建立两个通道，一个来一个去？如果是这样的话，调用 API 请求文件之后，文件占用了插件到后端的通道，此后的 API 调用虽然可以成功，但后端会潜在地需要很久之后才收到调用结果？